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]"):
> [Ian:]
> > - Multiple signatures must be simultaneously available,
> > for multiple upstream imports (eg targeting different suites).
>
> 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.
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.
--
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.
