I would like to get rid of the set up your identity and Clean up your identity XWiki Standard release steps, and for that we need to stop using personal GitHub account and GPG key to do those.
So the proposal would be to:
Always use the same GitHub account. We have two possibilities here:
a. reuse xwikici which is currently used by ci.xwiki.org
b. create a new dedicated account (which would have much more rights than what xwikici currently have, since it would need to be able to do commits and create releases)
Create a new GPG key for the releases and publish it
Pro:
reduce the time spent and complexity of releases
it’s a mandatory step to make automated releases possible, eventually
Cons:
we won’t know who did the release just from the GitHub history anymore
WDYT ?
I honestly don’t see much value in what we currently do, and it’s quite an annoying and error-prone step. We are already using a common SSH key, so why not go all the way.
So here is my +1 in general.
I have a preference for 1.b. (mainly because of the very different level of access), but I understand if others feel it’s overkill and prefer 1.a.
This proposal is open until at least all release managers have answered it.
+1 that it’s painful but I thought we wanted traceability in the signature/etc and thus has individual GPG keys. I’m not an expert on this topic of security, so I’m going to trust that there’s no negative effects of using a common key beyond the fact that we won’t be able to trace back a release to an individual by looking at the artifacts.
Sure, it won’t be an individual, but you can still trace it back to an organization (it’s not like it was not signed at all anymore). Of course, we can still easily know who did which release from https://dev.xwiki.org/xwiki/bin/view/Community/ReleasePlans, even if it’s less direct (but I doubt anyone ever tried to use the signature of an artifact to find out who did an XWiki release ).
+1 to sign automated steps with a specific account that is not link to a specific person.
Though we could consider signing individual commits by their author if we want to have more traceability (but that’s another discussion).
I think we need to carefully examine the security impact. New risks I see in particular with the setup without passphrase:
GPG keys without passphrase would create a problem once we validate signatures in the extension manager (see signed extensions) in case the key is stolen in any way.
An SSH key without password with permanently enabled write access would be a much larger impact on our source repository when it is stolen than the current setup where write access for the key is only enabled during the release itself (at least if we detect a possible incident before the next release).
Ex-committers could copy the private keys and keep access to the GitHub account and keep the ability to sign artifacts. We would need to carefully rotate the keys whenever a committer leaves (same when signing with personal keys, but there it seems more obvious once we start putting any trust in these signatures).
What I would find okay from a security point of view is to have TPM-secured keys (or keys secured by some other hardware) such that they cannot be extracted from the release agent, ideally additionally secured by a password. That way, while getting access to the server would allow using the keys, neither committers nor attackers would be able to extract the private key.
Ideally, we would even be able to keep an audit log of all uses of the keys outside the build agent, but I don’t know if that’s practical.
In any case, I’m +1 if we find a way to prevent copying the keys (e.g., using TPM as mentioned above).
).