Added my release key
AbandonedPublic
Actions

Authored by jasonbcox on May 29 2018, 00:11.

Details

Reviewers

deadalnix
schancel
matiu

Group Reviewers

Restricted Project

Summary

Adding my release key per Matias's proposed release process

Test Plan

Do a release

Diff Detail

Repository

rABC Bitcoin ABC

Branch

release

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 2669
Build 3450: Bitcoin ABC Buildbot (legacy)
Build 3449: arc lint + arc unit

Event Timeline

jasonbcox created this revision.May 29 2018, 00:11

Herald added a reviewer: Restricted Project. · View Herald TranscriptMay 29 2018, 00:12

Build Bitcoin-ABC :: Diffs :: Bitcoin-ABC Diff Testing started.

Not sure if it matters, but the key was not generated in ASCII mode. I assume that's why there's no preview in the diff section.

Build Bitcoin-ABC :: Diffs :: Bitcoin-ABC Diff Testing passed.

Harbormaster completed remote builds in B2668: Diff 4014.May 29 2018, 00:47

Please armor key (send the .asc) file. Thanks for your comment on the doc, I have updated it.

This revision now requires changes to proceed.May 29 2018, 01:49

Used ASCII armor instead

Build Bitcoin-ABC :: Diffs :: Bitcoin-ABC Diff Testing started.

Build Bitcoin-ABC :: Diffs :: Bitcoin-ABC Diff Testing passed.

Harbormaster completed remote builds in B2669: Diff 4015.May 29 2018, 04:36

deadalnix accepted this revision.May 29 2018, 13:40

matiu accepted this revision.May 30 2018, 16:31

This revision is now accepted and ready to land.May 30 2018, 16:31

We should do this instead:

gpg --keyserver hkp://subset.pool.sks-keyservers.net --send-keys 7A55A44F3A3239827C8A594E7D3958C44427674A
gpg: sending key 7D3958C44427674A to hkp://subset.pool.sks-keyservers.net

Then per https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-keys

We can have people run this:

while read fingerprint keyholder_name; do gpg --keyserver hkp://subset.pool.sks-keyservers.net --recv-keys ${fingerprint}; done < ./keys.txt

This enables having cold storage *revocation* keys, in the event that one of our keys is compromised. Also, this enables cross-signing other people's keys. See: https://lwn.net/Articles/461236/

See:

gpg --fingerprint <key ID>
gpg --keyserver hkp://subset.pool.sks-keyservers.net --recv-key <their key ID>
gpg -u <your key ID> --sign-key <their key ID>
gpg --keyserver hkp://subset.pool.sks-keyservers.net --send-key <their key ID>
gpg --keyserver hkp://subset.pool.sks-keyservers.net --recv-key <your key ID>

I'm not sure which keyserver we should use, both

@schancel Are you suggesting we do that instead of adding our keys to the repo? I think having it in repo is a good idea no matter what else we use in addition.

schancel requested changes to this revision.May 31 2018, 14:49

This revision now requires changes to proceed.May 31 2018, 14:49

I don't agree. Having them here is bad UX. People will never check to see if revocation signatures have been issued.

Some additional useful information here: https://wiki.debian.org/Keysigning

Sending the signature to the server didn't seem to work when I did it.

deadalnix added inline comments.Jun 7 2018, 10:00