Jérémy Bobbio wrote:
> Here's the ideas that I have heard (and written) during the "Supporting
> 15.000 packages" BoF which happened during DebConf7. I should probably
> have posted this earlier, but, well, better now than never...
Thanks for taking notes.
> The security team is already overloaded. Is there any point on
> supporting every single "minimal http server"? Which kind of support
> can we offer for bad PHP web applications? How could we deal with
> dead/stubborn upstream?
>
> * If we agree that we have unsupported packages, how to mark them as
> such? A possible solution would be to add an extra-section like
> Ubuntu. Another one is to use the Debtags framework. The later is
> far more flexible and we can also more easily change package state
> over time. People attending the BoF seemed to have a consensus about
> *not* adding an extra section.
>
> * If we drop security support for a package, user of stable should be
> notified...
debtags seemed the most passable choice. I believe we need:
* [etch|lenny]-security-unsupported to flag that a source package has no
support by the Security Team. It should be distribution-specific to
allow revoking support for individual suites, as it was necessary for
Mozilla in Sarge.
* local-use-only (or something similar, I'm unsure about the exact naming),
to indicate that security support only applies to local, trusted users.
An example: SQL-Ledger has a horrible security track record, so we only
support to run it behind an authenticated HTTP zone. It's still a useful
software and limiting support is a viable choice; doing accounting carries
a whole lot of implicit trust anyway.
Once implemented in debtags we need support in apt, etc.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
