I've started playing a bit with exporting a few more or less random root
certificates using Google chrome browser on Windows 7. I picked those
used by kiln, codeplex and bitbucket. Export file format chosen was
"Base-64 encoded X.509 (.CER)".
I've combined them into the attached file (warning: use only for
testing) by using a text editor (converted to LF line ends) and then
referenced that file in my user mercurial.ini as
[web]
cacerts = C:\Users\adi\combined-mercurial.cer
With that, for example the warning
warning: bitbucket.org certificate not verified (check web.cacerts
config setting)
was then gone (same for codeplex, I didn't test kiln).
Should we do something like that for the
C:\Program Files (x86)\TortoiseHg\hgrc.d\Mercurial.rc and install such a
combined cert file with some of the most important root certs?
I haven't yet figured out how to do that in detail though. I guess this
needs tweaking some wix files (Open question: does it need the full
install path of the cert file?)
Warning: I'm far from being a certificate expert so this might well be
complete nonsense (concerning security). So use the attached cert file
at your own risk.
It's near the top of my TODO list for the next stable release. Matt
recommended looking at how curl manages its cert files, and I think
it's similar to what you did.
> I've started playing a bit with exporting a few more or less random root
> certificates using Google chrome browser on Windows 7. I picked those
> used by kiln, codeplex and bitbucket. Export file format chosen was
> "Base-64 encoded X.509 (.CER)".
>
> I've combined them into the attached file (warning: use only for
> testing) by using a text editor (converted to LF line ends) and then
> referenced that file in my user mercurial.ini as
>
> [web]
> cacerts = C:\Users\adi\combined-mercurial.cer
>
> With that, for example the warning
>
> warning: bitbucket.org certificate not verified (check web.cacerts
> config setting)
>
> was then gone (same for codeplex, I didn't test kiln).
>
> Should we do something like that for the
> C:\Program Files (x86)\TortoiseHg\hgrc.d\Mercurial.rc and install such a
> combined cert file with some of the most important root certs?
>
> I haven't yet figured out how to do that in detail though. I guess this
> needs tweaking some wix files (Open question: does it need the full
> install path of the cert file?)
Good question. We have no mechanism for expanding paths in our hgrc
files at install time (I could use such a feature for the
TortoisePlink path, for instance, right now we depend on the %PATH%).
So this needs to be worked through.
> Warning: I'm far from being a certificate expert so this might well be
> complete nonsense (concerning security). So use the attached cert file
> at your own risk.
>
Thanks for getting this started.
--
Steve Borho
Ok. Good to know.
Well. I didn't really want to, but I imagine the warning has really
potential to worry lots of users who download TortoiseHg and then try
one of the usual hosters.
I've pushed changes to thg-winbuild and the WiX files on the default
branch to include a cacert.pem file downloaded from what appears to be
a reliable source (linked from the curl documentation;
http://curl.haxx.se/ca/).
Please try out a new nightly build. If all looks well, I'll back port
this to stable for the Jan 1 release.
--
Steve Borho
PS: I decided to install the cacert.pem in the hgrc.d directory mainly
because that is where the other user-overridable configurations are.
I'm having some difficulty uploading new installer packages today,
I'll try again in a few hours.
--
Steve Borho
Cool. Thanks for working on this.
http://curl.haxx.se/ca/ looks nice ("We provide automated conversions -
done weekly").
I've downloaded http://curl.haxx.se/ca/cacert.pem and configured it in
my user mercurial.ini. With that, pull from bitbucket and codeplex works
without warning.
I'll try the installers as soon as they are available.
> Steve, are you working on the certificate warning? (or someone else?)
>
> I've started playing a bit with exporting a few more or less random
> root certificates using Google chrome browser on Windows 7. I picked
> those used by kiln, codeplex and bitbucket. Export file format chosen
> was "Base-64 encoded X.509 (.CER)".
>
> I've combined them into the attached file (warning: use only for
> testing) by using a text editor (converted to LF line ends) and then
> referenced that file in my user mercurial.ini as
>
> [web]
> cacerts = C:\Users\adi\combined-mercurial.cer
>
> With that, for example the warning
>
> warning: bitbucket.org certificate not verified (check web.cacerts
> config setting)
>
> was then gone (same for codeplex, I didn't test kiln).
>
> Should we do something like that for the
> C:\Program Files (x86)\TortoiseHg\hgrc.d\Mercurial.rc and install such a
> combined cert file with some of the most important root certs?
I think the "correct way" would be to somehow query Windows about what
it thinks are the trusted root certificates -- TortoiseHg should ideally
not distribute its own list of root certificates.
As an example, one can install the ca-certificates package on Debian
systems and then add
[web]
cacerts = /etc/ssl/certs/ca-certificates.crt
to a config file in order to use the system's CA list. I think this is
the correct way since it concentrates the trust on the operating system
packages instead of third-party programs.
Maybe Windows has some API that can be used to get a list of CAs trusted
by the system.
--
Martin Geisler
aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/
I agree (if I even dare say so, given my limited understanding of these
matters), but given how much "Linuxism" we have to deal with in
TortoiseHg/Mercurial, I think installing the root certs file from curl
isn't that bad as a quick stop gap measure for the Jan 1st stable
release until someone has figured out how to do it "the right way" on
Windows (and is willing to contribute the code changes needed).
BTW, the curl root certs file seems to be built weekly and Steve pulls
it from the internet at *build time*:
https://bitbucket.org/tortoisehg/thg-winbuild/changeset/ab383615f7b9
I've installed
tortoisehg-unstable-1.9.676.2614-x64-26bc8395-134f-492d-b40e-c6bf82f21323.msi
on Windows 7 x64.
cacert.pem is in C:\Program Files\TortoiseHg\hgrc.d
There is a Paths.rc containing
[web]
cacerts=C:\Program Files\TortoiseHg\hgrc.d\cacert.pem
and 'hg incoming' from bitbucket https shows no warnings.
I've uploaded stable (hgtk) packages to thg-winbuild/downloads that
now include a certificate file. I also back-ported a couple of
goodies from the pyqt thg-winbuild branch that should make 'hgtk
userconfig' start fairly fast again, and also ensures all the Python
packages we ship with TortoiseHg include up-to-date compiled C++
extensions.
Let me know if you spot any troubles.
--
Steve Borho
It looks like this would be possible:
But I have very little motivation to do so.
--
Steve Borho
Yeah, Windows has a crypto API. I could be wrong, but if anyone wants to
try to integrate that, it should probably be tried in the Mercurial
codebase. My motivation to drill there is rather low currently as well.
<rant mode, off topic>Right now, I would be happy enough to get
Mercurial's file access for Windows straight without having to trip into
some hard new traps while being enticed by Matt to do yet some other
dangerous hard core optimizations in the Mercurial code base. I'm still
suffering from the delete on 'w'rite debacle
(http://mercurial.selenic.com/bts/issue2524 ).
As always in Mercurial, keeping both the Linux geeks *and* Windows happy
is quite difficult. Probably yet another multi-month slow-motion patch
wrangling...</rant mode>
I uninstalled TortoiseHg 1.9.676.2614 (x64) on my Windows 7 x64, which
then told me it needed a reboot (which I did), and then installed
tortoisehg-stable-1.1.7118.2127-x64-38270d49-1314-418c-8487-e691159ff0e6.msi
Works fine. No certificate warning when pulling from bitbucket over https.
Thanks for the last minute nice hacking to fix all this.
Ugh. Looks like there no certs installed for the mercurial 1.7.3 installers.
I still don't how that happened, but I've rebuilt 1.7.3 installers
without changing a line of code anywhere, installed them both, and
they have cacert.pem and paths.rc. I've uploaded them with version
number 1.7.3-1
--
Steve Borho