Skip to content

Allow split source+binary upload signing

This is an attempt to condense #816 (comment 615365) and thread into a separate issue, since it's really somewhat separate from the original topic of #816 (closed). @santiago asked for us to sort this out this quarter, as a number of (E)LTS contributors (CC @spwhitton @jspricke @tobi @utkarsh @lgarrett) have indicated that they're unhappy with using the current system.

My original intent when we were designing the package_upload and debian_pipeline workflows was that they should support Debusine acting as a buildd, in which case it would sign the binary uploads using its own key. However, at the time I didn't have a clear view of how the workflows were going to be laid out and so I didn't anticipate the scenario where a developer uploads an unsigned source package, Debusine builds it, and then we want to upload the combination of all of that together: in that case I think the cleanest approach is to have the developer sign the source .changes file and Debusine sign each of the binary .changes files, then upload all of those without merging them.

(Another possibility that was suggested is to keep merging the uploads, but inject extra fields into the merged .changes file to identify the creator of the Debusine workflow so that the ELTS repository can maintain traceability of that. I'm not opposed to injecting extra fields in principle, but as long as we're using reprepro to maintain the repository I don't think we should rely on that to authorize the .changes file; that seems too likely to end up with us having to do short-term reprepro hacking, and I don't think it should be necessary to solve this problem.)

Let's add an option or combination of options to the package_upload workflow (and its wrapping in debian_pipeline) that has the following effect:

  • the source artifact is treated as with today's require_signature: True: an ExternalDebsign task is created to wait until the creator of the workflow provides a signature
  • the binary artifacts are treated as with today's key: FINGERPRINT: for each binary artifact, a Debsign task is created to have Debusine sign the upload with the given key
  • the binary signing tasks depend on the source signing task, so Debusine doesn't sign anything until the creator of the workflow has confirmed that they're ready to go ahead
  • the PackageUpload tasks for the binary artifacts depend on the PackageUpload task for the source artifact, so that the source package is uploaded first
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information