Publish release signing key (more) #92

New Issue

s-hamann · 2020-01-10T08:55:41Z

s-hamann commented

2020-01-10 08:55:41 +00:00

The PGP release signing key for Teabot <teabot@gitea.io> (7C9E68152594688862D62AF62D9AE806EC1592E2) is on the SKS network, but I was (mostly) unable to find it anywhere else.
Since the SKS network is not exactly looking into a bright future (cf. https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f, for instance), it may be prudent to explore alternatives.
I believe there are two viable options:

keys.openpgp.org:
This server uses a different approach to publishing keys, but is mostly compatible with the SKS network, i.e. works as a drop-in replacement since it uses the same HKPS protocol.
Debian uses this as the default key server.
The difference is that this server will not publish identities without confirming the e-mail address.
gnupg, at least on Debian 10, does not import keys without identities.
Therefore, while the Teabot key is on keys.openpgpg.org, it is not easily usable.
The solution seems simple: Confirm the e-mail address (i.e. receive an e-mail to teabot@gitea.io and click a link).
This would make things slightly easier for Debian users (and others who prefer this keyserver).
Web Key Directory (WKD):
WKD is a proposed standard for publishing keys via HTTPS.
In a nutshell, it involves putting a static file in a well-known location on gitea.io (see https://wiki.gnupg.org/WKD and https://wiki.gnupg.org/WKDHosting).
It's quite simple to set up (for one key that does not change too frequently, that is).
Since WKD makes the key available under a web URL, the docs could link to it for manual download, which would be a nice addition, IMHO.
DNS:
For completeness, PGP keys can also be published via DNS (OPENPGPKEY or PKA).
I consider that somewhat unwieldy and don't see much of a point in doing so.

The PGP release signing key for `Teabot <teabot@gitea.io>` (`7C9E68152594688862D62AF62D9AE806EC1592E2`) is on the SKS network, but I was (mostly) unable to find it anywhere else. Since the SKS network is not exactly looking into a bright future (cf. https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f, for instance), it may be prudent to explore alternatives. I believe there are two viable options: 1. `keys.openpgp.org`: This server uses a different approach to publishing keys, but is mostly compatible with the SKS network, i.e. works as a drop-in replacement since it uses the same HKPS protocol. Debian uses this as the default key server. The difference is that this server will not publish identities without confirming the e-mail address. gnupg, at least on Debian 10, does not import keys without identities. Therefore, while the Teabot key is on `keys.openpgpg.org`, it is not easily usable. The solution seems simple: Confirm the e-mail address (i.e. receive an e-mail to `teabot@gitea.io` and click a link). This would make things slightly easier for Debian users (and others who prefer this keyserver). 2. Web Key Directory (WKD): WKD is a [proposed standard](https://tools.ietf.org/html/draft-koch-openpgp-webkey-service) for publishing keys via HTTPS. In a nutshell, it involves putting a static file in a well-known location on `gitea.io` (see https://wiki.gnupg.org/WKD and https://wiki.gnupg.org/WKDHosting). It's quite simple to set up (for one key that does not change too frequently, that is). Since WKD makes the key available under a web URL, the docs could link to it for manual download, which would be a nice addition, IMHO. 3. DNS: For completeness, PGP keys can also be published via DNS (OPENPGPKEY or PKA). I consider that somewhat unwieldy and don't see much of a point in doing so.

zeripath commented

2020-01-10 09:41:29 +00:00

We could create a Teabot user on this instance and have the key here on that user here too. (Obviously we would need to ensure that the Teabot user is sufficiently safe from interaction.) then you could get the key for the teabot at https://gitea.com/teabot.gpg

For example, the GPG key I sign my commits with is here: https://gitea.com/zeripath.gpg

After a quick glance at the WKD spec it seems likely that we could easily make that additional .well-known based endpoint work with the exception of supporting update - although that could possibly be done under the auth-submit route. I'd have to carefully read the spec to see how it copes with .well-known being hosted on sub-domains, probably it doesn't, but that is still not really a reason for us to not support it - people hosting gitea as say https://example.org/gitea can proxy as necessary if they want it (simy for the non-https case).

Why don't you open an issue on https://github.com/go-gitea/gitea for this feature?

We could create a Teabot user on this instance and have the key here on that user here too. (Obviously we would need to ensure that the Teabot user is sufficiently safe from interaction.) then you could get the key for the teabot at https://gitea.com/teabot.gpg For example, the GPG key I sign my commits with is here: https://gitea.com/zeripath.gpg After a quick glance at the WKD spec it seems likely that we could easily make that additional `.well-known` based endpoint work with the exception of supporting update - although that could possibly be done under the `auth-submit` route. I'd have to carefully read the spec to see how it copes with `.well-known` being hosted on sub-domains, probably it doesn't, but that is still not really a reason for us to not support it - people hosting gitea as say `https://example.org/gitea` can proxy as necessary if they want it (simy for the non-https case). Why don't you open an issue on https://github.com/go-gitea/gitea for this feature?

👍 1

s-hamann commented

2020-01-10 12:38:44 +00:00

We could create a Teabot user on this instance and have the key here on that user here too. (Obviously we would need to ensure that the Teabot user is sufficiently safe from interaction.) then you could get the key for the teabot at https://gitea.com/teabot.gpg

That's an option to publish the key, but not one that gpg can handle.
My suggestions are all standardized (to some degree).
Especially in automated deployments, I generally prefer standards (and supporting tools) over having to come up with something myself (even if it seems fairly trivial in this case).

After a quick glance at the WKD spec it seems likely that we could easily make that additional .well-known based endpoint work with the exception of supporting update - although that could possibly be done under the auth-submit route. I'd have to carefully read the spec to see how it copes with .well-known being hosted on sub-domains, probably it doesn't, but that is still not really a reason for us to not support it - people hosting gitea as say https://example.org/gitea can proxy as necessary if they want it (simy for the non-https case).

It has to be no subdomain or openpgpkey.$domain.

Why don't you open an issue on https://github.com/go-gitea/gitea for this feature?

I did not mean for Gitea to generally support that.
I'd be happy if the Teabot key that signs Gitea binaries was published via an additional channel.
Therefore the website seemed appropriate to me.

WKD support seems like a nice feature for Gitea itself, though.
But since I don't currently have need for that myself, I'd rather leave the feature request to people that would actually appreciate the work that goes into it 😉

> We could create a Teabot user on this instance and have the key here on that user here too. (Obviously we would need to ensure that the Teabot user is sufficiently safe from interaction.) then you could get the key for the teabot at https://gitea.com/teabot.gpg That's an option to publish the key, but not one that gpg can handle. My suggestions are all standardized (to some degree). Especially in automated deployments, I generally prefer standards (and supporting tools) over having to come up with something myself (even if it seems fairly trivial in this case). > After a quick glance at the WKD spec it seems likely that we could easily make that additional .well-known based endpoint work with the exception of supporting update - although that could possibly be done under the auth-submit route. I'd have to carefully read the spec to see how it copes with .well-known being hosted on sub-domains, probably it doesn't, but that is still not really a reason for us to not support it - people hosting gitea as say https://example.org/gitea can proxy as necessary if they want it (simy for the non-https case). It has to be no subdomain or `openpgpkey.$domain`. > Why don't you open an issue on https://github.com/go-gitea/gitea for this feature? I did not mean for Gitea to generally support that. I'd be happy if the Teabot key that signs Gitea binaries was published via an additional channel. Therefore the website seemed appropriate to me. WKD support seems like a nice feature for Gitea itself, though. But since I don't currently have need for that myself, I'd rather leave the feature request to people that would actually appreciate the work that goes into it :wink:

giteabot commented

2020-01-11 05:50:25 +00:00

https://gitea.com/giteabot.gpg is ready.

6543 commented

2020-01-29 12:54:55 +00:00

Since the SKS network is not exactly looking into a bright future

https://keys.openpgp.org/ works great :)

and now giteabot has its key available ther too:
https://keys.openpgp.org/search?q=teabot%40gitea.io

since gitea.com has it and it is on openpgp I'll close this issue

@s-hamann feel free to reopen if i missed someting

> Since the SKS network is not exactly looking into a bright future https://keys.openpgp.org/ works great :) and now giteabot has its key available ther too: `https://keys.openpgp.org/search?q=teabot%40gitea.io` since gitea.com has it and it is on openpgp I'll close this issue @s-hamann feel free to reopen if i missed someting

6543 closed this issue

2020-01-29 12:54:56 +00:00

This repo is archived. You cannot comment on issues.

No Milestone

No Assignees

4 Participants

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/website#92