<koike> ansgar, still about #821051, I didn't get the embargoed problem. We could only publish the signature when the embargoed package is publish, no?
-zwiebelbot/#debian-ftp- Debian#821051: Need support for uploading and signing EFI executables - https://bugs.debian.org/821051
<ansgar> koike: That leaks the existence of an embargoed upload, even when the actual changes are not disclosed.
<ansgar> koike: We don't want people to know "there will be an (embargoed) security update for grub soon".
<koike> ansgar, right, but we could only publish the signature after this (embargoed) security update for grub is published, no?
<jcristau> ansgar: it's not clear how to avoid that though
<ansgar> jcristau: Well, if you do the evil thing and have dak build the source package...
<jcristau> koike: no, because you need the signature to update the grub-signed package, which is what people are installing
<ansgar> That would also reduce delays and work without maintainer interaction (say binnmus).
<jcristau> so there's a catch-22
<jcristau> ansgar: that thought did occur to me, but, eww
<ansgar> When you have per-arch source packages (linux-signed-amd64), otherwise you have to wait for all builds to finish (but that is not nice either way).
<ansgar> The generated package would also go to embargoed, so no problem with disclosure.
<ansgar> The ugly part is: having automatically build source packages; having per-arch source packages.
<jcristau> would need yet another signing key
<ansgar> Yes, that too.
<jcristau> or i guess it could reuse the archive key...
<ansgar> Debian automated package building key :)
<ansgar> I don't like reusing keys for different purposes too much.
<jcristau> ack
<ansgar> But it needs to be in (some) keyring too and allowed to upload source packages (whitelisted like DM upload would be enough).
<jcristau> i'm also not sure we can get that all done and tested in time
<jcristau> and leaking the existence of a linux security update is maybe not too much of a leak, there are linux security updates all the time
<jcristau> ansgar: btw any thoughts on the timing issue, what with signing 3000 kernel modules with a yubikey needing almost half an hour?
<ansgar> jcristau: Hmm, that is quite long. Probably should run outside of cron.unchecked then.
<ansgar> Throw the .tar.xz somewhere, have a .path unit pick it up and start the-efi-signer.service ;)
<jcristau> the other option was to use an on-disk key for kernel modules.  i'm not sure i like that too much.
<ansgar> Well, eventually it won't matter either way.  Once the first priv escalation to kernel space in any module is found ;)
<ansgar> Unless one forbids rollbacks to older versions...
<jcristau> adding to the blacklist on upgrade should be possible i think
<ansgar> Is that a blacklist of all things? Or can you say everything earlier than version ${x} and include version numbers?
<jcristau> you blacklist specific binaries aiui
<jcristau> not sure if that actually works today...
<jcristau> (you can also blacklist a signing key of course)

...


<jcristau> koike: the signature needs to be part of the grub-signed source package. so you need the signature before you can update grub-signed. so you need a mechanism to get at the signature before the package is published.
<jcristau> what ansgar was suggesting was to build the -signed package in dak directly, rather than go through the "publish the signature, have a human grab it, make an updated -signed package, and upload that" process
<jcristau> which would mean signing that package with some gpg key