|
|
Log in / Subscribe / Register

Trouble at Linux Mint — and beyond

Trouble at Linux Mint — and beyond

Posted Feb 25, 2016 16:25 UTC (Thu) by misc (subscriber, #73730)
In reply to: Trouble at Linux Mint — and beyond by jospoortvliet
Parent article: Trouble at Linux Mint — and beyond

Caring about security can mean differents things. Is "publishing a announce" caring, or is "backporting the fix to a stable release" caring ? One of the main interest of using a distribution is the coordination, and if the model for security is "upgrade to latest version", it might not work that well in practice (mostly because some upstream are also platform for plugins and/or have unexpressed dependencies on the protocol with others components).

There is a reason why the model of Gentoo upgrade is not that widely used in the industry, even if CD/CI and new stuff permitting to revert (such as docker/rkt, ostree, snappy, or just immutable server) might change that.

Business depending on a web application might also have incentives to not offer a free version for a too long time, since some might sell a entreprise version supported for a longer time (even if that's at least better than the alternative of making a opencore model such as newer companies try to do, such as docker and docker datacenter, or beegfs with a strange opensource license)

I have been told that the LF have created a checklist regarding security, which might be a starting point for evalutating a upstream for suitability. having dealt with various upstream for reporting CVE, I must say that while I do not have a set big enough to get any definite conclusion, I was not impressed by how most of them handle security.

Few peoples know how to get a CVE, few seems to care getting one before publishing the patch (or even after), and one vendor took even 2 months to say "there is no security problem" issue, stance that was reverted once I posted publically to get feedback from others (and that's why "responsible disclosure" folks can't have nice things).

At the same time, dealing with distribution security team was a much nicer experience, mostly because they deal with more security issue, so they have likely more experience dealing with it. Maybe some kind of federation of upstream project security could work. 1 single point of contact for various upstreams, able to decide if a security bug is a security bug or not, able to contact the right person using the right medium, following a published process, etc.

And upstream should have to follow some charter to be part of the group.

That's maybe something that could convince me (as a packager, ex-distributor and current sysadmin) that upstream would provides the support I would find acceptable.

Of course, better understanding with the constraint of their downstream (and of the users of the downstream, cause distro do not have rules for the fun of having them) could help a lot. But since there is always a new set of upstream, and each starting by thinking "we know better", that's a never ending task.


to post comments


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds