Re: Keeping upstream commits separate from Debian packaging commits
On 17 October 2014 16:57, Tristan Seligmann <mithrandi@mithrandi.net> wrote:
> On 17 October 2014 17:19, Dimitri John Ledkov <xnox@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 <contact@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)
> <alan@bitcoinarmory.com>"
> gpg: aka "Alan C. Reiner (Armory Signing Key)
> <etotheipi@gmail.com>"
> gpg: aka "Alan C. Reiner (Armory Signing Key)
> <alan.reiner@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 <contact@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)
> <alan@bitcoinarmory.com>"
> gpg: aka "Alan C. Reiner (Armory Signing Key)
> <etotheipi@gmail.com>"
> gpg: aka "Alan C. Reiner (Armory Signing Key)
> <alan.reiner@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.
Reply to: