- Jul 25, 2016
-
-
Gábor Stefanik authored
Make life easier for extension writers.
-
Gregory Szorc authored
SSLContext.get_ca_certs() can raise "ssl.SSLError: unknown error (_ssl.c:636)" on Windows. See https://bugs.python.org/issue20916 for more info. We add a try..except that swallows the exception to work around this bug. If we encounter the bug, we won't print a warning message about attempting to load CA certificates. This is unfortunate. But there appears to be little we can do :/
-
- Jul 18, 2016
-
-
Matt Mackall authored
The existing code (a) assumed path would be specified in encoding.encoding and (b) assumed unicode() objects wouldn't cause other parts of Mercurial to blow up. Both are dangerous assumptions. Since we don't know the encoding of path and can't pass non-ASCII through docstrings, just escape the path and drop the early _(). Will have to suffice until we can teach docstrings to handle UTF-8b escaping. This has the side-effect that the line containing the path is now variable by the time it reaches _() and thus can't be translated.
-
- Jul 21, 2016
-
-
Kostia Balytskyi authored
In 1e4512eac59e, I introduced a new bug: when a symlink points to a folder in commit A and to another folder in commit B, while updating from A to B, Mercurial will try to use removedir on this symlink, which will fail. This is a very bad bug, since it basically renders symlinks to folders unusable in repos. Added test case fails without a fix and passes with it.
-
- Jul 25, 2016
-
-
Anton Shestakov authored
-
Anton Shestakov authored
-
Anton Shestakov authored
-
Anton Shestakov authored
-
- Jul 22, 2016
-
-
Yuya Nishihara authored
Since the default joinfmt() can't process a dict of multiple keywords, we need a dedicated joinfmt for showparents(). Unlike revset(), parents are formatted as '{rev}:{node|formatnode}' by default. We copy the default formatting just like showextras() and showfilecopies() do.
-
Yuya Nishihara authored
It's been broken since e4609ec959f8, which made makemap() return a dict of multiple keywords. Because the default joinfmt() randomly picks one item from a dict, we have to make revset() select d[name] explicitly.
-
Hannes Oldenburg authored
Previously a subrepository "sub" would cause no warnings to be issued for a file "subnot/a" if it is not removed when calling: hg remove -S "subnot/a"
-
- Jul 20, 2016
-
-
Matt Mackall authored
-
- Jul 19, 2016
-
-
Wagner Bruna authored
-
- Jul 20, 2016
-
-
Gregory Szorc authored
There are various causes for the inability to negotiate common SSL/TLS protocol between client and server. Previously, we had a single, not very actionable warning message for all of them. As people encountered TLS 1.0 servers in real life, it was quickly obvious that the existing messaging was inadequate to help users rectify the situation. This patch makes the warning messages much more verbose in hopes of making them more actionable while simultaneously encouraging users and servers to adopt better security practices. This messaging flirts with the anti-pattern of "never blame the user" by signaling out poorly-configured servers. But if we're going to disallow TLS 1.0 by default, I think we need to say *something* or people are just going to blame Mercurial for not being able to connect. The messaging tries to exonerate Mercurial from being the at fault party by pointing out the server is the entity that doesn't support proper security (when appropriate, of course).
-
Gregory Szorc authored
This will be used in a subsequent patch to improve messaging.
-
Gregory Szorc authored
--insecure is our psuedo-supported footgun for disabling connection security. The flag already disables CA verification. I think allowing the use of TLS 1.0 when specified is appropriate.
-
Gregory Szorc authored
TIL that ui instances for remote/peer repos don't automagically inherit config options from .hg/hgrc files. This patch makes remote ui instances inherit options from the [hostsecurity] section. We were already inheriting options from [hostfingerprints] and [auth]. So adding [hostsecurity] to the list seems appropriate.
-
- Jul 18, 2016
-
-
Mads Kiilerich authored
The code used self._rbcnamescount as if it was the length of self._names ... but actually it is just the number of good entries on disk. This caused the cache to be populated inefficiently. In some cases very inefficiently. Instead of checking the length before lookup, just try a lookup in self._names - that is also in most cases faster. Comments and debug messages are tweaked to help understanding the issue and the fix.
-
Mads Kiilerich authored
-
- Jul 19, 2016
-
-
Gregory Szorc authored
versiontuple() was previously only splitting on '+' and strings like "3.9-rc" were causing it to misreport the version as (3, None). By splitting on either '+' or '-' we can handle our version strings with "-rc" in them.
-
Kevin Bullock authored
The inventory property was deprecated in favor of root_inventory in bzr 2.5.0. Current version is 2.7.0. I noticed this when testing locally on Python 2.6.9, which has warnings turned on by default. The failure that occurs without this patch can be seen on Python 2.7 by running with warnings enabled: $ PYTHONWARNINGS=::DeprecationWarning make 'test-convert-bzr*'
-
Yuya Nishihara authored
-
Simon Farnsworth authored
When the inhibit extension from mutable-history is enabled, it attempts to iterate over the rebaseset to prevent the nodes being rebased from being marked obsolete. This happens at the same time as rebase's _filterobsoleterevs function trying to iterate over the rebaseset to figure out which ones are obsolete. The two of these iterating over the same revset generatorset cause a 'generator already executing' exception. This is probably a flaw in the revset implementation, since iterating over the same set twice should be supported. This regression was introduced in 5d16ebe7b14f, since it changed _filterobsoleterevs to be called before the rebaseset was turned into a set(). For now let’s just make the rebaseset an actual set again before calling that function. This was caught by the inhibit tests. The relevant call stack from test-inhibit.t: File "/tmp/hgtests.jgjrN5/install/lib/python/hgext/rebase.py", line 285, in _preparenewrebase obsrevs = _filterobsoleterevs(self.repo, rebaseset) File "/data/hgbuild/facebook-hg-rpms/mutable-history/hgext/inhibit.py", line 197, in _filterobsoleterevswrap r = orig(repo, rebasesetrevs, *args, **kwargs) File "/tmp/hgtests.jgjrN5/install/lib/python/hgext/rebase.py", line 1380, in _filterobsoleterevs return set(r for r in revs if repo[r].obsolete()) File "/tmp/hgtests.jgjrN5/install/lib/python/hgext/rebase.py", line 1380, in <genexpr> return set(r for r in revs if repo[r].obsolete()) File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3079, in _iterordered val2 = next(iter2) File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3417, in gen yield nextrev() File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3424, in _consumegen for item in self._gen: File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 71, in iterate cl = repo.changelog File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 319, in changelog revs = filterrevs(unfi, self.filtername) File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 261, in filterrevs repo.filteredrevcache[filtername] = func(repo.unfiltered()) File "/data/hgbuild/facebook-hg-rpms/mutable-history/hgext/directaccess.py", line 65, in _computehidden hidden = repoview.filterrevs(repo, 'visible') File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 261, in filterrevs repo.filteredrevcache[filtername] = func(repo.unfiltered()) File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 175, in computehidden hideable = hideablerevs(repo) File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/repoview.py", line 33, in hideablerevs return obsolete.getrevs(repo, 'obsolete') File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/obsolete.py", line 1097, in getrevs repo.obsstore.caches[name] = cachefuncs[name](repo) File "/data/hgbuild/facebook-hg-rpms/mutable-history/hgext/inhibit.py", line 255, in _computeobsoleteset if getrev(n) not in blacklist: File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3264, in __contains__ return x in self._r1 or x in self._r2 File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3348, in __contains__ for l in self._consumegen(): File "/tmp/hgtests.jgjrN5/install/lib/python/mercurial/revset.py", line 3424, in _consumegen for item in self._gen: ValueError: generator already executing
-
- Jul 18, 2016
-
-
Jun Wu authored
Now setpgid has 2 main purposes: better handling for terminal-generated SIGTSTP, SIGINT, and process-exit-generated SIGHUP. Update the comment to explain things more clearly.
-
- Jul 17, 2016
-
-
Jun Wu authored
These signals are meant to send to a process group, instead of a single process: SIGINT is usually emitted by the terminal and sent to the process group. SIGHUP usually happens to a process group if termination of a process causes that process group to become orphaned. Before this patch, chg will only forward these signals to the single server process. This patch changes it to the server process group. This will allow us to properly kill processes started by the forked server process, like a ssh process. The behavior difference can be observed by setting SSH_ASKPASS to a dummy script doing "sleep 100" and then run "chg push ssh://dest-need-password-auth". Before this patch, the first Ctrl+C will kill the hg process while ssh-askpass and ssh will remain alive. This patch will make sure they are killed properly.
-
- Jul 19, 2016
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Jul 18, 2016
-
-
Mads Kiilerich authored
It was in some cases possible to end up writing to the cache file without growing it first. The range assignment in _setcachedata would append instead of writing at the requested position and thus write the new record in the wrong place. To fix this, we avoid looking up in too small caches, and when growing the cache, do it right before writing the new record to it so we know it has been done correctly.
-
Mads Kiilerich authored
-
Jun Wu authored
We recently discovered a case in production that chg uses 100% CPU and is trying to read data forever: recvfrom(4, "", 1814012019, 0, NULL, NULL) = 0 Using gdb, apparently readchannel() got wrong data. It was reading in an infinite loop because rsize == 0 does not exit the loop, while the server process had ended. (gdb) bt #0 ... in recv () at /lib64/libc.so.6 #1 ... in readchannel (...) at /usr/include/bits/socket2.h:45 #2 ... in readchannel (hgc=...) at hgclient.c:129 #3 ... in handleresponse (hgc=...) at hgclient.c:255 #4 ... in hgc_runcommand (hgc=..., args=<optimized>, argsize=<optimized>) #5 ... in main (argc=...486922636, argv=..., envp=...) at chg.c:661 (gdb) frame 2 (gdb) p *hgc $1 = {sockfd = 4, pid = 381152, ctx = {ch = 108 'l', data = 0x7fb05164f010 "st):\nTraceback (most recent call last):\n" "Traceback (most recent call last):\ne", maxdatasize = 1814065152," " datasize = 1814064225}, capflags = 16131} This patch addresses the infinite loop issue by detecting continuously empty responses and abort in that case. Note that datasize can be translated to ['l', ' ', 'l', 'a']. Concatenate datasize and data, it forms part of "Traceback (most recent call last):". This may indicate a server-side channeledoutput issue. If it is a race condition, we may want to use flock to protect the channels.
-
Gregory Szorc authored
The Python ssl module conditionally sets the TLS 1.1 and TLS 1.2 constants depending on whether HAVE_TLSv1_2 is defined. Yes, these are both tied to the same constant (I would think there would be separate constants for each version). Perhaps support for TLS 1.1 and 1.2 were added at the same time and the assumption is that OpenSSL either has neither or both. I don't know. As part of developing this patch, it was discovered that Apple's /usr/bin/python2.7 does not support TLS 1.1 and 1.2 (only TLS 1.0)! On OS X 10.11, Apple Python has the modern ssl module including SSLContext, but it doesn't appear to negotiate TLS 1.1+ nor does it expose the constants related to TLS 1.1+. Since this code is doing more robust feature detection (and not assuming modern ssl implies TLS 1.1+ support), we now get TLS 1.0 warnings when running on Apple Python. Hence the test changes. I'm not super thrilled about shipping a Mercurial that always whines about TLS 1.0 on OS X. We may want a follow-up patch to suppress this warning.
-
- Jul 11, 2016
-
-
Maciej Fijalkowski authored
-
- Jun 05, 2016
-
-
Yuya Nishihara authored
It's been broken since cca59ef27e60, which made ui argument mandatory. I've tried several combinations of HTTP/HTTPS proxying on old/new Python versions, but I couldn't figure out how to reach this code path. Also, wrapping HTTP connection by SSLSocket seems wrong. My understanding is that self.realhostport is set by _generic_start_transaction() if HTTPS connection is tunneled. This patch removes proxy tunneling from httpconnection.connect() assuming that it was dead code from the beginning. Note that HTTPS over tunneling should be handled by httpsconnection class.
-
- May 21, 2016
-
-
Yuya Nishihara authored
self.address has been reanmed to self._realaddress to clarify that it can be different from the address argument.
-
- May 22, 2016
-
-
Yuya Nishihara authored
Instead of overwriting self.address, calculate it from the address argument, which is the base address.
-
Yuya Nishihara authored
This should make it slightly easier to follow the call path.
-
- May 21, 2016
-
-
Yuya Nishihara authored
commandserver.log() is noop at this time because no client connection is established.
-
- Jun 05, 2016
-
-
Yuya Nishihara authored
It was introduced by b76d8c641746, which is no longer necessary thanks to recent refactoring of sslutil including ef316c653b7f.
-
- Jul 17, 2016
-
-
Gregory Szorc authored
The bundle2 changegroup part has an advisory param saying how many changesets are in the part. Before this patch, we were setting this part when generating bundle2 parts via the wire protocol but not when generating local bundle2 files. A side effect of not setting the changeset count part is that progress bars don't work when applying changesets. As the tests show, this impacted clone bundles, shelve, backup bundles, `hg unbundle`, and anything touching bundle2 files. This patch adds a backdoor to allow us to pass state from changegroup generation into the unbundler. We store the number of changesets in the changegroup in this state and use it to populate the aforementioned advisory part parameter when generating the bundle2 bundle. I concede that I'm not thrilled by how state is being passed in changegroup.py (it feels a bit hacky). I would love to overhaul the rather confusing set of functions in changegroup.py with something that passes rich objects around instead of e.g. low-level generators. However, given the code freeze for 3.9 is imminent, I'd rather not undertake this endeavor right now. This feels like the easiest way to get the parameter added to the changegroup part.
-