##// END OF EJS Templates
dispatch: protect against malicious 'hg serve --stdio' invocations (sec)...
dispatch: protect against malicious 'hg serve --stdio' invocations (sec) Some shared-ssh installations assume that 'hg serve --stdio' is a safe command to run for minimally trusted users. Unfortunately, the messy implementation of argument parsing here meant that trying to access a repo named '--debugger' would give the user a pdb prompt, thereby sidestepping any hoped-for sandboxing. Serving repositories over HTTP(S) is unaffected. We're not currently hardening any subcommands other than 'serve'. If your service exposes other commands to users with arbitrary repository names, it is imperative that you defend against repository names of '--debugger' and anything starting with '--config'. The read-only mode of hg-ssh stopped working because it provided its hook configuration to "hg serve --stdio" via --config parameter. This is banned for security reasons now. This patch switches it to directly call ui.setconfig(). If your custom hosting infrastructure relies on passing --config to "hg serve --stdio", you'll need to find a different way to get that configuration into Mercurial, either by using ui.setconfig() as hg-ssh does in this patch, or by placing an hgrc file someplace where Mercurial will read it. mitrandir@fb.com provided some extra fixes for the dispatch code and for hg-ssh in places that I overlooked.
Augie Fackler -
r32050:77eaf953 4.1.3 stable
Show More
Name Size Modified Last Commit Author
/ tests / sslcerts
README Loading ...
client-cert.pem Loading ...
client-key-decrypted.pem Loading ...
client-key.pem Loading ...
priv.pem Loading ...
pub-expired.pem Loading ...
pub-not-yet.pem Loading ...
pub-other.pem Loading ...
pub.pem Loading ...

Generate a private key (priv.pem):

$ openssl genrsa -out priv.pem 2048

Generate 2 self-signed certificates from this key (pub.pem, pub-other.pem):

$ openssl req -new -x509 -key priv.pem -nodes -sha256 -days 9000 \
-out pub.pem -batch -subj '/CN=localhost/emailAddress=hg@localhost/'
$ openssl req -new -x509 -key priv.pem -nodes -sha256 -days 9000 \
-out pub-other.pem -batch -subj '/CN=localhost/emailAddress=hg@localhost/'

Now generate an expired certificate by turning back the system time:

$ faketime 2016-01-01T00:00:00Z \
openssl req -new -x509 -key priv.pem -nodes -sha256 -days 1 \
-out pub-expired.pem -batch -subj '/CN=localhost/emailAddress=hg@localhost/'

Generate a certificate not yet active by advancing the system time:

$ faketime 2030-01-1T00:00:00Z \
openssl req -new -x509 -key priv.pem -nodes -sha256 -days 1 \
-out pub-not-yet.pem -batch -subj '/CN=localhost/emailAddress=hg@localhost/'

Generate a passphrase protected client certificate private key:

$ openssl genrsa -aes256 -passout pass:1234 -out client-key.pem 2048

Create a copy of the private key without a passphrase:

$ openssl rsa -in client-key.pem -passin pass:1234 -out client-key-decrypted.pem

Create a CSR and sign the key using the server keypair:

$ printf '.\n.\n.\n.\n.\n.\nhg-client@localhost\n.\n.\n' | \
openssl req -new -key client-key.pem -passin pass:1234 -out client-csr.pem
$ openssl x509 -req -days 9000 -in client-csr.pem -CA pub.pem -CAkey priv.pem \
-set_serial 01 -out client-cert.pem

When replacing the certificates, references to certificate fingerprints will
need to be updated in test files.

Fingerprints for certs can be obtained by running:

$ openssl x509 -in pub.pem -noout -sha1 -fingerprint
$ openssl x509 -in pub.pem -noout -sha256 -fingerprint