On Tue, 2017-10-10 at 13:19 +0100, Steve McIntyre wrote: > On Mon, Oct 09, 2017 at 07:00:14PM +0100, Ben Hutchings wrote: > > On Mon, 2017-10-09 at 17:38 +0100, Steve McIntyre wrote: [...] > > > What human intervention are you wanting here? > > > > A human decides when processing the BYHAND queue whether this binary > > upload looks reasonable. If it's built from an NMU, I would hope this > > gets extra scrutiny (perhaps including a query to the maintainer). > > (Ideally that would happen at the source upload stage for packages that > > get code-signed. I'm not sure if that's possible to do.) > > The plan for the ftpmaster route (as communicated to me) was *not* > necessarily going to need actual manual processing of the BYHAND queue > for bits needing signing. Is that something we can (should?) > legitimately expect - every signed package to get extra manual > checking by ftpteam? The rate of source package uploads requiring binaries to be signed should not be very high. Looking at the upload history of linux and grub2, I would say no more than twice a week on average. I would assume (maybe wrongly) that the byhand uploads of binaries could then be dealt with in batches. For kernel uploads, only the kernel image should require signing with an HSM, so the signing process should not be nearly as slow as Julien reported. (And if I manage to implement Merkle hashing of modules, they won't need to be signed at all.) [...] > On the flip side, how far are we going to get if we can't trust the > buildds? Reproducibility helps, but only if the source uploader can > already generate matching builds for all the packages on all the > architectures we want to support. [...] It would be desirable to reduce the amount of trust we put in any given buildd. I feel that allowing them to get signatures at any time is going in the opposite direction. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein
Attachment:
signature.asc
Description: This is a digitally signed message part