Mercurial > hg
view mercurial/dirstateguard.py @ 31290:f819aa9dbbf9
sslutil: issue warning when [hostfingerprint] is used
Mercurial 3.9 added the [hostsecurity] section, which is better
than [hostfingerprints] in every way.
One of the ways that [hostsecurity] is better is that it supports
SHA-256 and SHA-512 fingerprints, not just SHA-1 fingerprints.
The world is moving away from SHA-1 because it is borderline
secure. Mercurial should be part of that movement.
This patch adds a warning when a valid SHA-1 fingerprint from
the [hostfingerprints] section is being used. The warning informs
users to switch to [hostsecurity]. It even prints the config
option they should set. It uses the SHA-256 fingerprint because
recommending a SHA-1 fingerprint in 2017 would be ill-advised.
The warning will print itself on every connection to a server until
it is fixed. There is no way to suppress the warning. I admit this
is annoying. But given the security implications of sticking with
SHA-1, I think this is justified. If this patch is accepted,
I'll likely send a follow-up to start warning on SHA-1
certificates in [hostsecurity] as well. Then sometime down
the road, we can drop support for SHA-1 fingerprints.
Credit for this idea comes from timeless in issue 5466.
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Thu, 09 Mar 2017 20:33:29 -0800 |
parents | 751639bf6fc4 |
children | ec306bc6915b |
line wrap: on
line source
# dirstateguard.py - class to allow restoring dirstate after failure # # Copyright 2005-2007 Matt Mackall <mpm@selenic.com> # # This software may be used and distributed according to the terms of the # GNU General Public License version 2 or any later version. from __future__ import absolute_import from .i18n import _ from . import ( error, ) class dirstateguard(object): '''Restore dirstate at unexpected failure. At the construction, this class does: - write current ``repo.dirstate`` out, and - save ``.hg/dirstate`` into the backup file This restores ``.hg/dirstate`` from backup file, if ``release()`` is invoked before ``close()``. This just removes the backup file at ``close()`` before ``release()``. ''' def __init__(self, repo, name): self._repo = repo self._active = False self._closed = False self._suffix = '.backup.%s.%d' % (name, id(self)) repo.dirstate.savebackup(repo.currenttransaction(), self._suffix) self._active = True def __del__(self): if self._active: # still active # this may occur, even if this class is used correctly: # for example, releasing other resources like transaction # may raise exception before ``dirstateguard.release`` in # ``release(tr, ....)``. self._abort() def close(self): if not self._active: # already inactivated msg = (_("can't close already inactivated backup: dirstate%s") % self._suffix) raise error.Abort(msg) self._repo.dirstate.clearbackup(self._repo.currenttransaction(), self._suffix) self._active = False self._closed = True def _abort(self): self._repo.dirstate.restorebackup(self._repo.currenttransaction(), self._suffix) self._active = False def release(self): if not self._closed: if not self._active: # already inactivated msg = (_("can't release already inactivated backup:" " dirstate%s") % self._suffix) raise error.Abort(msg) self._abort()