Re: Proposal/Guidelines for working on *-security branches in packaging repository
Le lun. 16 sept. 2019 à 22:00, Salvatore Bonaccorso
<carnil@debian.org> a écrit :
>
> Hi
>
> I was pondering for a while to try to start this discussion. And it is
> more a collection of some thoughs.
>
> Recently more people have started to work to as well commit fixes for
> CVEs into the respective *-security branches. This is very good news
> indeed :) and is very encouraging to see contributions!
>
> I started to think we might want to outline some guidelines what to
> commit on *-security branches while we are yet UNRELEASED.
>
> Two preliminary points have to be stated to make the idea clear:
>
> - Not every CVE fix needs really a DSA or an "urgent" release via
> security, many fixes go in as well via import of upstream stable
> releases and scheduled in point releases.
> - If a security upload needs to be done, and there is in particular an
> ABI bump involved, then more needs to be done (bump ABI, make a new
> linux-latest upload, packages need to go through NEW on
> security-master and need manual intervention from ftp-masters, the
> later is as well then in twice instance needed for now from
> ftp-masters for signed kernel as well).
>
> So my idea was to bring this up here for discussion: I think while
> working on *-security branches and keep the possibilty to release
> "fast" updates without ABI bump via security, whenever needed for an
> "urgent" fix -- I would propose as guideline -- commits can, and are
> *encouraged* to be added, if there is no ABI break. If there is an ABI
> break and the fix is not very urgent, then rather keep if off for the
> time beeing.
>
> Whenever then an urgent fix is needed which in any case requires an
> ABI bump then it's safe to add as well other less urgent commits for
> CVEs.
As a security and system linux engineer, for me any security breach is
a security breach.
There are no "less urgent" security fixes. Even if technically, I
agree that there are
critical security issues, like spectre typically, while some others
have a smaller
surface attack... or harder to exploit because it requires exotics hardwares
(I just share my opinion here)
Anyway, I understand that in some cases, it is more complicated to do
a new upload
in the security branch, mostly in case of ABI bump.
So a general rule to avoid the most all possible ABI bumps in security uploads,
is good to me. it does make sense to me to write a doc for this, yes :)
What is your definition of "less urgent" security issues ? (or important ones).
The fact is, there are products running buster now, so in case of
security issues,
these cannot really wait the next point releases (for some of these).
Can we propose to upload at maximum 1 or 2 security updates for the
kernel between
each point release ? (with maximum one ABI bump.. for example... ) 1
sec update at
maximum would be good and acceptable, imho..
Regards,
Romain
Reply to: