git: show warning when removing existing unused Kallithea hook These hooks are no longer used and should be removed, but it is nice to have explicit logging when it happens.

auth: tweak log statements when redirecting unauthenticated users to login Warning level was too verbose.

files: fix raw download of repo files with names with unicode points above 256 in name Raw download had apparently only been tested with non-ascii characters that were latin1. That was apparently a (too) simple case that worked without crashing. Files with unicode code points above 256 in their name would fail to download, when Waitress failed like this, trying to get a real byte string by encoding WSGI headers to latin1: UnicodeEncodeError: 'latin-1' codec can't encode characters in position 84-85: ordinal not in range(256) HTTP headers are of course byte strings on the network, but Python3 WSGI does unfortunately neither expose it as bytes nor as unicode strings to be encoded as utf-8. Instead, it uses unicode strings with byte values encoded as code points 0-255. That is achieved by decoding the utf-8 encoded bytes as latin1. For raw downloads, the recommended download filename is provided in the Content-Disposition header. The problem is that it was provided as a real unicode string. Fixed by applying the "proper" latin1-decoding of a utf8-encoding.

Kick off next development cycle (0.7.99)

merge stable

Added tag 0.7.0 for changeset 7324ff1929d5

release 0.7.0

MANIFEST.in: add missing pytype_requirements.txt added in commit 278cc5936ed5

release: merge default to stable for 0.7.0

contributors: update

i18n: updated translation for French Currently translated at 99.8% (1079 of 1081 strings)

i18n: update normalized translations Refactorings moved things around.

i18n: fix duplicate entries after fixing odd space before ? in "Don't have an account ?" Dropping the odd spaces in 462064bd9489 gave some duplicate translation strings ... but there are no actual conflicting translations, so it can be resolved "trivially".

ini: set translate_forwarded_server = False when using paste prefix middleware Paste Deploy PrefixMiddleware will be default trust HTTP headers that a proxy server might have set. That can be a problem if there is no proxy server or if the proxy just pass these headers through. Change the configuration example to disable this translation.

git: fix whitespace in previous commit scripts/whitespacecleanup.sh will remove tabs introduced in f0fbb0fe4462 ... but that is fine; it was just an example.

git: update check for invalid URL characters to work with Python versions that include an attempt at fixing the very same problem With changes like https://github.com/python/cpython/commit/76cd81d60310d65d01f9d7b48a8985d8ab89c8b4 making it to Python 3.10 and being backported to previous Python versions, the approach in a8a51a3bdb61 no longer works when combined with urllib.parse.urlparse in d2f59de17bef: path will never contain the invalid characters. To catch this case anyway, add a new check to verify that the parsed URL can roundtrip back to the original representation with urllib.parse.urlunparse . The actual exception might vary, but one of them should always fire. There is a risk that the new check will reject some URLs that somehow isn't normalized. No such cases have been found yet.

auth: only use X- headers instead of wsgi.url_scheme if explicitly told so in url_scheme_header - drop https_fixup setting Before, several X- headers would be trusted to overrule the actual connection protocol (http or https) seen by the Kallithea WSGI server. That was mainly when https_fixup were set, but it incorrectly also kicked in if https_fixup or use_htsts were configured. The ambiguity of which headers were used also made it less reliable. The proxy server not only had to be configured to set one of the headers correctly, it also had to make sure other headers were not passed on from the client. It would thus in some cases be possible for clients to fake the connection scheme, and thus potentially be possible to bypass restrictions configured in Kallithea. Fixed by making it configurable which WSGI environment variable to use for the protocol. Users can configure url_scheme_header to for example HTTP_X_FORWARDED_PROTO instead of using the default wsgi.url_scheme . This change is a bit similar to what is going on in the https_fixup middleware, but is doing a bit more of what for example is happening in similar code in werkzeug/middleware/proxy_fix.py . The semantics of the old https_fixup were unsafe, so it has been dropped. Admins that are upgrading must change their configuration to use the new url_scheme_header option.

auth: only use X- headers instead of REMOTE_ADDR if explicitly told so in remote_addr_header Before, X-Forwarded-For (and others) headers would *always* be trusted blindly, also in setups without a proxy server. It would thus in some cases be possible for users to fake their IP, and thus potentially be possible to bypass IP restrictions configured in Kallithea. Fixed by making it configurable which WSGI environment variable to use for the remote address. Users can configure remote_addr_header to for example HTTP_X_FORWARDED_FOR instead of using the default REMOTE_ADDR. This change is a bit similar to what is going on in the https_fixup middleware, but is doing a bit more of what for example is happening in similar code in werkzeug/middleware/proxy_fix.py .

auth: don't trust clients too much - only trust the *last* IP in the X-Forwarded-For header The X-Forwarded-For header contains a list of IP addresses, where each proxy server appends the IP they see their request coming from. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For . Trusting the *first* IP in HTTP_X_FORWARDED_FOR would allow clients to claim any IP, which could be used to bypass IP restrictions configured in Kallithea. Instead, only trust the last proxy in the chain, and thus only use the *last* IP in HTTP_X_FORWARDED_FOR. (In setups where more than last IP should be trusted, the last proxy server in the chain must be configured rewrite the header accordingly.)

docs: document how proxy servers must be configured