Discussion about handling embargoes

[Florian Weimer]

On 09/23/2015 07:38 AM, pjp at fedoraproject.org wrote:

> What we really need is a process/policy to push updates in a timely order.

And I believe handling embargoes is just a small aspect of this, and
many security issues linger around well after the embargo.

> I wonder how other communities folks handle it. Don't they also have
> maintainers who are least bothered about fixing security issues in their
> packages?
> 
> @Florian: how does it work in Debian?

For core packages in a release with unresponsive maintainers, the
security team makes fixes happen, by either uploading something on their
own, or sponsoring a third-party upload.  For obscure packages, this
does not happen, but users are informed through debsecan (and
third-party commercial tools) that packages on their system have unfixed
security bugs.

In Debian, security bugs are generally release-critical, and packages
with unfixed security bugs will eventually be removed from the testing
distribution, from where the next stable release will be branched.
(Release-critical bugs are real blockers, they have to be addressed or
downgraded.)  We have realized that providing security support for
otherwise unmaintained packages in unstable is counterproductive, so we
no longer tend to do that.

>> Would we need some kind of "security-updates" repository that would
>> only carry security fixes while they are fresh and not mirrored
>> everywhere else?  Maybe a small centralized repository would not need
>> to handle too much load, if it only contains security fixes for a small
> 
>> period of time while they are still being copied to the other mirrors.
> 
>   I'm not sure about it, a separate repository sounds iffy.

Another advantage is that you can downgrade because the old version is
still available from the main or updates repository, which means that
updates can perhaps be pushed with less QA.

-- 
Florian Weimer / Red Hat Product Security