Hi,

please add an option -S that will be passed through to the commit
so it’s signed as with “git commit -S”.

Hello,

Bug #913772 in pristine-tar reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/pristine-tar/commit/2d3495360059cde9ae58a9130d7eafae48bc6c4a
------------------------------------------------------------------------
allow to sign tarball commits with --git-gpg-sign=KEYID (Closes: #913772)
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/913772

Hi!

This feature would be very useful, and potentially a requirement for
being able to use pristine-tar in tag2upload for additional
confirmation that the pristine-tar branch commit was really done by
the DD who has permission to upload.

However the commit that implemented it in
https://salsa.debian.org/debian/pristine-tar/commit/2d3495360059cde9ae58a9130d7eafae48bc6c4a
was only ever on branch 'master-tmp', not in any pristine-tar release.

Hi Otto,
implementing this, pristine-tar commit signatures would not get used at
all. You can follow the progress at https://bugs.debian.org/1106071

Bye!

Andrea Pappacoda writes ("Re: pristine-tar: please add -S (sign commit) option"):

Indeed.

Also, I have very strong reservations about git signed commits.
I even wrote a whole blog post (back in 2018):

  git signed commits are a bad idea
https://diziet.dreamwidth.org/515.html

That's written from my background as a cryptographic protocol
designer.

Ian.

Perhaps, but this is used beyond tag2upload after all. Not everyone
even wants to switch to that.

bye,
//mirabilos

Thorsten Glaser writes:

I don't understand.  My reservations about git signed commits are
nothing to do with tag2upload.  Indeed, I wrote that article in
2018, before Sean and I even conceived tag2upload.

git signed commits are not a good idea and IMO should usually not be
used, for anything.  For the reasons I explain in my article.

So, I don't think signed commits are a good thing to be using in
pristine-tar.

Ian.

Hi!

I agree that the arguments put forward in
https://diziet.dreamwidth.org/515.html make sense, but please consider
that the exact same arguments can be used to justify that signing
commits on the pristine-tar branch is for now fine, as there is no
system in place to replace it with signed pushes to salsa.debian.org,
nor are people publishing "draft" versions of pristine-tar but 99% of
the time it is real and final imports of upstream releases.

Signing commits will clearly improve the current situation where
salsa.debian.org hosts a bunch or pristine-tar branches that have no
signatures whatsoever nor do their commit ids fold into any other
branch that would have signatures. Also note that Tomasz already
implemented https://salsa.debian.org/debian/pristine-tar/commit/2d3495360059cde9ae58a9130d7eafae48bc6c4a,
it just got forgotten on the branch 'master-tmp'.

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.

Your article explains that very well *for a limited set of use cases*.
If one’s threat scenario (or whatever) differs, it is still possible
that using it is better than not using it.

bye,
//mirabilos

Thorsten Glaser writes ("Re: pristine-tar: please add -S (sign commit) option"):
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"):

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.
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.

For your use case.

Yes. But there are use cases where this does not matter, as shocking
as this may seem to the unsuspecting developer.

bye,
//mirabilos

Hi,

Check. The files PACKAGE_UPSTREAMVERSION.{id,xdelta,sig} are added by
pristine-tar in one single commit, at the time of import.

Check. The signature covers that one commit.
If somebody later does "administrative commits" (should not really
happen) the person using the git branch going forward will need to
review/trust those extra commits, whatever they are.

I am not sure what the last bullet point means. There is only ever one
single version of the upstream tarball for a given upstream version.
If I import upstream 1.1.1 and then upload it to both Trixie and
Bookworm, the one and the same pristine-tar commit and its files will
suffice. There are multiple commits and a signature for each, so I
think this is also a "check".

..

Yes, this would work too.

However this would need to be done by git-buildpackage and not in
pristine-tar (where we are now discussing it), and perhaps defined as
an addendum to DEP-14? Since we want to have a mechanism that will be
created and read by multiple different software, perhaps DEP-14 could
be a good vehicle to spec this and have all implementors agree on it?

Summary of the overall situation:

 As an expert with a PhD, and years of practical experince, in
 cryptographic protocols, I remain of the view that git commit
 signatures are an exceptionally poor design, and unsuitable for most
 of their apparent use cases.

 git signed commits are IMO definitely wrong for pristine-tar.  If
 pristine-tar data is to be be signed, the starting point should be a
 proper consideration of the needs and behaviour of the software (and
 user) who will perform the verification.

 Until then, no changes should be made to add ill-conceived "security
 features" (even if they are popular, and even if they produce a
 reassuring but meaningless green indication in certain web UIs).

 I probably won't be responding to this thread again on this topic.
 Please don't take my lack of response as an indication that presented
 counterarguments are valid.  If explicitly asked, I will be happy to
 say whether I am convinced.


Otto Kekäläinen writes ("Re: pristine-tar: please add -S (sign commit) option [and 1 more messages]"):

There can be multiple upstream versions simultaneously, for different
suites.  In the normal workflow these are represented as multiple
files within the HEAD of the pristine-tar branch.

If a signature is to be verified it ought (generally) to be the one
made when the tarball was imported.  Not one made later when a
subsequent tarball was imported.  Doing this with git commit
signatures on the prstine-tar branch would be very fiddly, and a naive
use of the commit signature verifies the wrong signature.

I think before pushing these ideas further we should think about what
sofware is going to verify the signatures and how those signatures
would influence the software's behaviour.

An example of a bad pattern not to follow, is dpkg-source, which
always tries to verify a signature but merely grumbles on stderr when
one is missing or fails to verify.  In practice this specific warning
message is ubiquitous during Debian development, and does not
represent an out-of-course situation, let alone any kind of problem.

Possibly we would wamt pristine-tar to verify the signature before
constructing the output tarball and decline to operate if the
verification fails.  But it's not clear why the prstine-tar branch
deserves this treatment when the main branch doesn't.

Ian.