Hi,
> Ie, the key points
> - The signature shoud be made when importing a new upstream release
Check. The files PACKAGE_UPSTREAMVERSION.{id,xdelta,sig} are added by
pristine-tar in one single commit, at the time of import.
> - 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.)
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.
> - 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.
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".
..
> 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).
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?
