On Mon, 2018-05-14 at 22:05 +0900, Hideki Yamane wrote: > Hi, > > Thanks, your explanation is really helpful. > > > > The signing service is a source package builder. > > It build source package but its source package is based on built binary package? > As I understand, singing to binary is necessary step. Right. > 1. source package > 2. -> upload to dak > 3. -> passed to buildd > 4. -> binary package built And one of those binary packages is a "template" for the source package. This is documented on the Etherpad, but in short it contains an unpacked source package with everything except the signatures, plus a configuration file specifying which binaries in which packages need to be signed. > 5. -> singing service pull those > 6. -> source package built This is the template source package plus all the (detached) signatures that were specified in the configuration. > 7. -> dak, again > 8. -> buildd, again Here there are build-dependencies on the previously built binaries, and the build process adds the detached signatures to those binaries. > 9. -> dak passes those to repo > > > And in previous report > > > We're still missing (partially or completely): > > - generate a signing template for GRUB2 > > - have DAK accept those generated source-only uploads > > This is 7th step in above, right? The second point (have DAK accept ...) is part of step 7, yes. It seems to have been implemented now. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison
Attachment:
signature.asc
Description: This is a digitally signed message part