git/wrapper.c, branch v2.50.0

Merge branch 'cf/wrapper-bsd-eloop'

2025-05-16T00:24:55Z

The fallback implementation of open_nofollow() depended on open("symlink", O_NOFOLLOW) to set errno to ELOOP, but a few BSD derived systems use different errno, which has been worked around. * cf/wrapper-bsd-eloop: wrapper: NetBSD gives EFTYPE and FreeBSD gives EMFILE where POSIX uses ELOOP

wrapper: NetBSD gives EFTYPE and FreeBSD gives EMFILE where POSIX uses ELOOP

2025-05-06T16:43:22Z

As documented on NetBSD's man page, open with the O_NOFOLLOW flag and a symlink returns -1 and sets errno to EFTYPE which differs from POSIX. This patch fixes the following test failure: $ sh t0602-reffiles-fsck.sh --verbose --- expect 2025-05-02 23:05:23.920890147 +0000 +++ err 2025-05-02 23:05:23.916794959 +0000 @@ -1 +1 @@ -error: packed-refs: badRefFiletype: not a regular file but a symlink +error: unable to open '.git/packed-refs': Inappropriate file type or format not ok 12 - the filetype of packed-refs should be checked FreeBSD has the same issue for EMLINK instead of EFTYPE. This portability issue was introduced in cfea2f2da8 (packed-backend: check whether the "packed-refs" is regular file, 2025-02-28) Signed-off-by: Collin Funk Acked-by: brian m. carlson Acked-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

object-file: move `xmmap()` into "wrapper.c"

2025-04-15T15:24:35Z

The `xmmap()` function is provided by "object-file.c" even though its functionality has nothing to do with the object file subsystem. Move it into "wrapper.c", whose header already declares those functions. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

wrapper: allow generating insecure random bytes

2025-01-07T17:04:18Z

The `csprng_bytes()` function generates randomness and writes it into a caller-provided buffer. It abstracts over a couple of implementations, where the exact one that is used depends on the platform. These implementations have different guarantees: while some guarantee to never fail (arc4random(3)), others may fail. There are two significant failures to distinguish from one another: - Systemic failure, where e.g. opening "/dev/urandom" fails or when OpenSSL doesn't have a provider configured. - Entropy failure, where the entropy pool is exhausted, and thus the function cannot guarantee strong cryptographic randomness. While we cannot do anything about the former, the latter failure can be acceptable in some situations where we don't care whether or not the randomness can be predicted. Introduce a new `CSPRNG_BYTES_INSECURE` flag that allows callers to opt into weak cryptographic randomness. The exact behaviour of the flag depends on the underlying implementation: - `arc4random_buf()` never returns an error, so it doesn't change. - `getrandom()` pulls from "/dev/urandom" by default, which never blocks on modern systems even when the entropy pool is empty. - `getentropy()` seems to block when there is not enough randomness available, and there is no way of changing that behaviour. - `GtlGenRandom()` doesn't mention anything about its specific failure mode. - The fallback reads from "/dev/urandom", which also returns bytes in case the entropy pool is drained in modern Linux systems. That only leaves OpenSSL with `RAND_bytes()`, which returns an error in case the returned data wouldn't be cryptographically safe. This function is replaced with a call to `RAND_pseudo_bytes()`, which can indicate whether or not the returned data is cryptographically secure via its return value. If it is insecure, and if the `CSPRNG_BYTES_INSECURE` flag is set, then we ignore the insecurity and return the data regardless. It is somewhat questionable whether we really need the flag in the first place, or whether we wouldn't just ignore the potentially-insecure data. But the risk of doing that is that we might have or grow callsites that aren't aware of the potential insecureness of the data in places where it really matters. So using a flag to opt-in to that behaviour feels like the more secure choice. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

global: mark code units that generate warnings with `-Wsign-compare`

2024-12-06T11:20:02Z

Mark code units that generate warnings with `-Wsign-compare`. This allows for a structured approach to get rid of all such warnings over time in a way that can be easily measured. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

don't report vsnprintf(3) error as bug

2024-04-21T19:27:07Z

strbuf_addf() has been reporting a negative return value of vsnprintf(3) as a bug since f141bd804d (Handle broken vsnprintf implementations in strbuf, 2007-11-13). Other functions copied that behavior: 7b03c89ebd (add xsnprintf helper function, 2015-09-24) 5ef264dbdb (strbuf.c: add `strbuf_insertf()` and `strbuf_vinsertf()`, 2019-02-25) 8d25663d70 (mem-pool: add mem_pool_strfmt(), 2024-02-25) However, vsnprintf(3) can legitimately return a negative value if the formatted output would be longer than INT_MAX. Stop accusing it of being broken and just report the fact that formatting failed. Suggested-by: Jeff King Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano

treewide: remove unnecessary includes in source files

2023-12-26T20:04:31Z

Each of these were checked with gcc -E -I. ${SOURCE_FILE} | grep ${HEADER_FILE} to ensure that removing the direct inclusion of the header actually resulted in that header no longer being included at all (i.e. that no other header pulled it in transitively). ...except for a few cases where we verified that although the header was brought in transitively, nothing from it was directly used in that source file. These cases were: * builtin/credential-cache.c * builtin/pull.c * builtin/send-pack.c Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

parse: separate out parsing functions from config.h

2023-09-29T22:14:57Z

The files config.{h,c} contain functions that have to do with parsing, but not config. In order to further reduce all-in-one headers, separate out functions in config.c that do not operate on config into its own file, parse.h, and update the include directives in the .c files that need only such functions accordingly. Signed-off-by: Calvin Wan Signed-off-by: Jonathan Tan Signed-off-by: Junio C Hamano

wrapper: reduce scope of remove_or_warn()

2023-09-29T22:14:56Z

remove_or_warn() is only used by entry.c and apply.c, but it is currently declared and defined in wrapper.{h,c}, so it has a scope much greater than it needs. This needlessly large scope also causes wrapper.c to need to include object.h, when this file is largely unconcerned with Git objects. Move remove_or_warn() to entry.{h,c}. The file apply.c still has access to it, since it already includes entry.h for another reason. Signed-off-by: Calvin Wan Signed-off-by: Jonathan Tan Signed-off-by: Junio C Hamano

maintenance: add get_random_minute()

2023-08-10T21:04:16Z

When we initially created background maintenance -- with its hourly, daily, and weekly schedules -- we considered the effects of all clients launching fetches to the server every hour on the hour. The worry of DDoSing server hosts was noted, but left as something we would consider for a future update. As background maintenance has gained more adoption over the past three years, our worries about DDoSing the big Git hosts has been unfounded. Those systems, especially those serving public repositories, are already resilient to thundering herds of much smaller scale. However, sometimes organizations spin up specific custom server infrastructure either in addition to or on top of their Git host. Some of these technologies are built for a different range of scale, and can hit concurrency limits sooner. Organizations with such custom infrastructures are more likely to recommend tools like `scalar` which furthers their adoption of background maintenance. To help solve for this, create get_random_minute() as a method to help Git select a random minute when creating schedules in the future. The integrations with this method do not yet exist, but will follow in future changes. To avoid multiple sources of randomness in the Git codebase, create a new helper function, git_rand(), that returns a random uint32_t. This is similar to how rand() returns a random nonnegative value, except it is based on csprng_bytes() which is cryptographic and will return values larger than RAND_MAX. One thing that is important for testability is that we notice when we are under a test scenario and return a predictable result. The schedules themselves are not checked for this value, but at least one launchctl test checks that we do not unnecessarily reboot the schedule if it has not changed from a previous version. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano