[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 26 Apr 2015, at 17:25, Simon Waters <simon@xxxxxxxxxxxxxx> wrote: > On 2015-04-26 10:50, Brad Rogers wrote: >> FYI, Jessie has just been released, and will have LTS (at least 5 years). > Squeeze is ancient history, but I think a lot of folk have got a bit laid back > (myself included), as the years roll by quickly. > > There is an arrangement for long term security support for Squeeze, but I don't > think these are really viable on ANY distro. > > There are security issues that do not, or can not, be addressed in older software > with just back porting small fixes, and the priority almost invariably drops as > the code varies further and further from the current maintained version. > > I too am guilty of fixing bugs only to discover a long time afterwards that it was > also a security relevant bug. Heck colleague just released an open source product > update with 3 obvious security fixes but only 2 CVE numbers assigned, it happens. > But a bunch of the other fixes in that release concerned an authentication step, > very likely that security bugs in this were fixed, probably inadvertently. If this > code were packaged in Debian my guess is the maintainer would end up doing more > work than the developers if they tried to avoid simply updating it. > > Even trying to backport fixes to older releases may be a mistake in that it > encourages people to put too less effort into maintenance, whilst running software > that often lacks modern security controls. > > Good example - default PHP on RHEL 6 was 5.3 - no really. > > So does it matter if a lot of people offer PHP 5.3? Yes because proper password > hashing was introduced into PHP in 5.4, and other security features were added, > whilst key bad practices were removed, or deprecated. The back porting cements in > suboptimal habits or forces coding for specific versions increasing complexity. > Redhat ended up with 3 versions of PHP on RHEL 6, and we are talking about a > company that accidentally left some key security fixes out of RHEL 7 (whoops), so > you really want them supporting 3 versions of PHP on 2 versions of RHEL, when they > are struggling with one version of some Internet facing software? > > Another example is TLS support, the older distros were shipping with openssl > supporting SSL2, SSL3 and TLS 1.0. Now SSL2 and SSL3 are considered broken, so you > only have TLS 1.0 left. Next bad bug in OpenSSL, and they'll have to upgrade the > whole stack, or further fork the code (and maybe standard), to keep things secure. > > Debian 8 (Jessie) and Ubuntu 15.4, both fine choices for the month of April. I > have Jessie installing in a terminal window behind this one as I type, and a > virtualbox in another window for testing another Jessie upgrade. > > Ultimately people are looking to stand still (for good business reasons), in an > environment in which the software is less secure than it needs to be to meet the > threats it faces. Whilst it is possible to constrain the threat with depth, > isolation of service, firewalls, intrusion prevention, if you have the money and > time to do all that you probably also have the motivation to maintain all your > software anyway, most people are doing very little of the depth type stuff, and > hoping the software will work some sort of magic. > > all very valid points, but the guy just wants a local non internet facing file server that works. Form my POV the trade off is actually documentation related. When your new cutting/bleeding edge is a pain in the ass, options and new ways to do stuff don't tend to hit the mainstream documentation and blogs for a few months. (especially when you don't know where to look yet) Where as a slightly older stable, LTS version with an abundance of documentation is a great place to start learning. > > -- > The Mailing List for the Devon & Cornwall LUG > http://mailman.dclug.org.uk/listinfo/list > FAQ: http://www.dcglug.org.uk/listfaq -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq