I'm currently a bystander. And while I reply to Joerg's mail, I'm not directly referencing any of the points in his mail, so no quotes.
I'd like to point out though, that signing the content of the package is not possible if the developer should only need to do `git $something`.
They would also need to generate the source package, as I don't see a guarantee that regenerating the source package from the same git tag (by t2u) would necessarily result in a bitwise identical source package.
What would be possible would be (if dak has sufficient network access) to check the signed git tag that t2u used and re-check the signature on that. The problem remains that this only verified that the tag was set, not that t2u actually used the code that tag points to. That would again require trust in t2u or reproducible source package builds (and for dak to rebuild from the git repo).
In essence: I don't see how to fulfill the mentioned requirements by ftpmasters while keeping the workflow of developers minimal. The only way I see to fulfill them is to have the workflow that t2u is supposed to simplify and host actually run on the developer-controlled machines instead of a centralized service. Which defeats the purpose IMHO.
So there are two options:
1) FTPmaster&dak trust the tag2upload services security and authentication and only (re) check authorization (optionally with reading the git repo to re-verify the signature on the tag, but still needing to trust that tag2upload really took the code at that tag to create the package.
2) tag2upload only provides the developer with the generated source package for them to (re)sign and upload. That would defeat the purpose.
(The third option would be to let tag2upload die as a service and at best run on each developers machine to somewhat automate their own process.)
Kind regards,
Sven
