smtp.verifycert was accidentally broken by 799db3fe9866. And,
I believe the "loose" value has been broken for longer than that.
The current code refuses to talk to a remote server unless the
CA is trusted or the fingerprint is validated. In other words,
we lost the ability for smtp.verifycert to lower/disable security.
There are special considerations for smtp.verifycert in
sslutil.validatesocket() (the "strict" argument). This violates
the direction sslutil is evolving towards, which has all security
options determined at wrapsocket() time and a unified code path and
configs for determining security options.
Since smtp.verifycert is broken and since we'll soon have new
security defaults and new mechanisms for controlling host security,
this patch formally deprecates smtp.verifycert. With this patch,
the socket security code in mail.py now effectively mirrors code
in url.py and other places we're doing socket security.
For the record, removing smtp.verifycert because it was accidentally
broken is a poor excuse to remove it. However, I would have done this
anyway because smtp.verifycert is a one-off likely used by few people
(users of the patchbomb extension) and I don't think the existence
of this seldom-used one-off in security code can be justified,
especially when you consider that better mechanisms are right around
the corner.
This message has been overlooked by check-code, because it starts with
non-alphabet character ('\').
Making this message translatable seems reasonable, because messages
below in same function are already translatable
- '\ndiffs (truncated from %d to %d lines):\n\n'
- '\ndiffs (%d lines):\n\n'
This is also a part of preparation for making "missing _() in ui
message" detection of check-code more exact.
This message has been overlooked by check-code, because it starts with
non-alphabet character ('%').
This is also a part of preparation for making "missing _() in ui
message" detection of check-code more exact.
Most commands use opts.get() to retrieve values for options
that may not be explicitly passed. purge wasn't.
This makes it easier to call purge() from 3rd party extensions.
Files that are already in local store should be checked locally. The problem
with this implementation is how difference in messages between local and remote
checks should look like. For now local errors for file missing and content
corrupted looks like this:
'changeset cset: filename references missing storepath\n'
'changeset cset: filename references corrupted storepath\n'
for remote it looks like:
'changeset cset: filename missing\n'
'changeset cset: filename: contents differ\n'
Contents differ error for remote calls is never raised currently - for now
statlfile implementation lacks checking file content.
This allows users to start a commit with "verb! ..." so that when this is
opened in histedit, the default action will be "verb". For example, "roll! foo"
will default to the action "roll". Currently, we'll allow any known verb to be
used but this is experimental.
Since (b) is banned, we should do the same for (a) for consistency.
a) from mercurial import hg
from mercurial.i18n import _
b) from . import hg
from .i18n import _
The [alias] config section affects a global state: commands.table. It's hard
to trace whether an alias is added by a config option or an extension, and
add/remove aliases in a safe way per chg request. It will hurt performance a
bit if we clean the table and parse aliases every time. Therefore let's just
add it to confighash.
This will make chg pass test-pager.t.
Since we expand environment variables in alias lazily, the _clearenvaliases
hack is no longer necessary.
This resolves an issue that a non-shell alias which has environment variables
in its arguments and is set to use pager will not use pager running with chg.
Fixes CVE-2016-3105 (1/1).
Previously, it was possible for the repository path passed to git-ls-remote
to be misinterpreted as a URL.
Always passing an absolute path to git is a simple way to avoid this.
Before this patch, `hg pull --rebase` would be a strict sequence of `hg pull`
followed by `hg rebase` if anything was pulled.
Now that rebase pick his default destination the same way than merge, than
`hg rebase` step would abort in the case the repo already had multiple anonymous
heads (because of the ambiguity). (changed in 8822059a608a)
The intend of the user with `hg pull --rebase` is clearly to rebase on pulled
content. This used to be (mostly) enforced by the former default destination for
rebase, "tipmost changeset of the branch" as the tipmost would likely a
changeset that just got pulled. But this intended was no longer enforced with
the new defaul destination (unified with merge).
This changeset makes use of the '_destspace' mechanism introduced in the previous
changeset to enforce this.
This partially fixes issue5214 as no change at all have been made to the new
handling of the case with bookmark (unified with merge).
In the 'hg pull --rebase', we don't want to pick a rebase destination unrelated
to the pull, we lay down basic infrastructure to allow such restriction on
stable (before 3.8 release) in this case. See issue 5214 for details.
Actual usage and test will be in the next patch.
Windows command lines use double quotes to quote arguments with spaces.
This change is in a series to unify around using single quotes around
commands, and double quotes around interior arguments.
This changeset is taken on stable for consistency with similar update done
before the freeze.
See dc90bb772edc, 675a0be03493, 518b94d8f911 and 149a699cfd98.
Windows command lines use double quotes to quote arguments with spaces.
This change is in a series to unify around using single quotes around
commands, and double quotes around interior arguments.
This patch makes sure that either "tmpl" or "mapfile" is exclusively set,
which is the same behavior as common log-like templates and formatter outputs.
See the previous patch for why.
This prepares for the API change to support template aliases. I'm going to
extract a factory function of templater that reads a map file:
# original
templater(mapfile, ..., cache, ...)
# new
templater.frommapfile(mapfile, ...) # read mapfile to build cache/map
templater(..., cache, ...) # use specified cache (= map elements)
This will make it clear to isolate stock styles (i.e. map files) from user
aliases. Template aliases should be applied to command arguments and templates
in hgrc, but not to map files. Otherwise, our stock styles and web templates
could be modified unintentionally.
This patch makes sure that either "tmpl" or "mapfile" is exclusively set. It's
theoretically a behavior change, since you could put new keywords in template
by defining them in a map file before:
# mapfile
foo = "{rev}"
# hgrc
[bugzilla]
style = mapfile
template = {foo}
But the old behavior would be a bug because bugzilla.template is documented
as "overrides style if specified". Also, common log-like templates and
formatter doesn't allow using mapfile-keywords in a separate template. So
I decided to make a BC.
Since there was no test for the bugzilla extension, this adds new test that
covers style/template output.
This extension lets you direct specific ui.log() information to shell
commands, spawned in the background. This can be used to, say, capture
timings, commandfailure tracebacks, etc., making the output available
to other command-line tools.
Before, when converting revisions without also including their already
converted parents in convert.hg.revs, the parents would no longer be parents.
That seems unfortunate and we dare to assume that nobody ever wants that.
Instead, preserve parents that are outside the current convert range but
already have been converted.
The parents returned in getcommit() are unconditionally converted, so we
introduce a separate optparents with optional parents.
