Input from Security or Ops security-type folks?

My proposal would be the following:

• Create a "mediawiki releases 2017 key" (with an expiration date of maybe 2-3 years)
• Disseminate the secret key to the releng members usually making releases (don't make the group too big, though since the key should be rotated when people leave)
• Push the public key to the SKS network
• Ask on operations@ or engineering@ that people who use PGP validate the release key's correctness (e.g. by validating the PGP signature of that mail) and sign the releases key

When a new release is being made, people can then identify the correctness of the signing key by checking the key listed on mediawiki.org (which could be forged), but also against their web-of-trust.

Would we be creating a new key every year then?

As a complete idiot when it comes to this: are subkeys an option? Like, could we have a master key that basically nobody has the password to, but then each releaser gets their own subkey?

In T181019#3782146, @dpatrick wrote:

as releases could be signed by the Jenkins instance.

Just so everyone's on the same page, by "the Jenkins instance" Darian is referring to the private Jenkins instance, not the normal one people think of (https://integration.wikimedia.org/ci/). ;)

In T181019#3782098, @Legoktm wrote:

Would we be creating a new key every year then?

Not needed, I'd simply use the key over it's designated lifetime until the expiry date (If you rotate the key e.g. every 2-3 years you're keeping the key updated to current GPG crypto settings).

In T181019#3782121, @demon wrote:

As a complete idiot when it comes to this: are subkeys an option? Like, could we have a master key that basically nobody has the password to, but then each releaser gets their own subkey?

That would also work, but you'd still need to rotate the master key in case someone in control of the secret key leaves.

I don't have an idea about how many releasers we're talking here, can someone provide some estimate?

In T181019#3782273, @greg wrote:

Just so everyone's on the same page, by "the Jenkins instance" Darian is referring to the private Jenkins instance, not the normal one people think of (https://integration.wikimedia.org/ci/). ;)

How is that private Jenkins instance accessed, just from localhost on releases1001? Jenkins adds some notable complexity and has had it's fair share of code execution vulnerabilities in the past. Also, you'd need to store the key's passphrase in Jenkins.

Auto-signing from within Jenkins isn't a super huge priority.