[ale] IBM is buying Redhat!

[Beddingfield, Allen]

It isn't so much about "Security" as it is a about ability and 
willingness to execute.
If "Super Mega Agency" discovers a problem that is not yet fixed with a 
publicly available patch, they call up Red Hat/Oracle/SUSE, and someone 
literally creates a patch for the issue especially for them, does the 
requisite testing, documents it, and stands behind it. We've done this 
process with SUSE multiple times as a university.  We are a big enough 
customer that they immediately dedicated the resources to do this.
If that occurs with Debian or something similar, what are they to do? 
Take to IRC and beg a developer for help?
Allen B.

On 10/29/18 9:40 AM, Simba via Ale wrote:
> That's been true for years but I think it's less so these days. Debian
> has a lot of support in the commercial sector. Like I said it's got
> something similar to SELinux but I don't recall, someone in #debian on
> freenode explained it to me like a year ago.
> 
> Personally, I really dislike when someone in the commercial sector
> believes they have to use RHEL because it's "the secure one", and I try
> to encourage them to use Debian instead, because the stable branch is
> plenty secure.
> 
> of course I realize I'm saying this right after a vulnerability was
> spotted in SystemD but it's been patched at the source and i'm confident
> a fix will be coming down the pipe soon.
> 
> https://security-tracker.debian.org/tracker/CVE-2018-15688
> 
> We could argue forever over which distro is most secure.. who's got the
> time.
> 
> 
> Simba Lion - https://tailpuff.net
> https://keybase.io/simbalion
> 
> "Why is a raven like a writing desk?"
> On 10/29/18 10:26 AM, James Taylor via Ale wrote:
>> Just an added note about meeting DoD requirements.
>> SUSE and redHat spend a lot of time upfront baking DoD security
>> specifications into each of their releases before they are allowed out
>> the door.
>> Government, and most commercial customers care about that.
>> I don’t always use commercial versions of linux for customer solutions,
>> but when I'm working with clients in to regulated spaces, that doesn’t
>> fly far.
>> -jt
>>   
>>
>>> On Oct 29, 2018, at 9:33 AM, Beddingfield, Allen via Ale <ale at ale.org
>>> <mailto:ale at ale.org>> wrote:
>>>
>>> Oh, and I forgot to mention:  Support for LONG term releases,
>>> backporting of fixes, and rigid change control.
>>> For example:  Want to upgrade from version 12.2 to version 12.3?
>>>   Better start the approval process a year early...  document your
>>> testing plan, provide a tested backout plan, have adequate testing
>>> documented and verified by the proper people, pass the change control
>>> approval process to go into a limited subset of test systems....wait
>>> the required time for full deployment to test systems....wait the
>>> required time for production rollout.
>>> Or:  Want to apply an in-the-wild zero day exploit patch? Follow a
>>> slightly faster variation of the above process.
>>>
>>> The Debian or Ubuntu model will not pass the change control
>>> requirements.  These are the reasons that SUSE and Red Hat backport
>>> fixes into an old version of a package for seven+ years, instead of
>>> incrementing the version.  That is why SUSE is still patching PHP
>>> 5.3.x on SLES 11 SP4.
>>>
>>> Allen B.
>>
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> https://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
> 

-- 
Allen Beddingfield
Systems Engineer
Office of Information Technology
The University of Alabama
Office 205-348-2251
allen at ua.edu