[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
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)
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.
>
>
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
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq