1298948 - Define a secret containing new hg.mozilla.org fingerprint

Status: RESOLVED FIXED

(Taskcluster :: Services, defect)

Description

[Gregory Szorc [:gps]]

The hg.mozilla.org x509 certificate expires on September 28. We'll need to update the TaskCluster secret to define the new fingerprint.

Mercurial 3.8 supports defining multiple certificate fingerprints per hostname. So, if we start using this, we can define the new certificate fingerprint alongside the old one in a TC secret and the certificate rotation will be seamless from a client perspective.

The content we need in a secret is:

 "sha256:8e:ad:f7:6a:eb:44:06:15:ed:f3:e4:69:a6:64:60:37:2d:ff:98:88:37:bf:d7:b8:40:84:01:48:9c:26:ce:d9, sha1:af:27:b9:34:47:4e:e5:98:01:f6:83:2b:51:c9:aa:d8:df:fb:1a:27"

This is the SHA-256 fingerprint of the new certificate and the SHA-1 fingerprint of the old certificate.

We can either add this string as a new key under the project/taskcluster/gecko/hgfingerprint secret or create a new secret. I don't have a preference.

For legacy clients (including code currently on the release and beta channels), we'll need to rotate the existing fingerprint/secret value when the server rotates its certificate, as there is no way to pin multiple fingerprints and the version of Mercurial they are using doesn't support the "sha*" prefix on fingerprint values. i.e. the existing "content" key on project/taskcluster/gecko/hgfingerprint *must not change* until we rotate the server cert.

Comment 1

[Pete Moore [:pmoore][:pete]]

I wonder why we currently store public information in a secret. I'm not able to see who created the secret, so I'm not sure who to ask.

Dustin, do you know?

Comment 2

[Greg Arndt [:garndt]]

I created the secret to use originally and mainly it was because we had access control in place around it and tc-secrets handles these types of things well.  It could have been stored somewhere else that didn't allow others to tamper with it too.

Comment 3

[Dustin J. Mitchell [:dustin] (he/him)]

I recall some discussion about wanting to be able to change this outside of the normal development process, which was what led to making it a secret.  The idea was, when the fingerprint changed we could just change the secret and have immediate effect across all branches.  I think that's a nice idea, but it hasn't worked out very well in this case since we need to change the format.

Embedding it in the docker image generation script wouldn't be the worst thing.  After all, even if we're using a secret, if it's only set when the docker images are rebuilt, then we'll need to land something on the older branches anyway to update them.

Comment 4

[Gregory Szorc [:gps]]

I don't see what hasn't worked out so well. We can just add a new key to the secret. e.g. "sha2content" and new consumers can look at that instead of "content."

Comment 5

[Dustin J. Mitchell [:dustin] (he/him)]

I mean that we haven't avoided the need to make in-tree changes due to a changing certificate.  But hopefully this won't happen again :)

Comment 6

[Gregory Szorc [:gps]]

The in-tree changes are needed because I'm upgrading to Mercurial 3.9. We could potentially do this without in-tree changes if Mercurial 3.9 weren't involved.

2 years from now, we should be able to make the cert transition by just changing the secret.

Comment 7

[Gregory Szorc [:gps]]

Can this please be implemented in the next 24 hours? I need it to unblock other work to move TC automation to Mercurial 3.9.1.

Comment 8

[Dustin J. Mitchell [:dustin] (he/him)]

I updated the "secret" to contain:

{
  "content": "af:27:b9:34:47:4e:e5:98:01:f6:83:2b:51:c9:aa:d8:df:fb:1a:27",
  "fingerprints": "sha256:8e:ad:f7:6a:eb:44:06:15:ed:f3:e4:69:a6:64:60:37:2d:ff:98:88:37:bf:d7:b8:40:84:01:48:9c:26:ce:d9, sha1:af:27:b9:34:47:4e:e5:98:01:f6:83:2b:51:c9:aa:d8:df:fb:1a:27"
}