Secure boot signing infrastructure - feedback request
Ben Hutchings
ben at decadent.org.uk
Wed Nov 22 22:16:42 UTC 2017
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20171122/83804ac0/attachment.sig>
More information about the Pkg-grub-devel
mailing list