Commits signed by key not registered on Savannah

Commits signed by key not registered on Savannah

[Mark H Weaver]

Hi David,

david@craven.ch (David Craven) writes:
> dvc pushed a commit to branch master
> in repository guix.
>
> commit a5bc3dfeaac3b5f04702a0e24c99b0c44a2422af
> Author: David Craven <david@craven.ch>
> Date:   Mon Jan 16 23:37:21 2017 +0100
>
>     gnu: Add ovmf.
>     
>     * gnu/packages/grub.scm (edk2-commit, edk2-version, edk2-origin, ovmf): New
>       variables.

According to "git log --show-signature" on my machine, several recent
commits by you (including this one) were signed with a different key
than the one you have registered on Savannah.  Savannah has key
C5E051C79C0BECDB, but your recent commits were signed with key
33B9E9FDE28D2C23.  How are we to confirm the authenticity of this key
and of these commits?

    Regards,
      Mark

Re: Commits signed by key not registered on Savannah

[David Craven]

> According to "git log --show-signature" on my machine, several recent
> commits by you (including this one) were signed with a different key
> than the one you have registered on Savannah.  Savannah has key
> C5E051C79C0BECDB, but your recent commits were signed with key
> 33B9E9FDE28D2C23.  How are we to confirm the authenticity of this key
> and of these commits?

Hi Mark,

I revoked my old key and published a new one to mit.edu. I mentioned
it in an email that I lost access to my previous key - I know - shame
on me - and if it was ok to simply regenerate a key and start signing
with it. I did not get a reply and assumed that keys expire and are
revoked from time to time so it must be ok. Please let me know what I
can do to remedy this issue.

Thank you,
David

Re: Commits signed by key not registered on Savannah

[Ludovic Courtès]

David Craven <david@craven.ch> skribis:

>> According to "git log --show-signature" on my machine, several recent
>> commits by you (including this one) were signed with a different key
>> than the one you have registered on Savannah.  Savannah has key
>> C5E051C79C0BECDB, but your recent commits were signed with key
>> 33B9E9FDE28D2C23.  How are we to confirm the authenticity of this key
>> and of these commits?
>
> Hi Mark,
>
> I revoked my old key and published a new one to mit.edu. I mentioned
> it in an email that I lost access to my previous key - I know - shame
> on me - and if it was ok to simply regenerate a key and start signing
> with it. I did not get a reply and assumed that keys expire and are
> revoked from time to time so it must be ok. Please let me know what I
> can do to remedy this issue.

I don’t remember seeing that message.

We still have little infrastructure in place around signed commits, but
we should definitely have a process for changing keys.  When switching
to a new key, we should make sure to let everyone else know.

Ludo’.

Re: Commits signed by key not registered on Savannah

[Mark H Weaver]

Hi David,

David Craven <david@craven.ch> writes:

>> According to "git log --show-signature" on my machine, several recent
>> commits by you (including this one) were signed with a different key
>> than the one you have registered on Savannah.  Savannah has key
>> C5E051C79C0BECDB, but your recent commits were signed with key
>> 33B9E9FDE28D2C23.  How are we to confirm the authenticity of this key
>> and of these commits?
>
> Hi Mark,
>
> I revoked my old key and published a new one to mit.edu. I mentioned
> it in an email that I lost access to my previous key - I know - shame
> on me

