Sven Luther wrote: > There is this vendor-specific-security-announce-with-embargo thingy. > > The debian kernel team mostly handles the unstable and testing kernel, is not > in the loop for getting advance advice on those problems, so we cannot build > fixed versions until the vulnerability gets announced, and thus we can't > upload kernels in a timely fashion like ubuntu or other vendors do, who often > have a couple week of advance warnings. On slower arches this could be a > problem. > > The debian-security team is handling stable only, and there are no security > updates for unstable until way after the embargo is over, and for testing a > bit after that, depending if the kernels get hinted in or not. > > To have proper security-in-testing-or-unstable for the kernel, the > debian-kernel security team, or at least a few members of it, need to be made > aware of the embargoed security holes, and get a chance to fix them in > advance, maybe with a private or security non-public copy of our svn tree > (using svk maybe). > > This is not a ubuntu related problem though, and the help the ubuntu > kernel/security team has provided us was invaluable, but it should maybe not > be necessary if the information was not unrightfully hold from us in the first > time. You seem to be implying that ubuntu is providing you with confidential prior warning about kernel security holes, but I really doubt this, since many of the ubuntu secutity advisories that I've backchecked against the debian kernels have turned out to still be unfixed in the kernel teams's svn weeks later. My experience is that the kernel security team is not very quick to fix publically known security holes, or to make uploads specifically for those holes once they have a fix. Even if we limit it to fixing the kernel-source packages and ignore the whole issue of rebuilding kernel-image packages for all arches. -- see shy jo
Attachment:
signature.asc
Description: Digital signature