Fri, 10 Jun 2016 00:10:06 -0400 store: use hashlib.sha1 directly instead of through util
Augie Fackler <raf@durin42.com> [Fri, 10 Jun 2016 00:10:06 -0400] rev 29338
store: use hashlib.sha1 directly instead of through util Also remove module-local alias to _sha, since it's not used that much.
Fri, 10 Jun 2016 00:14:43 -0400 similar: delete extra newline at EOF
Augie Fackler <raf@durin42.com> [Fri, 10 Jun 2016 00:14:43 -0400] rev 29337
similar: delete extra newline at EOF Spotted by my emacs config that cleans up extra whitespace.
Fri, 10 Jun 2016 00:14:10 -0400 scmutil: delete extra newline at EOF
Augie Fackler <raf@durin42.com> [Fri, 10 Jun 2016 00:14:10 -0400] rev 29336
scmutil: delete extra newline at EOF Spotted by my emacs config that cleans up extra whitespace.
Wed, 08 Jun 2016 16:18:43 +0100 graphmod: avoid sorting when already sorted
Martijn Pieters <mjpieters@fb.com> [Wed, 08 Jun 2016 16:18:43 +0100] rev 29335
graphmod: avoid sorting when already sorted This is somewhat redundant now, but allows us to add a toposort that should not be re-sorted either.
Tue, 07 Jun 2016 20:29:54 -0700 sslutil: per-host config option to define certificates
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 07 Jun 2016 20:29:54 -0700] rev 29334
sslutil: per-host config option to define certificates Recent work has introduced the [hostsecurity] config section for defining per-host security settings. This patch builds on top of this foundation and implements the ability to define a per-host path to a file containing certificates used for verifying the server certificate. It is logically a per-host web.cacerts setting. This patch also introduces a warning when both per-host certificates and fingerprints are defined. These are mutually exclusive for host verification and I think the user should be alerted when security settings are ambiguous because, well, security is important. Tests validating the new behavior have been added. I decided against putting "ca" in the option name because a non-CA certificate can be specified and used to validate the server certificate (commonly this will be the exact public certificate used by the server). It's worth noting that the underlying Python API used is load_verify_locations(cafile=X) and it calls into OpenSSL's SSL_CTX_load_verify_locations(). Even OpenSSL's documentation seems to omit that the file can contain a non-CA certificate if it matches the server's certificate exactly. I thought a CA certificate was a special kind of x509 certificate. Perhaps I'm wrong and any x509 certificate can be used as a CA certificate [as far as OpenSSL is concerned]. In any case, I thought it best to drop "ca" from the name because this reflects reality.
Fri, 27 May 2016 23:18:38 +0900 tests: add basic tests for SMTP over SSL
Yuya Nishihara <yuya@tcha.org> [Fri, 27 May 2016 23:18:38 +0900] rev 29333
tests: add basic tests for SMTP over SSL SSL handling in mail.py wasn't covered by our test suite, therefore it was sometimes broken. This patch introduces pretty minimal tests that only cover the default path. We can extend it later. Tested with python 2.6.9 and 2.7.11 on Debian sid.
Fri, 27 May 2016 22:43:47 +0900 tests: add dummy SMTP daemon for SSL tests
Yuya Nishihara <yuya@tcha.org> [Fri, 27 May 2016 22:43:47 +0900] rev 29332
tests: add dummy SMTP daemon for SSL tests Currently it only supports SMTP over SSL since SMTPS should be simpler than handling StartTLS. Since we don't need asynchronous server for our tests, it does TLS handshake in blocking way. But asyncore is required by Python smtpd module.
Fri, 27 May 2016 22:40:09 +0900 tests: extract SSL certificates from test-https.t
Yuya Nishihara <yuya@tcha.org> [Fri, 27 May 2016 22:40:09 +0900] rev 29331
tests: extract SSL certificates from test-https.t They can be reused in SMTPS tests.
Tue, 31 May 2016 21:49:49 +0900 check-code: make 'ls' pattern less invasive
Yuya Nishihara <yuya@tcha.org> [Tue, 31 May 2016 21:49:49 +0900] rev 29330
check-code: make 'ls' pattern less invasive I got false positive at "--tls smtps --certificate ...".
Tue, 07 Jun 2016 08:32:33 +0200 largefiles: fix support for local largefiles while using share extension stable
Henrik Stuart <henriks@unity3d.com> [Tue, 07 Jun 2016 08:32:33 +0200] rev 29329
largefiles: fix support for local largefiles while using share extension Prior to revision 2a3f24786d09, largefiles were saved in the local repository, even if it was using the share extension. After that change, all largefiles are now stored in the shared repository. However, the backward compatibility for existing largefiles already placed in the local repository was never tested, and has been broken since.
Thu, 09 Jun 2016 13:47:42 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 09 Jun 2016 13:47:42 -0500] rev 29328
merge with stable
Tue, 07 Jun 2016 11:57:11 +0200 crecord: drop unused "operation" parameter from filterpatch function
Denis Laxalde <denis.laxalde@logilab.fr> [Tue, 07 Jun 2016 11:57:11 +0200] rev 29327
crecord: drop unused "operation" parameter from filterpatch function
Tue, 07 Jun 2016 10:37:19 +0200 patch: define full messages for interactive record/revert
Denis Laxalde <denis.laxalde@logilab.fr> [Tue, 07 Jun 2016 10:37:19 +0200] rev 29326
patch: define full messages for interactive record/revert Followup 14eee72c8d52 to provide complete context for proper localization. Also update cmdutil.recordfilter docstring to remove recommendation that "operation" argument should be translated. Indeed, for record/revert, we either go to patch.filterpatch or crecord.filterpatch (in curses mode) ; the former now build the full ui message from the operation parameter and the latter does not use this parameter (removing in a followup patch). For shelve, operation is not specified and this thus falls back to "record".
Wed, 01 Jun 2016 15:16:38 +0200 hgweb: remove unused code in annotate web command
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 01 Jun 2016 15:16:38 +0200] rev 29325
hgweb: remove unused code in annotate web command
Sat, 04 Jun 2016 14:38:00 +0530 py3: conditionalize cPickle import by adding in util
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 04 Jun 2016 14:38:00 +0530] rev 29324
py3: conditionalize cPickle import by adding in util The cPickle is renamed to _pickle in python3 and this C extension is available in pickle which was not included in earlier versions. So imports are conditionalized to import cPickle in py2 and pickle in py3. Moreover the use of pickle in py2 is switched to cPickle as the C extension is faster. The hack is added in util.py and the modules import util.pickle
Thu, 02 Jun 2016 17:11:32 -0500 bdiff: remove effectively dead code stable
Matt Mackall <mpm@selenic.com> [Thu, 02 Jun 2016 17:11:32 -0500] rev 29323
bdiff: remove effectively dead code Now that we extend matches backwards in the inner loop, the final adjustment has no effect. (A similar extension for the forward direction is trickier and has less benefit.)
Thu, 02 Jun 2016 17:09:06 -0500 bdiff: extend matches across popular lines stable
Matt Mackall <mpm@selenic.com> [Thu, 02 Jun 2016 17:09:06 -0500] rev 29322
bdiff: extend matches across popular lines For very large diffs that have large numbers of identical lines (JSON dumps) that also have large blocks of identical text, bdiff could become confused about which block matches which because it can only match very limited regions. The result is very large diffs for small sets of edits. The earlier recursion rebalancing fix made this behavior more frequent because it's now more prone to match block 1 to block 2. One frequent user of large JSON files reported being unable to pass the resulting diffs through their code review system. Prior to this change, bdiff would calculate the length of a match at (i, j) as 1 + length found at (i-1, j-1). With large number of popular (ignored) lines, this often meant matches couldn't be extended backwards at all and thus all matching regions were very small. Disabling the popularity threshold is not an option because it brings back quadratic behavior. Instead, we extend a match backwards until we either found a previously discovered match or we find a mismatching line. This thus successfully bridges over any popular lines inside and before a matching region. The larger regions then significant reduce the probability of confusion.
Fri, 03 Jun 2016 21:49:26 +0900 test-revset: fix test vector for ordering issue of matching()
Yuya Nishihara <yuya@tcha.org> [Fri, 03 Jun 2016 21:49:26 +0900] rev 29321
test-revset: fix test vector for ordering issue of matching() 592e0beee8b0 fixed matching() to preserve the order of the input set, but the test was incorrect. Given "A and B", "A" should be the input set to "B". But thanks to our optimizer, the test expression was rewritten as "(2 or 3 or 1) and matching(1 or 2 or 3)", therefore it was working well. Since I'm going to fix the overall ordering issue, the test needs to be adjusted to do the right thing.
Fri, 20 May 2016 01:42:04 +0200 largefiles: rename match_ to matchmod import in lfutil
liscju <piotr.listkiewicz@gmail.com> [Fri, 20 May 2016 01:42:04 +0200] rev 29320
largefiles: rename match_ to matchmod import in lfutil
Thu, 12 May 2016 11:49:23 +0200 largefiles: rename match_ to matchmod import in reposetup
liscju <piotr.listkiewicz@gmail.com> [Thu, 12 May 2016 11:49:23 +0200] rev 29319
largefiles: rename match_ to matchmod import in reposetup
Thu, 12 May 2016 11:48:39 +0200 largefiles: rename match_ to matchmod import in overrides
liscju <piotr.listkiewicz@gmail.com> [Thu, 12 May 2016 11:48:39 +0200] rev 29318
largefiles: rename match_ to matchmod import in overrides
Thu, 12 May 2016 11:36:51 +0200 largefiles: rename match_ to matchmod import in lfcommands
liscju <piotr.listkiewicz@gmail.com> [Thu, 12 May 2016 11:36:51 +0200] rev 29317
largefiles: rename match_ to matchmod import in lfcommands
Tue, 10 May 2016 15:20:04 +0200 py3: make largefiles/wirestore.py use absolute_import
liscju <piotr.listkiewicz@gmail.com> [Tue, 10 May 2016 15:20:04 +0200] rev 29316
py3: make largefiles/wirestore.py use absolute_import
Tue, 10 May 2016 15:14:41 +0200 py3: make largefiles/uisetup.py use absolute_import
liscju <piotr.listkiewicz@gmail.com> [Tue, 10 May 2016 15:14:41 +0200] rev 29315
py3: make largefiles/uisetup.py use absolute_import
Tue, 10 May 2016 15:04:22 +0200 py3: make largefiles/reposetup.py use absolute_import
liscju <piotr.listkiewicz@gmail.com> [Tue, 10 May 2016 15:04:22 +0200] rev 29314
py3: make largefiles/reposetup.py use absolute_import
Tue, 10 May 2016 15:00:22 +0200 py3: make largefiles/remotestore.py use absolute_import
liscju <piotr.listkiewicz@gmail.com> [Tue, 10 May 2016 15:00:22 +0200] rev 29313
py3: make largefiles/remotestore.py use absolute_import
Tue, 10 May 2016 14:41:58 +0200 py3: make largefiles/proto.py use absolute_import
liscju <piotr.listkiewicz@gmail.com> [Tue, 10 May 2016 14:41:58 +0200] rev 29312
py3: make largefiles/proto.py use absolute_import
Tue, 10 May 2016 14:26:36 +0200 py3: make largefiles/overrides.py use absolute_import
liscju <piotr.listkiewicz@gmail.com> [Tue, 10 May 2016 14:26:36 +0200] rev 29311
py3: make largefiles/overrides.py use absolute_import
Tue, 10 May 2016 14:20:51 +0200 py3: make largefiles/localstore.py use absolute_import
liscju <piotr.listkiewicz@gmail.com> [Tue, 10 May 2016 14:20:51 +0200] rev 29310
py3: make largefiles/localstore.py use absolute_import
Tue, 10 May 2016 15:09:22 +0200 py3: make largefiles/lfutil.py use absolute_import
liscju <piotr.listkiewicz@gmail.com> [Tue, 10 May 2016 15:09:22 +0200] rev 29309
py3: make largefiles/lfutil.py use absolute_import
Sat, 07 May 2016 15:44:46 +0200 py3: make largefiles/lfcommands.py use absolute_import
liscju <piotr.listkiewicz@gmail.com> [Sat, 07 May 2016 15:44:46 +0200] rev 29308
py3: make largefiles/lfcommands.py use absolute_import
Fri, 06 May 2016 14:30:23 +0200 py3: make largefiles/basestore.py use absolute_import
liscju <piotr.listkiewicz@gmail.com> [Fri, 06 May 2016 14:30:23 +0200] rev 29307
py3: make largefiles/basestore.py use absolute_import
Fri, 06 May 2016 14:28:32 +0200 py3: make largefiles/__init__.py use absolute_import
liscju <piotr.listkiewicz@gmail.com> [Fri, 06 May 2016 14:28:32 +0200] rev 29306
py3: make largefiles/__init__.py use absolute_import
Sat, 04 Jun 2016 16:53:44 +0200 largefiles: move basestore._openstore into new module to remove cycle
liscju <piotr.listkiewicz@gmail.com> [Sat, 04 Jun 2016 16:53:44 +0200] rev 29305
largefiles: move basestore._openstore into new module to remove cycle
Thu, 02 Jun 2016 22:39:01 +0100 revset: make filteredset.__nonzero__ respect the order of the filteredset
Kostia Balytskyi <ikostia@fb.com> [Thu, 02 Jun 2016 22:39:01 +0100] rev 29304
revset: make filteredset.__nonzero__ respect the order of the filteredset This fix allows __nonzero__ to respect the direction of iteration of the whole filteredset. Here's the case when it matters. Imagine that we have a very large repository and we want to execute a command like: $ hg log --rev '(tip:0) and user(ikostia)' --limit 1 (we want to get the latest commit by me). Mercurial will evaluate a filteredset lazy data structure, an instance of the filteredset class, which will know that it has to iterate in a descending order (isdescending() will return True if called). This means that when some code iterates over the instance of this filteredset, the 'and user(ikostia)' condition will be first checked on the latest revision, then on the second latest and so on, allowing Mercurial to print matches as it founds them. However, cmdutil.getgraphlogrevs contains the following code: revs = _logrevs(repo, opts) if not revs: return revset.baseset(), None, None The "not revs" expression is evaluated by calling filteredset.__nonzero__, which in its current implementation will try to iterate the filteredset in ascending order until it finds a revision that matches the 'and user(..' condition. If the condition is only true on late revisions, a lot of useless iterations will be done. These iterations could be avoided if __nonzero__ followed the order of the filteredset, which in my opinion is a sensible thing to do here. The problem gets even worse when instead of 'user(ikostia)' some more expensive check is performed, like grepping the commit diff. I tested this fix on a very large repo where tip is my commit and my very first commit comes fairly late in the revision history. Results of timing of the above command on that very large repo. -with my fix: real 0m1.795s user 0m1.657s sys 0m0.135s -without my fix: real 1m29.245s user 1m28.223s sys 0m0.929s I understand that this is a very specific kind of problem that presents itself very rarely, only on very big repositories and with expensive checks and so on. But I don't see any disadvantages to this kind of fix either.
Fri, 03 Jun 2016 00:44:20 +0900 phases: make writing phaseroots file out avoid ambiguity of file stat
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 03 Jun 2016 00:44:20 +0900] rev 29303
phases: make writing phaseroots file out avoid ambiguity of file stat Cached attribute repo._phasecache uses stat of '.hg/phaseroots' file to examine validity of cached contents. If writing '.hg/phaseroots' file out keeps ctime, mtime and size of it, change is overlooked, and old contents cached before change isn't invalidated as expected. To avoid ambiguity of file stat, this patch writes '.hg/phaseroots' file out with checkambig=True. This patch is a part of "Exact Cache Validation Plan": https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan
Fri, 03 Jun 2016 00:44:20 +0900 dirstate: make writing branch file out avoid ambiguity of file stat
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 03 Jun 2016 00:44:20 +0900] rev 29302
dirstate: make writing branch file out avoid ambiguity of file stat Cached attribute dirstate._branch uses stat of '.hg/branch' file to examine validity of cached contents. If writing '.hg/branch' file out keeps ctime, mtime and size of it, change is overlooked, and old contents cached before change isn't invalidated as expected. To avoid ambiguity of file stat, this patch writes '.hg/branch' file out with checkambig=True. This patch is a part of "Exact Cache Validation Plan": https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan
Fri, 03 Jun 2016 00:44:20 +0900 dirstate: make writing dirstate file out avoid ambiguity of file stat
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 03 Jun 2016 00:44:20 +0900] rev 29301
dirstate: make writing dirstate file out avoid ambiguity of file stat Cached attribute repo.dirstate uses stat of '.hg/dirstate' file to examine validity of cached contents. If writing '.hg/dirstate' file out keeps ctime, mtime and size of it, change is overlooked, and old contents cached before change isn't invalidated as expected. To avoid ambiguity of file stat, this patch writes '.hg/dirstate' file out with checkambig=True. The former diff hunk changes the code path for "dirstate.write()", and the latter changes the code path for "dirstate.savebackup()". This patch is a part of "Exact Cache Validation Plan": https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan
Fri, 03 Jun 2016 00:44:20 +0900 bookmarks: make writing files out avoid ambiguity of file stat
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 03 Jun 2016 00:44:20 +0900] rev 29300
bookmarks: make writing files out avoid ambiguity of file stat Cached attribute repo._bookmarks uses stat of '.hg/bookmarks' and '.hg/bookmarks.current' files to examine validity of cached contents. If writing these files out keeps ctime, mtime and size of them, change is overlooked, and old contents cached before change isn't invalidated as expected. To avoid ambiguity of file stat, this patch writes '.hg/bookmarks' and '.hg/bookmarks.current' files out with checkambig=True. This patch is a part of "Exact Cache Validation Plan": https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan
Fri, 03 Jun 2016 00:44:20 +0900 transaction: avoid ambiguity of file stat at closing transaction
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 03 Jun 2016 00:44:20 +0900] rev 29299
transaction: avoid ambiguity of file stat at closing transaction Files below, which might be changed at closing transaction, are used to examine validity of cached properties. If changing keeps ctime, mtime and size of a file, change is overlooked, and old contents cached before change isn't invalidated as expected. - .hg/bookmarks - .hg/dirstate - .hg/phaseroots To avoid ambiguity of file stat, this patch writes files out with checkambig=True at closing transaction. checkambig becomes True only at closing (= 'not suffix'), because stat information of '.pending' file isn't used to examine validity of cached properties. This patch is a part of "Exact Cache Validation Plan": https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan
Fri, 03 Jun 2016 00:44:20 +0900 util: add __ne__ to filestat class for consistency
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 03 Jun 2016 00:44:20 +0900] rev 29298
util: add __ne__ to filestat class for consistency This is follow up for ca4065028e00, which introduced filestat class.
Sat, 16 Apr 2016 16:01:24 -0700 style: remove namespace class
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 16 Apr 2016 16:01:24 -0700] rev 29297
style: remove namespace class For better or worse, our coding do not use use class for pure namespacing. We remove the class introduced in a5009789960c.
Sat, 16 Apr 2016 15:59:30 -0700 style: don't use capital letter for constant
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 16 Apr 2016 15:59:30 -0700] rev 29296
style: don't use capital letter for constant For better or worse, our coding do not use all caps for constants. We rename constant name introduced in a5009789960c.
Thu, 02 Jun 2016 16:18:44 -0700 tests-subrepo-git: use "f" to dump pwned.txt, for portability stable
Danek Duvall <danek.duvall@oracle.com> [Thu, 02 Jun 2016 16:18:44 -0700] rev 29295
tests-subrepo-git: use "f" to dump pwned.txt, for portability Rather than sometimes using a complicated shell construct to dump pwned.txt (if it wasn't expected to exist, but might, if something were broken) or just cat (if it was expected to exist), just use the "f" utility, which will be consistent in its behavior across different platforms. Also make sure that *something* gets put into pwned.txt, even if we ended up typoing the message variable.
Wed, 01 Jun 2016 21:40:52 +0200 bundle2: don't assume ordering of heads checked after push stable
Mads Kiilerich <madski@unity3d.com> [Wed, 01 Jun 2016 21:40:52 +0200] rev 29294
bundle2: don't assume ordering of heads checked after push Usually, the heads will have the same ordering in handlecheckheads. Insisting on the same ordering is however an unnecessary constraint that in some custom cases can cause pushes to fail even though the actual heads didn't change. This caused production issues for us in combination with the current version of https://bitbucket.org/Unity-Technologies/hgwebcachingproxy/ .
Sat, 04 Jun 2016 11:16:08 -0700 sslutil: print the fingerprint from the last hash used
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 04 Jun 2016 11:16:08 -0700] rev 29293
sslutil: print the fingerprint from the last hash used Before, we would always print the unprefixed SHA-1 fingerprint when fingerprint comparison failed. Now, we print the fingerprint of the last hash used, including the prefix if necessary. This helps ensure that the printed hash type matches what is in the user configuration. There are still some cases where this can print a mismatched hash type. e.g. if there are both SHA-1 and SHA-256 fingerprints in the config, we could print a SHA-1 hash if it comes after the SHA-256 hash. But I'm inclined to ignore this edge case. While I was here, the "section" variable assignment has been moved to just above where it is used because it is now only needed for this error message and it makes the code easier to read.
Tue, 31 May 2016 19:21:08 -0700 sslutil: make cert fingerprints messages more actionable
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 31 May 2016 19:21:08 -0700] rev 29292
sslutil: make cert fingerprints messages more actionable The previous warning and abort messages were difficult to understand. This patch makes them slightly better. I think there is still room to tweak the messaging. And as we adopt new security defaults, these messages will certainly change again. But at least this takes us a step in the right direction. References to "section" have been removed because if no fingerprint is defined, "section" can never be "hostfingerprints." So just print "hostsecurity" every time.
Mon, 30 May 2016 15:43:03 -0700 sslutil: refactor code for fingerprint matching
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 May 2016 15:43:03 -0700] rev 29291
sslutil: refactor code for fingerprint matching We didn't need to use a temporary variable to indicate success because we just return anyway. This refactor makes the code simpler. While we're here, we also call into formatfingerprint() to ensure the fingerprint from the proper hashing algorithm is logged.
Mon, 30 May 2016 15:42:39 -0700 sslutil: print SHA-256 fingerprint by default
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 May 2016 15:42:39 -0700] rev 29290
sslutil: print SHA-256 fingerprint by default The world is starting to move on from SHA-1. A few commits ago, we gained the ability to define certificate fingerprints using SHA-256 and SHA-512. Let's start printing the SHA-256 fingerprint instead of the SHA-1 fingerprint to encourage people to pin with a more secure hashing algorithm. There is still a bit of work to be done around the fingerprint messaging. This will be addressed in subsequent commits.
Mon, 30 May 2016 13:15:53 -0700 sslutil: move and change warning when cert verification is disabled
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 May 2016 13:15:53 -0700] rev 29289
sslutil: move and change warning when cert verification is disabled A short time ago, validatesocket() didn't know the reasons why cert verification was disabled. Multiple code paths could lead to cert verification being disabled. e.g. --insecure and lack of loaded CAs. With the recent refactorings to sslutil.py, we now know the reasons behind security settings. This means we can recognize when the user requested security be disabled (as opposed to being unable to provide certificate verification due to lack of CAs). This patch moves the check for certificate verification being disabled and changes the wording to distinguish it from other states. The warning message is purposefully more dangerous sounding in order to help discourage people from disabling security outright. We may want to add a URL or hint to this message. I'm going to wait until additional changes to security defaults before committing to something.
Wed, 01 Jun 2016 19:57:20 -0700 sslutil: add devel.disableloaddefaultcerts to disable CA loading
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 01 Jun 2016 19:57:20 -0700] rev 29288
sslutil: add devel.disableloaddefaultcerts to disable CA loading There are various tests for behavior when CA certs aren't loaded. Previously, we would pass --insecure to disable loading of CA certs. This has worked up to this point because the error message for --insecure and no CAs loaded is the same. Upcoming commits will change the error message for --insecure and will change behavior when CAs aren't loaded. This commit introduces the ability to disable loading of CA certs by setting devel.disableloaddefaultcerts. This allows a testing backdoor to disable loading of CA certs even if system/default CA certs are available. The flag is purposefully not exposed to end-users because there should not be a need for this in the wild: certificate pinning and --insecure provide workarounds to disable cert loading/validation. Tests have been updated to use the new method. The variable used to disable CA certs has been renamed because the method is not OS X specific.
Mon, 30 May 2016 11:20:31 -0700 sslutil: store flag for whether cert verification is disabled
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 May 2016 11:20:31 -0700] rev 29287
sslutil: store flag for whether cert verification is disabled This patch effectively moves the ui.insecureconnections check to _hostsettings(). After this patch, validatesocket() no longer uses the ui instance for anything except writing messages. This patch also enables us to introduce a per-host config option for disabling certificate verification.
Mon, 30 May 2016 11:19:43 -0700 sslutil: remove "strict" argument from validatesocket()
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 30 May 2016 11:19:43 -0700] rev 29286
sslutil: remove "strict" argument from validatesocket() It was only used by mail.py as part of processing smtp.verifycert, which was just removed.
Sat, 04 Jun 2016 11:13:28 -0700 mail: unsupport smtp.verifycert (BC)
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 04 Jun 2016 11:13:28 -0700] rev 29285
mail: unsupport smtp.verifycert (BC) smtp.verifycert was accidentally broken by cca59ef27e60. 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.
Tue, 05 Apr 2016 07:30:01 +0200 update: fix bare --clean to work on new branch (issue5003) (BC)
liscju <piotr.listkiewicz@gmail.com> [Tue, 05 Apr 2016 07:30:01 +0200] rev 29284
update: fix bare --clean to work on new branch (issue5003) (BC) Before this commit bare update --clean on newly created branch updates to the parent commit, even if there are later commits on the parent commit's branch. Update to the latest head on the parent commit's branch instead. This seems reasonable as clean should discard uncommited changes, branch is one of them.
Fri, 03 Jun 2016 15:55:07 +0200 revert: use "discard"/"revert" verb when reverting interactively (issue5143)
Denis Laxalde <denis.laxalde@logilab.fr> [Fri, 03 Jun 2016 15:55:07 +0200] rev 29283
revert: use "discard"/"revert" verb when reverting interactively (issue5143) Instead of "record this change to 'FILE'?" now prompt with: * "discard this change to 'FILE'?" when reverting to the parent of working directory, and, * "revert this change to 'FILE'?" otherwise.
Tue, 05 Apr 2016 01:35:58 +0000 run-tests: add support for RTUNICODEPEDANTRY environment variable
timeless <timeless@mozdev.org> [Tue, 05 Apr 2016 01:35:58 +0000] rev 29282
run-tests: add support for RTUNICODEPEDANTRY environment variable based on 73e4a02e6d23
Fri, 27 May 2016 05:24:45 +0000 obsolete: fix grammar
timeless <timeless@mozdev.org> [Fri, 27 May 2016 05:24:45 +0000] rev 29281
obsolete: fix grammar
Sun, 03 Apr 2016 20:49:30 +0000 tests: add run-test .testtimes basic testing
timeless <timeless@mozdev.org> [Sun, 03 Apr 2016 20:49:30 +0000] rev 29280
tests: add run-test .testtimes basic testing
Tue, 31 May 2016 21:02:30 +0900 check-code: make repquote distinguish more characters for exact detection
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 31 May 2016 21:02:30 +0900] rev 29279
check-code: make repquote distinguish more characters for exact detection This patch makes repquote() distinguish more characters below, as a preparation for exact detection in subsequent patch. - "%" as "%" - "\\" as "b"(ackslash) - "*" as "A"(sterisk) - "+" as "P"(lus) - "-" as "M"(inus) Characters other than "%" don't use itself as replacement, because they are treated as special ones in regexp.
(0) -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 +10000 tip