Security EOL within Debian Stable

[Stephen Dowdy <sdowdy@ucar.edu>]

(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   -  sdowdy@ucar.edu        -  http://www.ral.ucar.edu/~sdowdy/