savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] Mercurial/hg and savannah's HTTPS


From: Bob Proulx
Subject: Re: [Savannah-hackers-public] Mercurial/hg and savannah's HTTPS
Date: Thu, 12 Jan 2017 16:08:45 -0700
User-agent: NeoMutt/20161126 (1.7.1)

Hi Assaf,

Good work on getting hg moved over.

Assaf Gordon wrote:
> Older 'hg' clients do not support SNI (Server Name Indication,

Would it be sufficient simply to state that for https to be used that
clients simply must use a suitable up to date client?

I think that is more than sufficient.  Especially considering that
they could not previously use https at all.  It supports the natural
progression of things.  If you want to use the new thing then you need
the new thing compatible software.

Is there any way to tell by statics how many older hg clients are
still in use?  Or perhaps what environments or OS distributions are
shipping older hg clients?

Obviously this has not previously been a problem because https has not
previously been offered for hg.  They never had this problem before.
This is simply a new feature which is only available to up to date
software.  I think that is okay.

I also suspect that older clients not getting updated anymore will
soon have problems with dropped protocols such as SSLv3 now dropped
too.  I see that TLS1.0 is the lastest supported by these older
clients.  When TLS1.0 becomes unsupportable they will be forced to
upgrade at that point.

> Possible workarounds include:

One you did not mention is that on the server side we could allocate
another IP address specifically for hg use.  That would allow us to
avoid needing SNI to serve the certificate.  However given that the
problem is outdated hg clients not getting updated which leads to
other problems I don't think we should help them do the wrong thing
here.

> 1. Use 'http' instead of 'https'

Or use the bzr:// protocol.  No difference then.  One of these two
options is what they have been using all of this while already.

> 2. Use '--insecure' :
>      hg clone --insecure https://hg.sv.gnu.org/hgweb/test-project/

Better than not using it.

> 3. Add the fingerprint to your '.hgrc' file:
> 
>     $ FP=c0:50:9b:12:09:6c:d7:f4:7e:3e:7d:d8:eb:17:a3:8b:17:ad:36:77
>     $ cat<<EOF>>.hgrc
>     [hostfingerprints]
>     hg.sv.gnu.org = $FP
>     hg.sv.nongnu.org = $FP
>     hg.savannah.gnu.org = $FP
>     hg.savannah.nongnu.org = $FP
>     EOF
> 
>   (though note that this is fingerprint might change in the future,
>    and it's rather arbitrary that 'bzr' certificate is used instead
>    of another).

Not sure but won't that change every time the certificate is renewed?
Being as we renew every two months and during our development we add
and remove sites from the certificate routinely I think the
fingerprint will not remain constant.  I worry about suggesting that
workaround as I do not think it will last.

> 4. Upgrade 'hg' (and/or the underlying python setup).

That seems like the best answer.  However I do have sympathy if old
clients are still in long term supported OS releases.

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]