A security flaw was found in the way Mercurial handled subject
Common Name field of the provided certificate (the check
if the commonName in the received certificate matches the
requested hostname was not performed). An attacker, able
to get a carefully-crafted certificate signed by a Certificate
Authority could use the certificate during a man-in-the-middle
attack and potentially confuse Mercurial into accepting it by
The true reason for this deficiency is the Python SSL module implementation,
but as stated in:
"Unfortunately, hostname matching is one of those ideas that seemed
better when it was thought up than it actually proved to be in practice.
I've had extensive experience with this, and have found it to almost
always an application-specific decision. I thought about this when
designing the client-side verification, and couldn't see any automatic
solution that doesn't get in the way. So the right way to do this with
Python is to write some application code that looks at the verified
identity and makes decisions based on whatever authentication algorithm
This issue did NOT affect the versions of the mercurial package, as shipped
with Fedora release of 12 and 13 (relevant packages are already updated).
So should this be closed?
This is fixed with 1.6.4, so it should be closed when that package hits "updates".
Hi Neal, Mads,
the Security Response product bugs cover the same issue, present in
particular package among various releases of Red Hat Enterprise Linux
Though this issue has been already addressed in versions of mercurial,
as shipped within Fedora releases, it still applies to version of mercurial,
as scheduled to appear in Red Hat Enterprise Linux 6.
So this bug being still valid.
Thanks && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Response Team
This issue affects the version of the mercurial package, as shipped with
Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this issue as having moderate security impact, a future update may address this flaw.