Moritz Muehlenhoff wrote: > We could just declare arm a second-class architecture for security updates, > i.e. DSAs being released once all archs are available except arm and arm > updates being released once available. For small to medium packages most > updates would still be released in sync, since we're not available to > release updates 24/7. Yeah, that's what I was suggesting. > But we should stop withholding security updates because we wait on slow > archs. Debian was the first to fix the vmsplice root exploit. If we > had released all archs in sync we would have left most of our users > unprotected for two more days. And that advisory was initially only released for alpha, i386, amd64, ia64, and s390 -- so it wasn't only arm being too slow in that case. Perhaps arm delayed the follow-up advisory though? > > I'm also unsure based on Moritz's mail exactly what kind of speed > > they're looking for from an arm security buildd. He mentioned something > > on the order of 14 hours to build xulrunner -- would an arm box that > > builds it in 9 hours[1] be a worthwhile improvement, or will that still > > leave the security team waiting until the next day for arm to catch up? > > 9 instead of 14 would still help. I also think a second security buildd > would help: It wouldn't address the spikes of giga packages like xulrunner, > but it would help for cases, where several updates are building in > parallel. The benefits I see from such a speedup are that it would let the arm advisory arrive 5 hours faster (but still 7 hours after everything else), and that it would increase the number of packages that wouldn't need a delayed advisory for arm. Accurate? -- see shy jo
Attachment:
signature.asc
Description: Digital signature