It's okay, I've lost keys sometimes too :-(

> - and if it was ok to simply regenerate a key and start signing
> with it. I did not get a reply and assumed that keys expire and are
> revoked from time to time so it must be ok. Please let me know what I
> can do to remedy this issue.

It would be good to upload your new key to Savannah.  Preferably, the
public key block associated with your account on Savannah would include
both your old and new public keys.

    Thanks,
      Mark

Re: Commits signed by key not registered on Savannah

[Mark H Weaver]

I wrote:
> Preferably, the public key block associated with your account on
> Savannah would include both your old and new public keys.

Sorry, my request above was ill-considered, and I hereby revoke it.
I now believe that you should register only your new key on Savannah.

It might be nice to associate with each committer, a list of all keys
that they have ever used to sign commits in our git repository.  Keys
would be added to the list over time, but never removed.  The
conventional usage of Savannah's ssh key registry is to include only
currently active keys, and that's needed as well.

What do you think?

      Mark

Re: Commits signed by key not registered on Savannah

[David Craven]

> It might be nice to associate with each committer, a list of all keys
> that they have ever used to sign commits in our git repository.

> Keys would be added to the list over time, but never removed.

Sounds good. Where would we put that list? And does that list also
need to be signed? Puh, lucky for me I don't have to be responsible
for that key =P

For now my public keys are published on mit.edu, so they shouldn't be lost
and can be retrieved when this list materializes.

>  The conventional usage of Savannah's ssh key registry is to include only
> currently active keys, and that's needed as well.

I updated the key.

Re: Commits signed by key not registered on Savannah

[ng0]

On 17-02-12 00:41:38, David Craven wrote:
> > It might be nice to associate with each committer, a list of all keys
> > that they have ever used to sign commits in our git repository.
> 
> > Keys would be added to the list over time, but never removed.
> 
> Sounds good. Where would we put that list? And does that list also

Would the git repository, or a new git repository (guix-keys.git?) be a
bad idea? Best case, we craft something which serves as an GNUPG_HOME
for the keys which then live in the keyring of this thing (compare to
gentoo-keys, debian-keys, etc).

> need to be signed? Puh, lucky for me I don't have to be responsible
> for that key =P
> 
> For now my public keys are published on mit.edu, so they shouldn't be lost
> and can be retrieved when this list materializes.
> 
> >  The conventional usage of Savannah's ssh key registry is to include only
> > currently active keys, and that's needed as well.
> 
> I updated the key.
> 

-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Commits signed by key not registered on Savannah

[David Craven]

> Would the git repository, or a new git repository (guix-keys.git?) be a
> bad idea? Best case, we craft something which serves as an GNUPG_HOME
> for the keys which then live in the keyring of this thing (compare to
> gentoo-keys, debian-keys, etc).

I don't think that is a good idea. Placing it in the same git
repository that we are trying to verify means that if an ssh key has
been compromised, someone could add a malicious commit and a public
key - since this means that developers would be expected to manage
their own public keys in this list, it may not even be suspicious. If
someone MiM cuirass <-> savannah it would not even show in our view of
the repo.

The integrity of our source code is given by peer review - we are
subscribed to the commits ML so we see other peoples commits.

The most important thing is verifying that the substitutes come from
signed and verified commits only. Maybe keys need to be stored in the
cuirass configuration.

Re: Commits signed by key not registered on Savannah

[Ludovic Courtès]

Hi!

The idea that I had while trying to see how to map TUF to Git¹ was to
store keys in the Git repo we’re authenticating.  We’d store a list of
“authorized keys” for each “role” that we define.  One of the roles
would be “update the authorized committer keys”, for instance.

Thus, to authenticate a Git commit, we’d have to check whether it was
made by a committer whose key was marked as authorized in the previous
commit.

I’d like to toy with this idea and see whether it’s hard to implement
and how well that would perform.

Thoughts?

Ludo’.

¹ https://bugs.gnu.org/22883

Re: Commits signed by key not registered on Savannah

[Mark H Weaver]

David Craven <david@craven.ch> writes:
> The integrity of our source code is given by peer review - we are
> subscribed to the commits ML so we see other peoples commits.

If we're concerned about security (and we should be), then we should not
rely on the commits mailing list (or any web interface) to show us the
same set of commits that have been pushed to the repo.  An attacker
could prevent some of those emails from reaching us, or modify them in
transit to introduce a malicious commit into our repository without it
being noticed.

It's better to "git pull" and read the commits directly out of our local
copy of the git repository.

      Mark

Re: Commits signed by key not registered on Savannah

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

On Sun, Feb 12, 2017 at 04:55:14PM -0500, Mark H Weaver wrote:
> David Craven <david@craven.ch> writes:
> > The integrity of our source code is given by peer review - we are
> > subscribed to the commits ML so we see other peoples commits.
> 
> If we're concerned about security (and we should be), then we should not
> rely on the commits mailing list (or any web interface) to show us the
> same set of commits that have been pushed to the repo.  An attacker
> could prevent some of those emails from reaching us, or modify them in
> transit to introduce a malicious commit into our repository without it
> being noticed.

In fact, the guix-commits mailing list was not sending any messages for
a few days recently:

http://lists.gnu.org/archive/html/savannah-hackers-public/2017-02/msg00030.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]