Opposite of --insecure is what?

Jason Harris jason at jasonfharris.com
Fri Feb 4 03:09:35 CST 2011


Ok in making MacHg work with certificates for https:// and fingerprints and
stuff the following issue has come up... Ironically I now have almost the
opposite question to the ones I previously asked. How do I make the operation
always fail if there is no verifiable certificate or fingerprint?

Consider:

if web.cacerts is not configured the error message is:

[Bolt:/Development/MacHgDev/MacHgDH] MacHgDH 2211(2211) ⌘ hg pull https://***@jasonfharris.com/hg/MacHg
warning: jasonfharris.com certificate with fingerprint b8:03:9f:99:31:f9:5e:4b:ab:5b:7e:5f:af:ff:e1:ec:f6:f0:2e:55 not verified (check hostfingerprints or web.cacerts config setting)
http authorization required
realm: Mercurial Repositories
user: ***
password: ....


But if I set up web.cacerts then things fail outright when connecting to a
server with a self-signed certificate, but no fingerprint info is printed. Eg

[Bolt:/Development/MacHgDev/MacHgDH] MacHgDH 2211(2211) ⌘ hg pull https://***@jasonfharris.com/hg/MacHg
abort: error: _ssl.c:480: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

(Note this is a scary error and really what has happened is that the self-signed
certificate was unknown to Mercurial. It wasn't that it was trying to spoof
something... The message shouldn't cry wolf. Maybe the message should be a
little lighter for this case? (I gather from the code that this is coming
through from a layer below Mercurial...)

Thus to sum up we currently have

(i) if web.cacerts set up, and unknown site accessed -> fail always, no fingerprint info issued.
(i) if web.cacerts not set up, and unknown site accessed -> succeed with warning, fingerprint info issued.

------------------------------------

Why do I need a --authentication strict option?

I need this for nice security interaction in MacHg.  Basically I would normally turn
on strict adherence in all my operations and then I would always detect the
abort errors coming from Mercurial whenever there are security problems and I
would and ask the user:

  The authenticity of host 'foobar.com' cannot be established.
  The host is reporting the key fingerprint:
    38:76:52:7c:87:26:9a:8f:4a:f8:d3:de:08:45:3b:ea:d6:4b:ee:cc
  Do you trust that this key fingerprint really represents 'foobar.com'?

Then the user can "Accept" or "Deny" this fingerprint being stored in MacHg's
Application Support hgrc file. Pretty much like the fingerprint acceptance in
ssh but with nice dialogs, etc.

However, if the user "Denies" the operation then of course its imperative that
the operation never actually went ahead in the first place. Ie I need a fail but
with fingerprint info accessible.

If the user "Accepts" then I issue another dialog stating: 
   Host Added
   'foobar.com' now has a fingerprint key associated with it so it can be verifiably recognized in the future.
   Continue Pull operation?

With choices "Continue" and "Cancel"

I have already locally changed Mercurial in MacHg so '--insecure' prints no
warnings and just does the connection. I now need a '--secure' option or
something which always fails whenever there is any problem in verifying the
server, but I need it to print an informative message with fingerprint key, so I
can grab that and add it to the hostfingerprints if the user accepts.

------------------------------------

Now to my question... Is there any interest on the part of Matt and or crew to
allow such behavior or should I just further patch Mercurial for MacHg? Thinking
about all of this a better design might be an option:

--authentication secure
--authentication flexible
--authentication insecure
--authentication ignore

Also I would like it clear from the error messages what the error truly is. Ie
is it just a basically unknown host error or is the host really being spoofed...

The other option would be for me to add a debugauthenticity command which would
test the authenticity of a host prior to actually doing anything.

What do people say?

Cheers,
  Jas


More information about the Mercurial-devel mailing list