- Mar 18, 2025
-
-
Raphaël Gomès authored
818598f5bc8b is the change that introduced the vulnerability (in 2006!) that was disclosed to us, but I found a similar pattern in other places in the code. Since XSS escaping is actually hard and that would mean vendoring some better sanitation tool, I decided to simply remove user input from any HTML output in hgweb, hopefully in all places.
- Mar 05, 2025
-
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
Pierre-Yves David authored
When the manifest bundle constain some known requirement that does not affect the stream clone, we used to crash. However since we know them and know they don't affect the stream clone, we can ignore them. Mozilla generated such buggy manifest bundle for a time which allowed us to catch this error. The issue was not caught until 961900fbd67c (released in 6.9.2) as the requirements information were ignored for stream-v2 until then. We fix the issue, refactor the code for robustness and adds more tests to better catch this kind of issue in the future.
-
- Feb 26, 2025
-
-
Matt Harbison authored
The SourceForge packages were working as recently as late last week, and then yesterday I suddenly got a failure that the size of the download changed from what was expected. Let's not trust SourceForge for critical things (though the MinGW package manager likely uses that too; I'm not sure how to fix that). We probably don't need this at all, now that `install-windows-dependencies.ps1` installs `gettext` 0.22.5 since da74e81ef9af. But I don't feel like tinkering with the packaging code at this point, and running that PowerShell script in CI is probably pretty heavy handed.
-
- Feb 19, 2025
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
- Feb 06, 2025
-
-
Arseniy Alekseyev authored
This one is much less likely to be problematic in practice since the data we're writing is constant-size, but it's not enough to completely rule out the problem.
-
- Feb 05, 2025
-
-
Arseniy Alekseyev authored
This commit makes the `sshpeer.doublepipe` object retry on short write, which fixes a deadlock in hg client-server communication, in particular when client needs to send a large message. Apparently Mercurial relies on `write` method on file objects to never return short writes, without checking, which leads to deadlocks. This work fine when the underlying file object is buffered, since buffered writers never return short writes. (why buffering has anything to do with this I don't know, but ok) It breaks horribly with raw IO, which happens to be used in sshpeer.
-
- Feb 18, 2025
-
-
Pierre-Yves David authored
The code was calling `_set_identity` in too many places, resulting in fetching cache information after reading the on disk data. This could result in old data labelled with the identity of new, never loaded data. Fixing it solve the issue spotted in the previous changesets. Further cleanup are warranted but it seems more reasonable to do them on stable.
-
Pierre-Yves David authored
This was giving the wrong output in the `dirstate-v2-rewrite` case. As the dirstate is rewritten, the data file is missing and we reload the full dirstate. The make the dirstate reloaded after the commit and it no longer see the file as dirty. Note that if we were deleting the data file less aggressively, we would see the other output. (for example if we were keeping old data file around for some time before deletion). One last thing… fixing this reveal a quite serious bug where a `hg status` end up overwriting a `hg update` done concurrently. Hooray for proper testing.
-
Pierre-Yves David authored
`#if dirstate-v2` is always false, because `dirstate-v2` is not one of the test cases. So we fix the conditionnal and adjust the expected matching. This highlight that the rhg/no-rhg output differ because an issue in the code. We will fix that in the next changeset.
-
Pierre-Yves David authored
We are going to fix a bug in the test framework, that will reveal a fairly serious bug with the Rust code. So we update the test before hand for clarity.
-
Julien Cristau authored
stream bundle specs specify requirements, but we were ignoring this when selecting which bundle to apply, causing spurious clone failures.
-
- Feb 12, 2025
-
-
Matt Harbison authored
I guess pytype 2023.11.21 goes out to lunch on this module- 2024.10.11 found this, and PyCharm sees the problem too. This broke back in a43d256c041a when the internal attr was made a property.
-
- Feb 08, 2025
-
-
Matt Harbison authored
This backs out 7b837fabc990 and eda075d7b2ac. The cleanup to transition away from bytes broke JavaHg, which is used by hosting software SCM Manager. I'm not sure who maintains JavaHg these days, so I'm not sure how to get a build out and get everyone to upgrade. Let's revert the change for a quicker fix (and fix an unknown number of other unmaintained extensions), and rely on pytype to flag any potential issues. It's also trivial, so let's not wait until the next feature release (with the added burden for packagers this cycle in dealing with the `setup.py` changes).
-
- Jan 29, 2025
-
-
Arseniy Alekseyev authored
Apparently we "return" instead of doing "continue", which seems clearly unintentional. I split the function in two to make this particular bug impossible.
-
- Jan 28, 2025
-
-
Arseniy Alekseyev authored
Do the same whitespace-at-the-edge validation in rhg that we do in Python.
-
- Jan 10, 2025
-
-
Arseniy Alekseyev authored
While we're at it, forbid empty path components (aka repeated slashes) as well because they can cause problems (at the very least a crash failing HgPath validation in rust code path).
-
Arseniy Alekseyev authored
Forbid whitespace at the edges of the pattern because it just doesn't work correctly.
-
- Jan 16, 2025
-
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
- Jan 14, 2025
-
-
Mitchell Kember authored
This makes hg-core use ResourceProfileValue::Medium as the default. Before, it used ResourceProfileValue::Default (now removed), which was not supposed to be a real value, but rather an indirection meaning to use the default (medium). The motivation for this is that my implementation of rhg annotate was slower on some files than Python. This was because Python used the "Medium" profile by default (enabling the revlog chunk cache), while Rust used the "Default" profile (disabling the revlog chunk cache).
-
Mitchell Kember authored
This makes hg-core read resource profile configs from usage.resources. Before, it correctly used that for sub-values such as usage.resources.memory, but for the generic value it incorrectly used usage.resource (singular).
-
Mitchell Kember authored
This makes get_resource_profile less confusing. Before, RESOURCE_DEFAULT was a special indirect value which meant to use DEFAULT_RESOURCE. I removed it while preserving the same behavior. The motivation for this is that the Rust implementation gets the default logic wrong due to confusion about defaults. I will fix it in a follow-up commit.
-
- Jan 15, 2025
-
-
Pierre-Yves David authored
So that we can build official package from the CI.
-
- Jan 02, 2025
-
-
Matt Harbison authored
COPYING.rtf has a few additional changes (like the website URL), because it's been unmaintained for awhile now.
-
- Dec 18, 2024
-
-
Pierre Augier authored
The use of `--no-use-pep517` leads to ERROR: Disabling PEP 517 processing is invalid: project specifies a build backend of setuptools.build_meta in pyproject.toml
-
- Dec 13, 2024
-
-
Pierre-Yves David authored
The point of these nightly build is to catch error on case we do not systematically test. So we better test them.
-
Pierre-Yves David authored
Otherwise the scheduled build are useless.
-
- Dec 05, 2024
-
-
Taylor R Campbell authored
Text that is meant to represent zero-width output in a readline prompt, such as terminal escape sequences, is supposed to be delimited by \001 ... \002: > Applications may indicate that the prompt contains characters that > take up no physical screen space when displayed by bracketing a > sequence of such characters with the special markers > RL_PROMPT_START_IGNORE and RL_PROMPT_END_IGNORE (declared in > readline.h `\001' and `\002', respectively). This may be used to > embed terminal-specific escape sequences in prompts. https://tiswww.cwru.edu/php/chet/readline/readline.html#index-rl_005fexpand_005fprompt When formatting a readline prompt in ui._readline, arrange to do this in the color.py labelling routines. Keeping mutable dynamically scoped state like this isn't great but threading it as a parameter through all the subroutines seems like much more trouble. (This doesn't address the missing line break -- that's a separate bug in libedit.) https://bz.mercurial-scm.org/show_bug.cgi?id=6930
-
Taylor R Campbell authored
Add missing line break so the heading is treated as such, not as paragraph text. https://bz.mercurial-scm.org/show_bug.cgi?id=6942
-
- Dec 06, 2024
-
-
Matt Harbison authored
A recent series got landed with a pytype failure, because it wasn't propagated to the CI caller (see c47fe7fd312d). I suspect it started recently with 069735062524, because failures have been flagged in the past. The shebang line needs to be specific to bash, otherwise it ignores this non-POSIX extension. I'm not aware of a POSIX flavor of this option.
-
- Nov 25, 2024
-
-
Matt Harbison authored
Since Python 2.7 and 3.5, `typing.ByteString` was defined as an alias for `bytes | bytearray | memoryview`, and `bytes` was also accepted as a shorthand for this, so we have `bytes` sprinkled all over the codebase. But then PEP-688 reversed all of that by deprecating `typing.ByteString` and its successor `collections.abc.ByteString` in Python 3.12 (as well as the `bytes` shorthand)[1], and removing it completely in Python 3.14. That leaves us with a couple of problems, namely defining something useful that spans py3.8-py3.13 and keeps pytype happy, and finding all of the instances where `bytes` doesn't really mean `bytes`. The current successor to all of this is `collections.abc.Buffer` in Python 3.12 (or `typing_extensions.Buffer` in previous versions). However, the current CI does type checking using Python 3.11 (so the former is not avaiable), and pytype has issues with importing `typing_extensions.Buffer`[2]. The good news is we don't need to deal with this mess immediately, since the type annotation evaluation is delayed to the type checking phase, and we're making no effort at supporting it in all supported versions of Python. So by delaying the import of this particular symbol, we can still use it for type checking purposes, but can start assessing Python 3.14 problems without doing a lot of extra work. Putting this on stable will allow people interested in 3.14 to work on it 4-5 extra months earlier (and apparently there's some interest). [1] https://peps.python.org/pep-0688/#no-special-meaning-for-bytes [2] https://github.com/google/pytype/issues/1772
-
- Nov 27, 2024
-
-
Matt Harbison authored
It seems like this command doesn't currently cause the wheels to be cached, but since I already had to prevent `pip` from caching when building wheels in 1a09563a615c, and also disable it in a test in 30b5dc517ec2, let's just be explicit that we don't want caching, in case the default behavior changes.
-
Matt Harbison authored
After 1a09563a615c, there's one more wheel that gets cached in the user's pip cache in the macOS CI runner. The wheel corresponds to the version being used for the tests, but it doesn't get cached until the 3rd or 4th test shard is run, so it's not an issue with installing to run the tests. This seems to eliminate that. This doesn't seem to be an issue on Windows or Linux in my setup. Windows not being affected is likely because we set `$USERPROFILE` to redirect the home directory to `$TESTTMP` when running tests, since 08fd76a553c9. (When checking with `"$PYTHON" -m pip cache dir`, it points to `$TESTTMP/pip/cache`.) We do also set `$HOME` to this same location when running posix tests, but I can't tell what's going on locally in Linux, because running `pip` directly in the *.t explodes, and `"$PYTHON" -m pip --version` prints `pip 9.0.1 from /usr/lib/python3/dist-packages`, so that's likely before caching was enabled[1]. Running `python3.8 -m pip --version` locally outside of the *.t (the same version used to invoke the test runner), prints `pip 24.2 from /home/mharbison/.local/lib/python3.8/site-packages/pip (python 3.8)`. In CI, both macOS and Linux print a modern version of `pip`, and list the cache as being under `$TESTTMP`, but then it doesn't end up there on macOS. No idea if it is a pip bug, or what. But let's be explict and disable caching. [1] https://github.com/pypa/pip/blob/fe0925b3c00bf8956a0d33408df692ac364217d4/docs/html/topics/caching.md?plain=1#L37
-
Matt Harbison authored
I had a pile of these one-shot wheels cached on the mac, taking about 1.2G of space from the few weeks we've been building wheels to test, and with the few times the macOS tests were actually run. There's not much point in caching these, since the tests run from a wheel file the tests are force fed. There is still an issue with one wheel from the tests being cached (probably on install), but that's 1/6 of the original problem. I'm putting this in the `pyproject.toml` because I think that's where we should have all of the `cibuildwheel` config collected. There's a concurrent effort to modernize `setup.py` and use this file more, so I'll hold off on pushing most of the config in here for now. But this applies the setting to all OSes, as well as when run through either CI or the individual buid scripts, so I think this is clearly the right way to go. Note that the docs for `cibuildwheel` talks about the intention to move from `pip` to `build` some day. This config only covers the former, so the other config example[1] with the latter may be needed at some point. But I don't see an obvious option for that tool, so we'll cross that bridge when we come to it. [1] https://cibuildwheel.pypa.io/en/v2.22.0/options/#examples_6
-