(after contemplating a possible 'chromium' thread hijack, i figured this should be a new thread)...
I see a definite problem with the way that package security support gets end-of-lifed in Debian-Stable. Not just chromium and other browsers, but the JDK/JRE packages, historically, as well. I'm not trying to point fingers or criticize, i legitimately want to know if there's something i'm missing, or if something could be done to handle package deprecation for security EOL conditions. So, if a user installs said package, but fails to notice any EOL DSA on it, the package gets left in place in a potentially VULNERABLE state. I.E. if a known exploit comes out, and the package is still installed, the end-user could get a nasty surprise thinking that because they've added security support to apt-sources and regularly update, that they are protected. This is a non-optimal and undesired end-result. Now, i'm sure some will argue about "Personal Responsibility" (keeping track of all the DSAs, etc), but leaving packages vulnerable in the Stable release seems to fly in the face of: https://www.debian.org/security/faq#handling Q: How is security handled in Debian? A: Once the security team receives a notification of an incident, one or more members review it and consider its impact on the stable release of Debian (i.e. if it's vulnerable or not). If our system is vulnerable, we work on a fix for the problem. The package maintainer is contacted as well, if they didn't contact the security team already. Finally, the fix is tested and new packages are prepared, which are then compiled on all stable architectures and uploaded afterwards. After all of that is done, an advisory is published. Note that chromium is in 'main' -- not 'contrib' or ..., so there's a valid expectation that its security support won't just silently stop -- unlike the other FAQ entry that says there's basically no security support or contrib, non-free.. Is there some mechanism that currently exists that could be used to flag such security EOL packages? this could be done by putting out a FINAL EOL security channel package update that did something like: - minimally change the package metadata "Description" to "SECURITY EOL ..." - made the package transition and made it depend on the newly named package "${package-name}-security-eol" - add a version suffix like "${package} version: ${version}-security-eol" (e.g. chromium 37.0.2062.120-1~deb7u1-security-eol ) - create a new repo component called 'security-eol' to complement main,contrib.non-free... ...??? It would be quite rude to automatically remove installed packages that were known vulnerable, obviously, but, maybe that would solve the problem, and anyone who wanted to willingly keep a package installed that was EOL/vulnerable, could apt-pin it. Similarly, a security-eol update could simply remove the executable bits from vulnerable applications, requiring end-user manual intervention. Still a shocker, but IMHO a better solution than leaving users vulnerable. Any comments, ideas, pointers to the reference that answers my question or points out my confusion... are welcome. thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu - http://www.ral.ucar.edu/~sdowdy/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CA+CZZDY8xJcBYmjzFMYRF=lh6uj2s50zov46_cvpkixh+ej...@mail.gmail.com