a guest Nov 29th, 2016 92 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. <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?
  2. -zwiebelbot/#debian-ftp- Debian#821051: Need support for uploading and signing EFI executables -
  3. <ansgar> koike: That leaks the existence of an embargoed upload, even when the actual changes are not disclosed.
  4. <ansgar> koike: We don't want people to know "there will be an (embargoed) security update for grub soon".
  5. <koike> ansgar, right, but we could only publish the signature after this (embargoed) security update for grub is published, no?
  6. <jcristau> ansgar: it's not clear how to avoid that though
  7. <ansgar> jcristau: Well, if you do the evil thing and have dak build the source package...
  8. <jcristau> koike: no, because you need the signature to update the grub-signed package, which is what people are installing
  9. <ansgar> That would also reduce delays and work without maintainer interaction (say binnmus).
  10. <jcristau> so there's a catch-22
  11. <jcristau> ansgar: that thought did occur to me, but, eww
  12. <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).
  13. <ansgar> The generated package would also go to embargoed, so no problem with disclosure.
  14. <ansgar> The ugly part is: having automatically build source packages; having per-arch source packages.
  15. <jcristau> would need yet another signing key
  16. <ansgar> Yes, that too.
  17. <jcristau> or i guess it could reuse the archive key...
  18. <ansgar> Debian automated package building key :)
  19. <ansgar> I don't like reusing keys for different purposes too much.
  20. <jcristau> ack
  21. <ansgar> But it needs to be in (some) keyring too and allowed to upload source packages (whitelisted like DM upload would be enough).
  22. <jcristau> i'm also not sure we can get that all done and tested in time
  23. <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
  24. <jcristau> ansgar: btw any thoughts on the timing issue, what with signing 3000 kernel modules with a yubikey needing almost half an hour?
  25. <ansgar> jcristau: Hmm, that is quite long. Probably should run outside of cron.unchecked then.
  26. <ansgar> Throw the .tar.xz somewhere, have a .path unit pick it up and start the-efi-signer.service ;)
  27. <jcristau> the other option was to use an on-disk key for kernel modules.  i'm not sure i like that too much.
  28. <ansgar> Well, eventually it won't matter either way.  Once the first priv escalation to kernel space in any module is found ;)
  29. <ansgar> Unless one forbids rollbacks to older versions...
  30. <jcristau> adding to the blacklist on upgrade should be possible i think
  31. <ansgar> Is that a blacklist of all things? Or can you say everything earlier than version ${x} and include version numbers?
  32. <jcristau> you blacklist specific binaries aiui
  33. <jcristau> not sure if that actually works today...
  34. <jcristau> (you can also blacklist a signing key of course)
  36. ...
  39. <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.
  40. <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
  41. <jcristau> which would mean signing that package with some gpg key
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand