Thorsten Glaser writes ("Re: pristine-tar: please add -S (sign commit) option"):
> Your article explains that very well *for a limited set of use cases*.
No. It is a fully general argument that git signed commits have the
wrong data model. The signature covers the wrong thing. It omits the
target branch and therefore the status of the signed thing. This make
the signature ambiguous, and almost impossible to safely rely on.
I will try to help with the cryptographic protocol design. This is a
field that I have considerable experience in, and also a formal
academic background (part of my PhD dealt with things in this area).
So:
Otto Kekäläinen writes ("Re: pristine-tar: please add -S (sign commit) option"):
> Signing commits will clearly improve the current situation where
> salsa.debian.org hosts a bunch or pristine-tar branches that have no
> signatures whatsoever
It seems to me that if there are going to be signatures, they ought to
be an approval of the specific pristine-tar metadata, for a particular
release.
So aa person who importa a new upstream release ought to sign the
*new* metadaa, but their signature ought not to cover *old* metadata.
The signature made by the previous import ought to remain undisturbed.
Ie, the key points
- The signature shoud be made when importing a new upstream release
- The signature should semanntically cover only that the
information related to that upstream release.
(The signature hash might cover other things for convenience
reasons but those aren't part of the semantics.)
- Multiple signatures must be simultaneously available,
for multiple upstream imports (eg targeting different suites).
I don't think commit signatures can readily do that.
Since pristine-tar metadata consists of multiple files per import, it
would be possible to sign a companion file with their checksums.
Something like this:
sha256sum PACKAGE_UPSTREAMVERSION.{id,xdelta,sig} |
gpg --clearsign |
PACKAGE_UPSTREAMVERSION.import_signature.asc
and put the file PACKAGE_UPSTREAMVERSION.import_signature.asc
inside the git branch.
> I guess he could rewrite it to sign git tags and tag every single
> commit on the pristine-tar branch, but the practical difference to
> signing the commits isn't big.
I think you mean "make a signed tag per import". Normally imports
correspond one-to-one to commits on the pristine-tar branch but that
is not necessarily true: administrative operations can edit the branch
contents.
One tag per import is cryptographically sound, because the tag name
then includes the (Debianised) upstream version number. So the
signature's intent is unambiguous. But there is a risk of confusion,
due to the signature covering a lot more than it needs to. And so
many extra tags might be unwieldy.
Another option would be to use the DEP-14 upstream/ tag. As I
understand most pristine-tar workflows, we typically generate a fresh
tag with the DEP-14 name. I think that tag is often signed?
We could put the pristine-tar integrity information into the
upstream/ tag, in the tag message body (in a machine-readable and
unambiguous form).
That integrity information could be a sha256sum as I suggest above.
Or it could be a git object name, but I think there are a few
technical reasons why sha256sums of the pristine-tar data for the
particular commit are best.
The final problem with most of these schemes is this: what happens if
the original tag signer retires? Their key leaves the keyring and now
their signature is unverifiable.
Normally this problem doesn't arise with uploads because they are
processed soon after signature.
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
