Before this patch, the certificate of the SMTP server for STARTTLS or
SMTPS isn't verified.
This may cause man-in-the-middle security problem (stealing
authentication information), even though SMTP channel itself is
encrypted by SSL.
When "[smtp] tls" is configured as "smtps" or "starttls", this patch:
- uses classes introduced by preceding patches instead of "SMTP" or
"SMTP_SSL" of smtplib, and
- verifies the certificate of the SMTP server, if "[smtp]
verifycert" is configured as other than False
"[smtp] verifycert" can be configured in 3 levels:
- "strict":
This verifies peer certificate, and aborts if:
- peer certification is not valid, or
- no configuration in "[hostfingerprints]" and "[web] cacerts"
This is default value of "[smtp] verifycert" for security.
- "loose":
This verifies peer certificate, and aborts if peer certification is
not valid.
This just shows warning message ("certificate not verified"), if
there is no configuration in "[hostfingerprints]" and "[web]
cacerts".
This is as same as verification for HTTPS connection.
- False(no verification):
Peer certificate is not verified.
This is as same as the behavior before this patch series.
"hg email --insecure" uses "loose" level, and ignores "[web] cacerts"
as same as push/pull/etc... with --insecure.
Ignoring "[web] cacerts" configuration for "hg email --insecure" is
already done in "dispatch._dispatch()" by looking "insecure" up in the
table of command options.
The help text shows "-c/--confirm", which implies that -c is an alias
for --confirm. Actually, it is an alias for --cc. Correct the text
by removing -c.
Before this change, the thread hierarchy looked like this:
PARENT
PATCH1/x
PATCH2/x
PATCH3/x
...
Now it is:
PARENT
PATCH1/x
PATCH2/x
PATCH3/x
...
With an introductory message the behaviour is unchanged:
PARENT
INTRO
PATCH1/x
PATCH2/x
PATCH3/x
...
Another version could have returned a revset expression from
getoutgoing(), but we do not know how many times it will be resolved, so
better do it once explicitely.
There is currently no way to make patchbomb include patches both as attachments
and as inline text. This would be quite convenient when sending patches to
people who use web email clients (e.g. gmail) which often mangle the patches,
making them hard to apply.
The default behavior of the email command is unchanged. However it is now
possible to use the --body flag _in addition_ to the -i or -a flags, in which
case the patchbomb emails will contain the patch as inline body text and as an
attachment.
A new test has been added to test-patchbomb.t ("test attach for single
patch"), based on the existing test called "test attach for single patch" test.
This matches our pre-existing behavior from:
changeset: 12197:0a3b85866451
user: Christian Ebert <blacktrash@gmx.net>
files: hgext/patchbomb.py tests/test-patchbomb.t
description:
patchbomb: show prompt and selection in non-interactive mode
changeset: 8940:023d1310d8a4
user: Mads Kiilerich <mads@kiilerich.com>
date: Sun Jun 21 03:13:38 2009 +0200
files: mercurial/ui.py tests/test-merge-prompt.out tests/test-merge-tools.out
description:
ui.prompt: Show prompt and selection in non-interactive mode
- prompt(): respect interactive mode; clarify logic a bit
- rename introneeded() to introwanted() and give it only one caller
- add 'numbered' arg to makepatch() so it does not need to call
introwanted()
- factor makeintro() out of getpatchmsgs(), so it's easier to skip the
intro message based on the user's behaviour
Unexpected but perfectly reasonable side effect: in non-interactive
mode, we don't show unanswerable "Cc" or "From" prompts anymore, so
remove those from the test expectations.
The introduction of the new URL parsing code has created a startup
time regression. This is mainly due to the use of url.hasscheme() in
the ui class. It ends up importing many libraries that the url module
requires.
This fix helps marginally, but if we can get rid of the urllib import
in the URL parser all together, startup time will go back to normal.
perfstartup time before the URL refactoring (707e4b1e8064):
! wall 0.050692 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
current startup time (9ad1dce9e7f4):
! wall 0.070685 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
after this change:
! wall 0.064667 comb 0.000000 user 0.000000 sys 0.000000 (best of 100)
This is a long desired cleanup and paves the way for new discovery.
To specify subsets for bundling changes, all code should use the heads
of the desired subset ("heads") and the heads of the common subset
("common") to be excluded from the bundled set. These can be used
revlog.findmissing instead of revlog.nodesbetween.
This fixes an actual bug exposed by the change in test-bundle-r.t
where we try to bundle a changeset while specifying that said changeset
is to be assumed already present in the target. This used to still
bundle the changeset. It no longer does. This is similar to the bugs
fixed by the recent switch to heads/common for incoming/pull.
Add missing calls to close() to many places where files are
opened. Relying on reference counting to catch them soon-ish is not
portable and fails in environments with a proper GC, such as PyPy.
While both '\ ' and '\\ ' parse the same in Python, the difference
trips up hggettext so that it cannot find the docstring in the source
file and thus cannot write the right line number to i18n/hg.pot.
While the line number is not essential, it can be used to lookup the
original message.
--confirm presents same prompt as --diffstat, but does not write
a diffstat to the messages' bodies.
A simple test simulating a negative response is included.
This changes the behaviour of --diffstat.
Before the user was asked for confirmation of each patch with its
description and diffstat, and a final summary.
Now there is only one prompt right before sending with a final
summary which does not include the patch descriptions, but the
message details and the diffstats:
Final summary:
From: sender
To: recipient(s)
Cc: (if present)
Bcc: (if present)
Reply-To: (if present)
Subject: [patch 0 of x [flags]] intro (if present)
a | 28 ++++++++++++++++++++++++++++
b | 15 +++++++++++++++
Subject: [patch 1 of x [flags]] subject
a | 28 ++++++++++++++++++++++++++++
[ ... ]
are you sure you want to send (yn)?
this helps users to know what kind of option is:
- no value is required(flag option)
- value is required
- value is required, and multiple occurrences are allowed
each kinds are shown as below:
-f --force force push
-e --ssh CMD specify ssh command to use
-b --branch BRANCH [+] a specific branch you would like to push
if one or more 3rd type options are shown, explanation for '[+]' mark
is also shown as footnote.
