Verify gentoo git. Best practices?

mv · Watchman Joined: 20 Apr 2005 Posts: 6749

After the github hack it appears more important than ever to recommend best practices for verifying gpg key signatures.

For rsync repositories, there is gemato with explicit recommendations.

Unfortunately, rsync does no longer provide ChangeLogs, and for this reason perhaps git is for many users still the preferred way of syncing.
But git comits are not signed by a single gentoo-release key but only by the single developers of the last commit.

It does not seem possible to get these keys in a "bulk", or is it?

Due to the way how git works, it would be sufficient to verify the to commit of HEAD.

But how does one do this in practice? What are you using?

My thoughts about it:

There is is app-crypt/gkeys, but it seems to be dead: gkeys-gpg cannot be used with --verify (the python code for this is simply buggy and has not been fixed although the bug has been reported years ago); even after fixing the obvious bugs, it is unclear to me how it is supposed to be used; if it is specified to git as gpg program, it still does not work.
I had written my own replacement for gkeys-gpg using the keys fetched from gkeys.
However, it is unclear to me how gkeys can be used to update the keys/seeds regularly and to remove outdated keys.

Alternatives are to manually check the "verified" box in github, but this is of course very cumbersome for every sync.

Does anybody have better recommendations? Or is gkeys still the recommended way and I am just using it incorrectly?

VinzC · Posted: Sun Jul 08, 2018 2:49 pm Post subject:

Sorry for jumping in on a probably inopportunte moment but there's something I don't quite get. I [think I] understand the point of signature and verification but I fail to see a point here: from what I understand of the hack, somebody managed to somhow "corrupt" source files on a Gentoo repository, right? Now to my question: what would code signing bring here? I mean if someone manages to "corrupt" source files *and* by the way also sign those changes, what would we, users, who have absolutely no clue of who's who in the Gentoo team, benefit from verifying keys?

Verifying leys on the user's side might always lead to successful verification of code that actually is malware, am I right? So to me it's more of a Gentoo insider issue: only Gentoo dev's — or the people officially granted access to the GIT repo — know who made changes *and* can be trusted.

Did I miss something?
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!

NeddySeagoon · Posted: Sun Jul 08, 2018 2:57 pm Post subject:

VinzC,

To do the resigning, the attacker would need the private key.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

krinn · Watchman Joined: 02 May 2003 Posts: 7470

mv: i think git is next on their todo list, but i cannot put my hands on the link ; i'm a bit useless so, let's just say at least that next logical step then?

VinzC · Posted: Sun Jul 08, 2018 3:22 pm Post subject:

krinn · Watchman Joined: 02 May 2003 Posts: 7470

mv · Watchman Joined: 20 Apr 2005 Posts: 6749

krinn · Watchman Joined: 02 May 2003 Posts: 7470

yeah sorry, not for git tree currently of course.

khayyam · Posted: Sun Jul 08, 2018 5:27 pm Post subject:

mv ...

best practices? What I normally do is place a peice of cheese by the hole and wait with a hammer for the git to get hungry ... and there endeth the parable :)

best ... khay

VinzC · Posted: Sun Jul 08, 2018 5:34 pm Post subject:

krinn · Watchman Joined: 02 May 2003 Posts: 7470

mv: before i forget

https://bugs.gentoo.org/660372

mv · Watchman Joined: 20 Apr 2005 Posts: 6749