git/http.c, branch v2.46.2

Merge branch 'jc/http-cookiefile'

2024-07-17T17:47:26Z

The http.cookieFile and http.saveCookies configuration variables have a few values that need to be avoided, which are now ignored with warning messages. * jc/http-cookiefile: http.c: cookie file tightening

Merge branch 'bc/http-proactive-auth'

2024-07-16T18:18:57Z

The http transport can now be told to send request with authentication material without first getting a 401 response. * bc/http-proactive-auth: http: allow authenticating proactively

http.c: cookie file tightening

2024-07-10T04:28:38Z

The http.cookiefile configuration variable is used to call curl_easy_setopt() to set CURLOPT_COOKIEFILE and if http.savecookies is set, the same value is used for CURLOPT_COOKIEJAR. The former is used only to read cookies at startup, the latter is used to write cookies at the end. The manual pages https://curl.se/libcurl/c/CURLOPT_COOKIEFILE.html and https://curl.se/libcurl/c/CURLOPT_COOKIEJAR.html talk about two interesting special values. * "" (an empty string) given to CURLOPT_COOKIEFILE means not to read cookies from any file upon startup. * It is not specified what "" (an empty string) given to CURLOPT_COOKIEJAR does; presumably open a file whose name is an empty string and write cookies to it? In any case, that is not what we want to see happen, ever. * "-" (a dash) given to CURLOPT_COOKIEFILE makes cURL read cookies from the standard input, and given to CURLOPT_COOKIEJAR makes cURL write cookies to the standard output. Neither of which we want ever to happen. So, let's make sure we avoid these nonsense cases. Specifically, when http.cookies is set to "-", ignore it with a warning, and when it is set to "" and http.savecookies is set, ignore http.savecookies with a warning. Signed-off-by: Junio C Hamano

http: allow authenticating proactively

2024-07-10T04:27:51Z

When making a request over HTTP(S), Git only sends authentication if it receives a 401 response. Thus, if a repository is open to the public for reading, Git will typically never ask for authentication for fetches and clones. However, there may be times when a user would like to authenticate nevertheless. For example, a forge may give higher rate limits to users who authenticate because they are easier to contact in case of excessive use. Or it may be useful for a known heavy user, such as an internal service, to proactively authenticate so its use can be monitored and, if necessary, throttled. Let's make this possible with a new option, "http.proactiveAuth". This option specifies a type of authentication which can be used to authenticate against the host in question. This is necessary because we lack the WWW-Authenticate header to provide us details; similarly, we cannot accept certain types of authentication because we require information from the server, such as a nonce or challenge, to successfully authenticate. If we're in auto mode and we got a username and password, set the authentication scheme to Basic. libcurl will not send authentication proactively unless there's a single choice of allowed authentication, and we know in this case we didn't get an authtype entry telling us what scheme to use, or we would have taken a different codepath and written the header ourselves. In any event, of the other schemes that libcurl supports, Digest and NTLM require a nonce or challenge, which means that they cannot work with proactive auth, and GSSAPI does not use a username and password at all, so Basic is the only logical choice among the built-in options. Note that the existing http_proactive_auth variable signifies proactive auth if there are already credentials, which is different from the functionality we're adding, which always seeks credentials even if none are provided. Nonetheless, t5540 tests the existing behavior for WebDAV-based pushes to an open repository without credentials, so we preserve it. While at first this may seem an insecure and bizarre decision, it may be that authentication is done with TLS certificates, in which case it might actually provide a quite high level of security. Expand the variable to use an enum to handle the additional cases and a helper function to distinguish our new cases from the old ones. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'ps/use-the-repository'

2024-07-02T16:59:00Z

A CPP macro USE_THE_REPOSITORY_VARIABLE is introduced to help transition the codebase to rely less on the availability of the singleton the_repository instance. * ps/use-the-repository: hex: guard declarations with `USE_THE_REPOSITORY_VARIABLE` t/helper: remove dependency on `the_repository` in "proc-receive" t/helper: fix segfault in "oid-array" command without repository t/helper: use correct object hash in partial-clone helper compat/fsmonitor: fix socket path in networked SHA256 repos replace-object: use hash algorithm from passed-in repository protocol-caps: use hash algorithm from passed-in repository oidset: pass hash algorithm when parsing file http-fetch: don't crash when parsing packfile without a repo hash-ll: merge with "hash.h" refs: avoid include cycle with "repository.h" global: introduce `USE_THE_REPOSITORY_VARIABLE` macro hash: require hash algorithm in `empty_tree_oid_hex()` hash: require hash algorithm in `is_empty_{blob,tree}_oid()` hash: make `is_null_oid()` independent of `the_repository` hash: convert `oidcmp()` and `oideq()` to compare whole hash global: ensure that object IDs are always padded hash: require hash algorithm in `oidread()` and `oidclr()` hash: require hash algorithm in `hasheq()`, `hashcmp()` and `hashclr()` hash: drop (mostly) unused `is_empty_{blob,tree}_sha1()` functions

global: introduce `USE_THE_REPOSITORY_VARIABLE` macro

2024-06-14T17:26:33Z

Use of the `the_repository` variable is deprecated nowadays, and we slowly but steadily convert the codebase to not use it anymore. Instead, callers should be passing down the repository to work on via parameters. It is hard though to prove that a given code unit does not use this variable anymore. The most trivial case, merely demonstrating that there is no direct use of `the_repository`, is already a bit of a pain during code reviews as the reviewer needs to manually verify claims made by the patch author. The bigger problem though is that we have many interfaces that implicitly rely on `the_repository`. Introduce a new `USE_THE_REPOSITORY_VARIABLE` macro that allows code units to opt into usage of `the_repository`. The intent of this macro is to demonstrate that a certain code unit does not use this variable anymore, and to keep it from new dependencies on it in future changes, be it explicit or implicit For now, the macro only guards `the_repository` itself as well as `the_hash_algo`. There are many more known interfaces where we have an implicit dependency on `the_repository`, but those are not guarded at the current point in time. Over time though, we should start to add guards as required (or even better, just remove them). Define the macro as required in our code units. As expected, most of our code still relies on the global variable. Nearly all of our builtins rely on the variable as there is no way yet to pass `the_repository` to their entry point. For now, declare the macro in "biultin.h" to keep the required changes at least a little bit more contained. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

http: do not assign string constant to non-const field

2024-06-07T17:30:53Z

In `write_accept_language()`, we put all acceptable languages into an array. While all entries in that array are allocated strings, the final entry in that array is a string constant. This is fine because we explicitly skip over the last entry when freeing the array, but will cause warnings once we enable `-Wwrite-strings`. Adapt the code to also allocate the final entry. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

config: clarify memory ownership in `git_config_string()`

2024-05-27T18:20:00Z

The out parameter of `git_config_string()` is a `const char **` even though we transfer ownership of memory to the caller. This is quite misleading and has led to many memory leaks all over the place. Adapt the parameter to instead be `char **`. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

config: clarify memory ownership in `git_config_pathname()`

2024-05-27T18:19:59Z

The out parameter of `git_config_pathname()` is a `const char **` even though we transfer ownership of memory to the caller. This is quite misleading and has led to many memory leaks all over the place. Adapt the parameter to instead be `char **`. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

http: refactor code to clarify memory ownership

2024-05-27T18:19:58Z

There are various variables assigned via `git_config_string()` and `git_config_pathname()` which are never free'd. This bug is relatable because the out parameter of those functions are a `const char **`, even though memory ownership is transferred to the caller. We're about to adapt the functions to instead use `char **`. Prepare the code accordingly. Note that the `(const char **)` casts will go away once we have adapted the functions. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano