Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing detached PGP signatures for 3.3.14, 3.3.15 releases #11094

Closed
Roguelazer opened this issue Aug 29, 2019 · 15 comments

Comments

@Roguelazer
Copy link

commented Aug 29, 2019

Looks like the same issue as #10702.

My automated processes rely on signature verification, so it's kind of frustrating that these keep going missing.

@gyuho

This comment has been minimized.

Copy link
Member

commented Aug 29, 2019

@hexfusion @philips Can you help? Or are we deprecating PGP signatures for 3.4 in favor of https://github.com/merklecounty/rget?

@philips

This comment has been minimized.

Copy link
Contributor

commented Aug 29, 2019

I don't have access to the signing key.

@gyuho

This comment has been minimized.

Copy link
Member

commented Aug 29, 2019

@hexfusion has access to the signing key.

@wiktor-k

This comment has been minimized.

Copy link

commented Aug 30, 2019

Or are we deprecating PGP signatures for 3.4 in favor of https://github.com/merklecounty/rget?

It seems rget suggests using both: GPG signatures and their scheme. From the README:

Q: Why not use GPG keys or other public key signing?
A: This is complimentary to public key signing! Public key signing asserts that someone with access to the private key signed the exact content. But, the private key can be used to generate an unlimited number of signatures for different content. If the URLs contents are both signed and logged in the URL content record then there is a guarantee that both the owner of the private key signed the content AND the content being fetched is cryptographically identical to the content other people are fetching using rget.

@philips

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2019

@wiktor-k @Roguelazer the problem is that key custody and signing is difficult now that etcd is maintained by many different companies under the CNCF. The questions of who has the key, where is it stored, how do we audit what the key signed, etc are all really difficult. In the beginning everything was signed with the CoreOS GPG key but that doesn't really make sense any longer.

As a point of comparison Kubernetes has never signed a release. And there has been an open discussion on the issue for over a year.

So, I guess I have two questions:

  1. What is the property people you want out of GPG signing of the releases?
  2. Is there a team maintained project you know that has a good solution to the key custody problem?
@Roguelazer

This comment has been minimized.

Copy link
Author

commented Aug 30, 2019

@philips

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2019

@Roguelazer OK, that is useful input. The rget tool is alpha but providing a durable tamper proof host for SHA digests was what I built it to accomplish (see blog).

@wiktor-k

This comment has been minimized.

Copy link

commented Sep 2, 2019

the problem is that key custody and signing is difficult now that etcd is maintained by many different companies under the CNCF. The questions of who has the key, where is it stored, how do we audit what the key signed, etc are all really difficult. In the beginning everything was signed with the CoreOS GPG key but that doesn't really make sense any longer.

I'd recommend to select a group of few people that'd prepare releases and they'd sign the artifacts. That's what kernel.org and Linux Foundation does (see source). As @Roguelazer mentions Apache uses similar approach (they store KEYS file in repository root with keys of people authorized to sign releases, c.f. https://httpd.apache.org/dev/verification.html).

Durable tamper proofing is important but it doesn't replace GPG signatures. I didn't check rget source yet but it looks like an interesting approach (I did work on secure timestamping, OpenTimestamps etc.)

@Roguelazer

This comment has been minimized.

Copy link
Author

commented Sep 18, 2019

Note that there are also no GPG signatures on any of the subsequent releases (e.g., 3.4, 3.4.1)

@hexfusion

This comment has been minimized.

Copy link
Member

commented Sep 18, 2019

@hexfusion

This comment has been minimized.

Copy link
Member

commented Sep 18, 2019

@retroflexer

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2019

The person who has access to the gpg keys has promised me to generate the keys for 3.3.14 and 3.3.15 also 3.4.0 and 3.4.1 by tomorrow (hopefully, before our meeting).

@retroflexer

This comment has been minimized.

Copy link
Contributor

commented Sep 19, 2019

@Roguelazer

This comment has been minimized.

Copy link
Author

commented Sep 20, 2019

Will they be attached to the Github releases?

@hexfusion

This comment has been minimized.

Copy link
Member

commented Sep 21, 2019

Will they be attached to the Github releases?

Back filled:

  • 3.3.14
  • 3.3.15
  • 3.4.0
  • 3.4.1
@hexfusion hexfusion closed this Sep 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
6 participants
You can’t perform that action at this time.