On 17 October 2014 17:19, Dimitri John Ledkov <x...@debian.org> wrote:
> There are different tag types in git. "Soft" are just named commit
> references and indeed can be renamed at will / point to new commits,
> however signed tags encode:
> object SHA1id
> type type-of-above
> tag tag-name
> tagger normal user name, email, timestamp
>
> tag-message
>
> All signed with gpg. Thus any change to that metadata of a signed tag
> will invalidate signature, or be treated as conflicting tag and thus
> require --force push.
I stand corrected, tag objects do indeed include a name. However, this
name does not have to be the same as the name of the ref to that tag!
For example, in a package I recently helped sponsor[1]:
mithrandi@lorien ~/d/p/armory> git tag -l | grep 0.92.3
debian/0.92.3-1
upstream/v0.92.3
mithrandi@lorien ~/d/p/armory> git tag -v upstream/v0.92.3
object 268db0f3fa20c989057bd43343a43b2edbe89aeb
type commit
tag v0.92.3
tagger Armory Technologies, Inc <cont...@bitcoinarmory.com> 1412648447 -0400
Tor privacy fixes and msg signing RNG fix
gpg: Signature made Tue 07 Oct 2014 04:20:47 SAST using RSA key ID 98832223
gpg: Good signature from "Alan C. Reiner (Offline Signing Key)
<a...@bitcoinarmory.com>"
gpg: aka "Alan C. Reiner (Armory Signing Key)
<etothe...@gmail.com>"
gpg: aka "Alan C. Reiner (Armory Signing Key)
<alan.rei...@gmail.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223
You'll notice that I've prefixed the upstream refs with upstream/ in
order to organise them; it is possible to do this automatically with a
configuration like:
git config remote.upstream.tagopt --no-tags
git config --add remote.upstream.fetch '+refs/tags/*:refs/tags/upstream/*'
However, the name does not match the standard git-buildpackage naming
scheme exactly (prefixed with 'v'), so setting --git-upstream-tag is
necessary. You could avoid this at the cost of having to fetch each
tag manually, with something like:
mithrandi@lorien ~/d/p/armory> git fetch upstream
+refs/tags/v0.92.3:refs/tags/upstream/this-is-nonsense
>From github.com:etotheipi/BitcoinArmory
* [new tag] v0.92.3 -> upstream/this-is-nonsense
mithrandi@lorien ~/d/p/armory> git tag -v upstream/this-is-nonsense
object 268db0f3fa20c989057bd43343a43b2edbe89aeb
type commit
tag v0.92.3
tagger Armory Technologies, Inc <cont...@bitcoinarmory.com> 1412648447 -0400
Tor privacy fixes and msg signing RNG fix
gpg: Signature made Tue 07 Oct 2014 04:20:47 SAST using RSA key ID 98832223
gpg: Good signature from "Alan C. Reiner (Offline Signing Key)
<a...@bitcoinarmory.com>"
gpg: aka "Alan C. Reiner (Armory Signing Key)
<etothe...@gmail.com>"
gpg: aka "Alan C. Reiner (Armory Signing Key)
<alan.rei...@gmail.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223
And thus name the ref whatever you like locally, regardless of what
upstream's name is. Since all of the commands that operate on a
revision take the ref name as an argument, not the actual name given
in the tag object, this is all that matters for things like
pristine-tar (which just records the commit id regardless of how you
identify the commit to use) and git-buildpackage.
The value of this is questionable if the upstream tags are unsigned,
especially if the released source tarballs *are* signed (in which case
they can be verified by uscan...but only as long as they continue to
be published, since the upstream signature is not kept anywhere in
Debian). In the case of Armory, upstream does not publish source
tarballs at all, only binary releases; the primary source release
mechanism is through signed tags in their git repository, so I felt it
was worth the extra contortions to handle the upstream tags /
orig.tar.gz this way (the upstream tag in the packaging repository can
still be verified, as shown above). I did end up writing a 36 line
README.source discussing this process however... so I'm not sure how
suitable it is for the average DPMT/PAPT-maintained package.
[1] The git repository is at
https://anonscm.debian.org/git/pkg-bitcoin/armory.git -- browse link
is https://anonscm.debian.org/cgit/pkg-bitcoin/armory.git
--
mithrandi, i Ainil en-Balandor, a faer Ambar
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/camckhmsn0trwfex97kylkqq5w-uyeeomcwtb0cwf_o9c7ez...@mail.gmail.com
