On 17 October 2014 16:57, Tristan Seligmann <mithra...@mithrandi.net> wrote: > 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]: >
LOLz!!! was my initial reaction. But honestly, this does sounds a bit broken =) I was not aware of this property. It does make sense that a signed tag object has unique sha1 and thus one can create multiple tags named "foo" with different sha1 IDs and thus store them in a single git object store without ref names and/or different ref names. However the implications of this are rather severe - what if I copy/rename v1.0.3 tag as a v1.0.5 tag in my mirror and thus trick people into an older version... I'm concerned by this, I'll checkout git mailing list and/or raise this issue there. For some time now I have switched to providing people with sha1id of a GPG signed commit, instead pushing signed tags and providing a signed tag name only. That was only for the sake of minimising amount of refs i publish/pollute. I guess this is for the best. Regards, Dimitri. > 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 -- Regards, Dimitri. -- 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/CANBHLUhF=fK2pjFfujjxQHYAd_VXHo1CCndqVXSvY43=ifg...@mail.gmail.com
