Improvements to the joining issue template #84
Conversation
The signed message should be clear on what exactly is being requested, more so given that these signed messages are publicly posted, so that they cannot be used in another context for potentially malicious purposes.
Even if just an example, let's make it use the ideal defaults.
While GPG is still one of the most prevalent implementations, it is just one among many. We are dealing here with OpenPGP artifacts, so spell that out explicitly. This is more relevant now that GnuPG has opted out of the IETF OpenPGP working group, and will not be implementing future revisions of the specification.
There was a problem hiding this comment.
lgtm.
however, i forgot everything i read about the OpenPGP schism and how that would affect compatibility.
(and I assume that your change is driven by the desire to clarify the instructions, to make it simpler to submit a correctly signed request).
Probably it would be enough to just state that the signature has to be verifiable against the Debian keyring (this would be a good addition anyhow)
DDs should be able to provide the required information without getting too deep into the details of what is the correct implementation.
|
I didn't feel there was a need to go over the OpenPGP schism in the issue message itself, or the reporting from the GitHub action, but using appropriate terms seems important to me, so that we can encourage and support the richer and wider OpenPGP ecosystem. For example I didn't use gpg to sign my own request. :) I was pondering as well to switch the GnuPG usage in the GitHub action into SOP, but left that out for now, but might come back to that later. :) I think the example signing instruction could also be generalized or extended with say SOP or sq examples, but left that out for now too. |
This PR contains a few improvements to the joining template. From using better terminology when referring to OpenPGP, to improving the security of the signed message.