# Verify gentoo git. Best practices?

## mv

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

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?

----------

## NeddySeagoon

VinzC,

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

----------

## krinn

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

 *NeddySeagoon wrote:*   

> VinzC,
> 
> To do the resigning, the attacker would need the private key.

 

Then there's something I don't understand: what private key?

EDIT: Been scratching my head but I think I get it now. You mean "the hacked account's private key", right? I understand why I didn't get it in the first place  :Very Happy:  .

That said, assuming all Gentoo devs use signing, what if the attacker creates another key pair for the hacked account — impersonating it or not, would that make a difference — and signs their commits with that private key? Is it plausible the code ransacking could be more insidious? I guess GitHub reporting tools would have the rogue commits nailed anyway, correct? Just thinking aloud.

----------

## krinn

 *VinzC wrote:*   

> That said, assuming all Gentoo devs use signing, what if the attacker creates another key pair for the hacked account — impersonating it or not, would that make a difference — and signs their commits with that private key? Is it plausible the code ransacking could be more insidious? I guess GitHub reporting tools would have the rogue commits nailed anyway, correct? Just thinking aloud.

 

The process is easy to get:

* you create keys (public and private)

* you store the public key in some server

* you use the private key to sign the tree

* you store tree in github

* when user download the tree, portage will download the public key (so not from github) and check if "that" key was use to sign the tree

So if someone sign the tree, still portage will not download the hacker's keys, but gentoo ones. And this fail.

In order to create a valid combo to hack gentoo user, you must sign tree with your key, and hack the key server to offer your own key to gentoo users.

that's all there:

```
 * Using keys from /usr/share/openpgp-keys/gentoo-release.asc

gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net 
```

----------

## mv

 *krinn wrote:*   

> that's all there:
> 
> ```
>  * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
> 
> ...

 

Only with the difference that gentoo-release.asc contains essentially just one key (and not any key which one would need to verify validity of the gentoo repository).

This is the question which I had posted: Are there any practical means currently to get the correct keys?

Due to the discussion which is parallel in gentoo-user ml and since no-one else posted an idea, it seems clear that currently the answer is: no.

Currently, using the git (source) repository is insecure since one cannot verify signatures!

(For gentoo-mirror the situation is different, since these have additional signatures by only the above key. Whether this signature is based on verification of the other keys or not, I don't know. If it is, maybe it would be relatively simple to provide these keys also to the user?)

----------

## krinn

yeah sorry, not for git tree currently of course.

----------

## khayyam

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

 *VinzC wrote:*   

> That said, assuming all Gentoo devs use signing, what if the attacker creates another key pair for the hacked account — impersonating it or not, would that make a difference — and signs their commits with that private key? Is it plausible the code ransacking could be more insidious? I guess GitHub reporting tools would have the rogue commits nailed anyway, correct? Just thinking aloud.

 

 *krinn wrote:*   

> The process is easy to get:
> 
> * you create keys (public and private)
> 
> * you store the public key in some server
> ...

 

I see. And those keys are distributed with app-crypt/openpgp-keys-gentoo-release, right? That scenario would require the keys to be installed on all Gentoo machines, users' included, is that correct?

 *khayyam wrote:*   

> 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 

   :Laughing: 

----------

## krinn

mv: before i forget  :Smile: 

https://bugs.gentoo.org/660372

 *VinzC wrote:*   

> And those keys are distributed with app-crypt/openpgp-keys-gentoo-release, right?

 

didn't check it for real, but i think that's how it's done yes.

----------

## mv

 *krinn wrote:*   

> mv: before i forget :)
> 
> https://bugs.gentoo.org/660372

 

This patch only helps if you are using the mentioned gentoo-mirrors for which the gentoo-release key is sufficient.

For the gentoo source repository this patch will just have the effect that you are not able to sync it anymore (unless you disable verification).

----------

