sign git tag v0.9.0 (or commit)

[adrelanos]

Could you please sign git tag v0.9.0 and or that commit pointing at v0.9.0?

Commits of previous releases were signed.

[solardiz]

We'll need to decide on commit/tag signing in general (so far, only Adam's commits in this repo are signed), but meanwhile you can verify the signature on the 0.9.0 release tarball on the Openwall website, and if you intend to use git then confirm that the trees are identical (perhaps with diff -urNx .git -x .gitattributes -x .mailmap).

For commit/tag signing in general, what is the best practice here for a project with many contributors? Any example project you suggest we take a look at?

BTW, the tags I created for these two releases are not annotated. I think this means they can't be signed on their own - only the commits can be. Should we use annotated tags instead? Perhaps that could be a solution allowing anyone's commit to become the release, yet have the release tag signed by a project leader (perhaps Adam or me)?

I'd also like to hear from @ldv-alt on these matters.

Commits of previous releases were signed.

The commit corresponding to v0.8.1 is also not signed. Older releases were not even tagged. (Maybe we should tag them retroactively.)

[adrelanos]

Thank you for your consideration!

For commit/tag signing in general, what is the best practice here for a project with many contributors?

Signing all (or most) commits leaves an audit track.

A long time since I looked into this. Last time I did I concluded it's best if all (new) git commits and (news) tags are signed. That makes manipulation by a mitm more difficult / easier to notice.

References:
https://forums.whonix.org/t/how-safe-are-signed-git-tags-only-as-safe-as-sha-1-or-somehow-safer/643

Any example project you suggest we take a look at?

Qubes and Whonix.

https://www.qubes-os.org/doc/code-signing/

Qubes and Whonix developers sign all commits as well as git tags.

BTW, the tags I created for these two releases are not annotated.

That is OK. No meaningful tag message required.

Perhaps that could be a solution allowing anyone's commit to become the release, yet have the release tag signed by a project leader (perhaps Adam or me)?

I'd prefer the the signed commit that becomes the release being from a project leader. Why? Because I already have the public keys of the project leaders but not of all contributors. Thereby I can verify the signature of any commit at any time and be assured that any contribution was reviewed, merged by at least one project leader.

Another reason is that sometimes LKRG is releasing fixes in git but without corresponding release tag. Therefore signed git commits are even more important than signed git tags. Because people not capable of auditing the diff from last signed tag to last commit would otherwise have no way to gpg verify they got the code from the actual developers, without mitm manipulating things.

(Maybe we should tag them retroactively.)

Unless someone requesting that, I'd suggest saving the extra effort for that.

[adrelanos]

Wondering if I may request prioritization of this issue, signed commit or tag creation please?
(recent release only more than good enough)

That would really help with keeping the Debian package https://www.whonix.org/wiki/Linux_Kernel_Runtime_Guard_LKRG as up to date as it used to be.

Reason is if I use the signed LKRG archives, extract and and commit to git Whonix/lkrg that then all files, all of LKRG would be easily confused as authored by me which I very much want to avoid.

[solardiz]

Thank you for the reminder. Frankly, this is currently still low among my priorities.

if I use the signed LKRG archives, extract and and commit to git Whonix/lkrg

Of course, don't do that. Instead, you can diff the tree in the signed tarball against the tree obtained after git checkout of the corresponding tag. Once you've confirmed they're identical, you can use that git tree knowing that at least that one revision is the same as what's signed. This doesn't verify past commits (it is possible to have alternate history arriving at the same point), but most people won't be running code using those.

Of course, the above is no excuse not to proceed with making more frequent releases with signed git tags.