On Fri, Sep 30, 2016 at 12:33 PM, Gregory Szorc <g...@mozilla.com> wrote: > `mach mercurial-setup` does an `hg pull` from hg.mozilla.org to obtain the > version-control-tools repository, which is where most of the logic for `mach > mercurial-setup` lives (because we have a nice testing harness in > version-control-tools). `mach mercurial-setup` doesn't pin the hash when > invoking `hg pull` because to do so would require vendoring the hash in the
> ... that means if you ran `mach mercurial-setup` on an old revision, > the pinned hash would be guaranteed to be incorrect and the connection would > always fail. Hmm. We should be able to use the fact that keys aren't reused. What if mercurial-setup had a vendored list of keys it knows have been rotated out in the past and another list which will be rotated in in the future of that particular revision? It could safely remove the former if it finds them in .hgrc because if you were able to pull a revision with that key marked expired, that should still be true when it's invoked later. Since mercurial 3.8 and later support multiple fingerprints, it would be safe to add any expected-to-be-used keys, as long as they aren't later compromised. Setting some kind of time window beyond which mercurial-setup doesn't attempt to install new keys would limit the potential damage. No worse that trusting a particular TLS config? -r _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
