Continuing on from the SCC stuff, which I should probably get in the
habit of calling
the mirror split, then…
At the same time as I’ve been trying to work out ways to fit the mirror
split stuff into the
AJ market concept, I’ve been pondering on
and off what can be done to improve the
security situation. My
thinking’s probably still biassed by my
long time wish for
official security updates to testing, but I’m somewhat inclined to think
that if we can figure out a way of integrating the testing security team
and the official security team we might end up closer to a solution – at
the very least that’d provide us with a decent number of people who can
actively help out with security updates that aren’t secet and get a few
more people familiar with the technical aspects of how security updates
are released, who’ll then have less of a learning curve if they end up
being added to the security team proper. And heck, even if that
doesn’t work, it at least gives people running testing an easier url to
remember for security updates.
Of course, integrating the teams isn’t that easy, or it would’ve
already been done. So after thinking about it, I had a chat with Joey
(aka Martin Schulze, aka the guy who’s issued 317 of the 340 security
advisories in the past 12 months) about the problems:
<aj> so, the other thing i wonder is what you think of the testing-security-support split?
<Joey> need more input
<aj> as in separate host, funny domain name, not available on security.debian.org/, extra effort to mirror, etc
<aj> i think it sucks :)
<Joey> there are a lot of sucking things…
<aj> it’s true
<aj> so, i figure the reasons for the split are (a) you don’t want to add a bunch of people to team@ and hence vendor-sec, and (b) there’s no way to make it so they can use dak-security without being full team/vendor-sec members; and maybe (c) you don’t want them officially associated with debian security coz they’re newbies
<Joey> a) and b) are true
<Joey> However, with security.debian.org being a push mirror, it would be possible to let it be pushed from a second source into a different directory, such as /testing-security/
<aj> hrm
<Joey> However, that would require all architectures to be supported and not just some.
<Joey> all as in “all that are in testing”
<aj> ah, that’s (c) then – they don’t do enough for the official debian stamp
<Joey> ah ok
Assuming those really are the key factors (which might or might not
turn out true, but they seem likely) then that’s something that can
be worked on. The first point is completely out of my domain – I’ve
never been on vendor-sec, and it’s not likely something that ought to be
tweaked much anyway; vendor-sec’s a very closed list by design, and for
most security work it’s probably a distraction (testing security as is
currently operates without concerning itself with vendor-sec, AIUI); the
second points purely technical; and the third point is a combination of
technical issues and an issue of training, both of which will be hopefully
helped a lot by integrating testing-security and security.debian.org.
So the easiest point of attack is obviously the second one, since it’s
“just” a matter of expanding dak’s featureset.
The problem here is embargoed fixes – the security team needs to
be able to prepare fixes for vulnerabilities revealed on vendor-sec,
but then keep them secret from everyone not on vendor-sec until the
publication date. Which is fine, except that dak takes an all or nothing
approach to that sort of secrecy: secuirty uploads go into accepted,
get built, and then the security team run “amber” to publish the update.
But what that means is the accepted directory and its contents can only
be visible to people with vendor-sec access, which means only people
with vendor-sec access can do security updates.
But we do actually have a different queuing mechanism that allows us
to keep some things secret, while not hiding everything: thanks to the
crypto-in-main transition, the NEW queue acts like that, more or less,
only allowing ftpmaster to see the contents of NEW packages until they’ve
passed license inspections and the appropriate export notifications have
taken place. And actually, we’d already considered extending that sort
of behaviour to add an “unapproved” queue that would prevent uploads
from entering proposed-updates without the stable release manager’s
prior approval.
The idea then, would be to have a couple of queues for the security
team: an embargoed queue, accessible only to those with vendor-sec access
that would store embargoed fixed ‘til they’re ready to be released,
and an unembargoed queue for preparation accessible by a wider group,
for preparation of fixes that don’t need to be secret. Both queues would
need to be autobuilt (and the build logs for embargoed uploads would
need to stay restricted, while the build logs for unembargoed uploads
would not), which is an added difficulty, since only accepted can be
autobuilt presently. But otherwise, it seems basically plausible, both
to myself and Joey.
Conveniently,
Andrew Pollock’s been interested in throwing
some money through the AJ Market to see what happens, and since the
initial idea we were tossing around fell through due to his move to
the US, he’s put up the dosh to make the above happen. Well, strictly
the dosh to make me make the above happen, or something.
Anyway, I’m already running behind both in implementation and blogging
about it, so back to the grindstone…
(Okay, perhaps it’s not quite the feature
Mark Twain would
most like added to dak, but it’s still nifty.)
).