[pull] master from git:master#43
Merged
pull[bot] merged 48 commits intoturkdevops:masterfrom Apr 25, 2025
Merged
Conversation
* ps/object-wo-the-repository: hash: stop depending on `the_repository` in `null_oid()` hash: fix "-Wsign-compare" warnings object-file: split out logic regarding hash algorithms delta-islands: stop depending on `the_repository` object-file-convert: stop depending on `the_repository` pack-bitmap-write: stop depending on `the_repository` pack-revindex: stop depending on `the_repository` pack-check: stop depending on `the_repository` environment: move access to "core.bigFileThreshold" into repo settings pack-write: stop depending on `the_repository` and `the_hash_algo` object: stop depending on `the_repository` csum-file: stop depending on `the_repository`
The `mkdir_in_gitdir()` function is similar to `safe_create_dir()`, but
the former is hosted in "object-file.c" whereas the latter is hosted in
"path.c". The latter code unit makes way more sense though as the logic
has nothing to do with object files in particular.
Move the file into "path.c". While at it, we:
- Rename the function to `safe_create_dir_in_gitdir()` so that the
function names are similar to one another.
- Remove the dependency on `the_repository` by making the callers pass
the repository instead.
Adjust callers accordingly.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The `safe_create_leading_directories()` function and its relatives are located in "object-file.c", which is not a good fit as they provide generic functionality not related to objects at all. Move them into "path.c", which already hosts `safe_create_dir()` and its relative `safe_create_dir_in_gitdir()`. "path.c" is free of `the_repository`, but the moved functions depend on `the_repository` to read the "core.sharedRepository" config. Adapt the function signature to accept a repository as argument to fix the issue and adjust callers accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The `git_open_cloexec()` wrapper function provides the ability to open a file with `O_CLOEXEC` in a platform-agnostic way. This function is provided by "object-file.c" even though it is not specific to the object subsystem at all. Move the file into "compat/open.c". This file already exists before this commit, but has only been compiled conditionally depending on whether or not open(3p) may return EINTR. With this change we now unconditionally compile the object, but wrap `git_open_with_retry()` in an ifdef. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
While we have the "object-store.h" header, most of the functionality for object stores is actually hosted in "object-file.c". This makes it hard to find relevant functions and causes us to mix up concerns. Split out functions relating to the object store subsystem into a new "object-store.c" file. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The functions `hash_object_file()`, `write_object_file()` and `index_fd()` reuse the same set of flags to alter their behaviour. This not only adds confusion, but given that every function only supports a subset of the flags it becomes very hard to see which flags can be passed to what function. Last but not least, this entangles the implementation of all three function families. Split up concerns by creating separate flags for each of the function families. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The `index_blob_stream()` function is a mere wrapper around `index_blob_bulk_checkin()`. This has been the case since 568508e (bulk-checkin: replace fast-import based implementation, 2011-10-28), which has moved the implementation from `index_blob_stream()` (which was still called `index_stream()`) into `index_bulk_checkin()` (which has since been renamed to `index_blob_bulk_checkin()`). Remove the redirection by dropping the wrapper. Move the comment to `index_blob_bulk_checkin()` to retain its context. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Split out functions relating to the object store subsystem from "object.c". This helps us to separate concerns. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cached objects are virtual objects that can be set up without writing anything into the object store directly, which is used by git-blame(1) to create fake commits for the working tree. These cached objects are stored in a global variable, which is another roadblock for libification of the object subsystem. Refactor the code so that we instead store the array as part of the raw object store. This refactoring raises the question whether virtual objects should really be specific to a single repository (or rather a single object store). Hypothetical usecases might for example span across submodules, and here it may or may not be the right thing to provide virtual objects across submodule boundaries. The only existing usecase is git-blame(1) though, which does not know to blame across submodule boundaries in the first place. As such, storing these objects both globally and per-repository would achieve the same result right now. But arguably, if we learned to blame across submodule boundaries, we would likely want to create separate fare working tree commits for each of the submodules so that the user can learn which worktree a specific uncommitted change belongs to. And even if we would want to create the same fake commit for each of the submodules we could do that when storing separate virtual objects per object store. While this is all rather hypothetical, the takeaway is that handling virtual objects per-object store gives us more flexibility compared to storing them globally. In a hypothetical future where we have achieved full libification one might be able to handle unrelated repositories in a single process, where the state of one repository should not have an impact on the state of another repository. As such, storing these cached objects per object store will enable more usecases and should lead to less surprising outcomes overall. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "object-store-ll.h" header has been introduced to keep transitive header dependendcies and compile times at bay. Now that we have created a new "object-store.c" file though we can easily move the last remaining additional bit of "object-store.h", the `odb_path_map`, out of the header. Do so. As the "object-store.h" header is now equivalent to its low-level alternative we drop the latter and inline it into the former. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a user wishes to disable hooks, then they can do so using the established pattern of setting 'core.hooksPath' to /dev/null. This is already tested in t1350-config-hooks-path.sh, but has not previously been visible in the documentation. Update the documentation to include this as an option. Signed-off-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tests use grep to search the output of `git tag` for tagnames they expect to exist, which can incorrectly pass if an unxpected tag has the expected tag as its substring. We fix this by using `git show-ref --verify` instead. Additionally, we add a negative test to verify that a possible uninteded tag does not show up in the imported repository. This change also fixes an additional problem, where piping the output of `git tag` caused the exit codes to be lost. Signed-off-by: Anthony Wang <anthonywang513@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 9371322 ("sparse: suppress some \"using sizeof on a function\" warnings", 2013-10-06) used target-specific variable assignments to add -DCURL_DISABLE_TYPECHECK to SPARSE_FLAGS for each of the files affected by the "typecheck-gcc.h" warnings. (http-push.c, http.c, http-walker.c and remote-curl.c). These warnings are only issued by sparse, and not by gcc, so we do not want to disable the 'type checking' for non-sparse targets. The meson build does not provide any sparse targets, so there is no need to use the CURL_DISABLE_TYPECHECK preprocessor flag with the c compiler. In order to re-enable the curl 'type checking' in the meson build, remove the assignment of -DCURL_DISABLE_TYPECHECK to libgit_c_args. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Several build variables only have any meaning when the RUNTIME_PREFIX
variable has been set. In particular, the following build variables are
otherwise ignored:
HAVE_BSD_KERN_PROC_SYSCTL
PROCFS_EXECUTABLE_PATH
HAVE_NS_GET_EXECUTABLE_PATH
HAVE_ZOS_GET_EXECUTABLE_PATH
HAVE_WPGMPTR
Make setting BASIC_CFLAGS, for each of these variables, conditional on
the RUNTIME_PREFIX being defined.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some preprocessor -Defines have defaults set in the source code when
they have not been provided to the C compiler. In this case, there is
no need to pass them on the command-line, unless the build requires a
non-standard value.
The build variables for DEFAULT_EDITOR and DEFAULT_PAGER have appropriate
defaults ('vi' and 'less') set in the code. Add the preprocessor -Defines
to the 'libgit_c_args' only if the values set with the corresponding
'options' are different to these standard values.
Also, the 'git-var' documentation contains some conditional text which
documents the chosen compiled in value, which would not read well for
the standard values. Similar to the above, only add the corresponding
'-a' attribute arguments to the 'asciidoc_common_options' variable, if
the values set in the 'options' are different to these standard values.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The build variable DEFAULT_HELP_FORMAT has an appropriate default
('man') set in the code, so there is no need to pass the -Define on
the compiler command-line, unless the build requires a non-standard
value.
In addition, on windows the make build overrides the default help
format to 'html', rather than 'man', in the 'config.mak.uname' file.
In order to suppress the -Define on the C compiler command-line, only
add the -Define to the 'libgit_c_args' variable when the requested
value is not the standard 'man'. In order to override the default value
on windows, add a 'platform' value to the 'default_help_format' combo
option and set it as the default choice. When this option is set to
'platform', use the 'host_machine.system()' method call to determine the
appropriate default value for the host system.
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit d19e3a5 ("Makefile: add NEEDS_LIBRT to optionally link with librt", 2016-07-07) introduced the NEEDS_LIBRT build variable to disassociate the HAVE_CLOCK_GETTIME variable with the unconditional linking of the librt library. At one time, the clock_gettime() function was not available as part of the libc library and (on some unix systems) required linking with librt. Commit 52fcec7 ("config.mak.uname: define NEEDS_LIBRT under Linux, for now", 2016-07-10) set the NEEDS_LIBRT variable in the Linux section of the config.mak.uname file, since Debian 7 (wheezy) was one of the few remaining distributions, with glibc 2.13, that required linking with librt for clock_gettime(). Note that from glibc version 2.17, this is no longer necessary. Note that Debian 7.0 was released on May 4th, 2013 and benefited from long term support until May 2018 when it went end-of-life. Since that time, Linux distributions use a more up-to-date library, for example: Distribution version end of support Debian 8 2.19 30th June 2020 RHEL 8 2.28 31st May 2024 * Ubuntu 16.04 2.23 30th Apr 2021 * paid 'Maintenance support' ends 31st May 2029 Since it is no longer required, remove NEEDS_LIBRT from the Makefile and config.mak.uname. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 817151e ("Rename safe_strncpy() to strlcpy().", 2006-06-24) added the NO_STRLCPY make variable to allow the conditional use of the gitstrlcpy() compat function on those platforms which didn't provide the 'standard' strlcpy() function. Recently, in the summer of 2023, the strlcpy() and strlcat() functions were added to the glibc library (v2.38), so some of the more up-to-date Linux distributions no longer need to set NO_STRLCPY. For example, both Ubuntu 24.04 LTS and RHEL 10 beta have glibc v2.39. However, several distributions, which are still within their support window, have an earlier version and must still use the 'compat' version of strlcpy(). If the meson or autoconf build systems are used on newer platforms, then they will be configured to to use strlcpy() from glibc, whereas the make build will always choose the 'compat' function instead. Add a note to the config.mak.uname file, in the Linux section, to prompt make users to override NO_STRLCPY in the config.mak file, if appropriate. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 92f63d2 ("Cygwin 1.7 needs compat/regex", 2013-07-19) set the NO_REGEX build variable because the platform regex library failed some of the tests (t4018 and t4034), which passed just fine with the compat library. After some time (maybe a year or two), the platform library had been updated (with an import from FreeBSD, I believe) and now passed the full test-suite. This would be about the time of the v1.7 -> v2.0 transition in 2015. I had a patch ready to send, but just didn't get around to submitting it to the list. At some point in the interim, the official cygwin git package used the autoconf build system, which sets the NO_REGEX variable to use the platform regex library functions. The new meson build system does likewise. The cygwin platform regex library, in addition to now passing the tests which formerly failed, now passes an 'test_expect_failure' test in the t7815-grep-binary test file. In particular, test #12 'git grep .fi a' which determines that the regex pattern '.' matches a NUL character. The commit f96e567 ("grep: use REG_STARTEND for all matching if available", 2010-05-22) added the test in question, but it does not give any indication as to why the test was framed as an expected fail, rather than a 'positive' test that the 'git grep' command fails to match a NUL. Note that the previous test #11 was also originally marked in that commit as a 'test_expect_failure', but was flipped to an 'success' test in commit 7e36de5 ("t/t7008-grep-binary.sh: un-TODO a test that needs REG_STARTEND", 2010-08-17). In order to produce the same NO_REGEX configuration from autoconf, meson and make, modify config.mak.uname to only set NO_REGEX for cygwin v1.7. In addition, skip test t7815.12 on cygwin, by adding the !CYGWIN pre- requisite to the test header, which (among other things) removes an '...; please update test(s)' comment. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cygwin has provided the getdelim() function as far back as (at least) 2011. The autoconf and meson builds enable the use of this symbol. In order to have the same configuration for autoconf, meson and make, enable the HAVE_GETDELIM build variable in the cygwin section of the config.mak.uname file. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cygwin supports the clock_gettime() function, along with the associated CLOCK_MONOTONIC preprocessor symbol. The autoconf and meson builds both enable the use of those symbols. In order to have the same configuration for the make builds, add the HAVE_CLOCK_GETTIME and HAVE_CLOCK_MONOTONIC build variables to the cygwin section of the config.mak.uname file. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The man page for sysinfo(2) on Linux states that (from v2.3.48) the sizes of the memory and swap fields, of the returned structure, are given as multiples of 'mem_unit' bytes. In earlier versions (prior to v2.3.23 on i386 in particular), the 'mem_unit' field was not part of the structure, and all sizes were measured in bytes. The man page does not discuss the motivation for this change, but it is possible that the change was intended for the, relatively rare, 32-bit platform with more than 4GB of memory. The total_ram() function makes the assumption that the 'totalram' field of the 'struct sysinfo' is measured in bytes, or alternatively that the 'mem_unit' field is always equal to one. Having writen a program to call the sysinfo() function and print the structure fields, it seems that, on Linux x84_64 and i686 anyway, the 'mem_unit' field is indeed set to one (note that the 32-bit system had only 2GB ram). However, cygwin also has an sysinfo() implementation, which gives the following values: $ ./sysinfo uptime: 21381 loads: 0, 0, 0 total ram: 2074637 free ram: 843237 shared ram: 0 buffer ram: 0 total swap: 327680 free swap: 306932 procs: 15 total high: 0 free high: 0 mem_unit: 4096 total ram: 8497713152 $ [This laptop has 8GB ram, so a little bit seems to be missing. ;) ] Modify the total_ram() function to allow for the possibility that the memory size is not specified in bytes (ie 'mem_unit' is greater than one). Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although sysinfo() is a 'Linux only' function, cygwin provides an implementation which appears to be functional. The assumption that this function is Linux only is reflected in the way the HAVE_SYSINFO build variable is handled by the Makefile and config.mak.uname. Rework the setting of HAVE_SYSINFO in the Linux section of the system specific config file, along with the corresponding setting of the BASIC_CFLAGS in the Makefile. Add the setting of HAVE_SYSINFO to the cygwin section of 'config.mak.uname'. While here, add a test for the sysinfo() function to the autoconf build system. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The arc4random_buf() function has been available in cygwin since about 2016 (somewhere in the v2.x branch). Set the CSPRNG_METHOD build variable to 'arc4random', in the cygwin section, to enable the use of this cryptographically-secure pseudorandom number function. Note that the autoconf and new meson builds also enable this function. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We accept a maximum value in `git_parse_signed()` that restricts the range of accepted integers. As the intent is to pass `INT*_MAX` values here, this maximum doesn't only act as the upper bound, but also as the implicit lower bound of the accepted range. This lower bound is calculated by negating the maximum. But given that the maximum value of a signed integer with N bits is `2^(N-1)-1` whereas the minimum value is `-2^(N-1)` we have an off-by-one error in the lower bound. Fix this off-by-one error by using `-max - 1` as lower bound instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
While we expose macros for most of our different option types understood
by the "parse-options" subsystem, not every combination of fields that
has one as that would otherwise quickly lead to an explosion of macros.
Instead, we just initialize structures manually for those variants of
fields that don't have a macro.
Callsites that open-code these structure initialization don't use
designated initializers though and instead just provide values for each
of the fields that they want to initialize. This has three significant
downsides:
- Callsites need to specify all values up to the last field that they
care about. This often includes fields that should simply be left at
their default zero-initialized state, which adds distraction.
- Any reader not deeply familiar with the layout of the structure
has a hard time figuring out what the respective initializers mean.
- Reordering or introducing new fields in the middle of the structure
is impossible without adapting all callsites.
Convert all sites to instead use designated initializers, which we have
started using in our codebase quite a while ago. This allows us to skip
any default-initialized fields, gives the reader context by specifying
the field names and allows us to reorder or introduce new fields where
we want to.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are two main differences between `OPT_INTEGER()` and
`OPT_MAGNITUDE()`:
- The former parses signed integers whereas the latter parses unsigned
integers.
- The latter parses unit factors like 'k', 'm' or 'g'.
While the first difference makes obvious sense, there isn't really a
good reason why signed integers shouldn't support unit factors, too.
This inconsistency will also become a bit of a problem with subsequent
commits, where we will fix a couple of callsites that pass an unsigned
integer to `OPT_INTEGER()`. There are three options:
- We could adapt those users to instead pass a signed integer, but
this would needlessly extend the range of accepted integer values.
- We could convert them to use `OPT_MAGNITUDE()`, as it only accepts
unsigned integers. But now we have the inconsistency that we also
start to accept unit factors.
- We could introduce `OPT_UNSIGNED()` as equivalent to `OPT_INTEGER()`
so that it knows to only accept unsigned integers without unit
suffix.
Introducing a whole new option type feels a bit excessive. There also
isn't really a good reason why `OPT_INTEGER()` cannot be extended to
also accept unit factors: all valid values passed to such options cannot
have a unit factors right now, so there wouldn't be any ambiguity.
Refactor `OPT_INTEGER()` to use `git_parse_int()`, which knows to
interpret unit factors. This removes the inconsistency between the
signed and unsigned options so that we can easily fix up callsites that
pass the wrong integer type right now.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the preceding commit, `OPT_INTEGER()` has learned to support unit factors. Consequently, the major differencen between `OPT_INTEGER()` and `OPT_MAGNITUDE()` isn't the support of unit factors anymore, as both of them do support them now. Instead, the difference is that one handles signed and the other handles unsigned integers. Adapt the name of `OPT_MAGNITUDE()` accordingly by renaming it to `OPT_UNSIGNED()`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The `OPTION_INTEGER` option type accepts a signed integer. The type of
the underlying integer is a simple `int`, which restricts the range of
values accepted by such options. But there is a catch: because the
caller provides a pointer to the value via the `.value` field, which is
a simple void pointer. This has two consequences:
- There is no check whether the passed value is sufficiently long to
store the entire range of `int`. This can lead to integer wraparound
in the best case and out-of-bounds writes in the worst case.
- Even when a caller knows that they want to store a value larger than
`INT_MAX` they don't have a way to do so.
In practice this doesn't tend to be a huge issue because users typically
don't end up passing huge values to most commands. But the parsing logic
is demonstrably broken, and it is too easy to get the calling convention
wrong.
Improve the situation by introducing a new `precision` field into the
structure. This field gets assigned automatically by `OPT_INTEGER_F()`
and tracks the size of the passed value. Like this it becomes possible
for the caller to pass arbitrarily-sized integers and the underlying
logic knows to handle it correctly by doing range checks. Furthermore,
convert the code to use `strtoimax()` intstead of `strtol()` so that we
can also parse values larger than `LONG_MAX`.
Note that we do not yet assert signedness of the passed variable, which
is another source of bugs. This will be handled in a subsequent commit.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is the equivalent to the preceding commit, but instead of introducing precision handling for `OPTION_INTEGER` we introduce it for `OPTION_UNSIGNED`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was reported that "t5620-backfill.sh" fails on s390x and sparc64 in a test that exercises the "--min-batch-size" command line option. The symptom was that the option didn't seem to have an effect: we didn't fetch objects with a batch size of 20, but instead fetched all objects at once. As it turns out, the root cause is that `--min-batch-size` uses `OPT_INTEGER()` to parse the command line option. While this macro expects the caller to pass a pointer to an integer, we instead pass a pointer to a `size_t`. This coincidentally works on most platforms, but it breaks apart on the mentioned platforms because they are big endian. This issue isn't specific to git-backfill(1): there are a couple of other places where we have the same type confusion going on. This indicates that the issue really is the interface that the parse-options subsystem provides -- it is simply too easy to get this wrong as there isn't any kind of compiler warning, and things just work on the most common systems. Address the systemic issue by introducing two new build asserts `BARF_UNLESS_SIGNED()` and `BARF_UNLESS_UNSIGNED()`. As the names already hint at, those macros will cause a compiler error when passed a value that is not signed or unsigned, respectively. Adapt `OPT_INTEGER()`, `OPT_UNSIGNED()` as well as `OPT_MAGNITUDE()` to use those asserts. This uncovers a small set of sites where we indeed have the same bug as in git-backfill(1). Adapt all of them to use the correct option. Reported-by: Todd Zullinger <tmz@pobox.com> Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 05cd988 ("wrapper: add a helper to generate numbers from a CSPRNG", 2022-01-17) added a csprng_bytes() function which used one of several interfaces to provide a source of cryptographically secure pseudorandom numbers. The CSPRNG_METHOD make variable was provided to determine the choice of available 'backends' for the source of random bytes. Commit 05cd988 did not set CSPRNG_METHOD in the Linux section of the config.mak.uname file, so it defaults to using '/dev/urandom' as the source of random bytes. The 'backend' values which could be used on Linux are 'arc4random', 'getrandom' or 'getentropy' ('openssl' is an option, but seems to be discouraged). The arc4random routines (arc4random_buf() is the one actually used) were added to glibc in version 2.36, while both getrandom() and getentropy() were included in 2.25. So, some of the more up-to-date distributions of Linux (eg Debian 12, Ubuntu 24.04) would be able to use the 'arc4random' setting. All currently supported distributions have glibc 2.25 or later (RHEL 8 has v2.28) and, therefore, have support for the 'getrandom' and 'getentropy' settings. The arc4random routines on the *BSDs (along with cygwin) implement the ChaCha20 stream cipher algorithm (see RFC8439) in userspace, rather than as a system call, and are thus somewhat faster (having avoided a context switch to the kernel). In contrast, on Linux all three functions are simple wrappers around the same kernel CSPRNG syscall. If the meson build system is used on a newer platform, then they will be configured to use 'arc4random', whereas the make build will currently default to using '/dev/urandom' on Linux. Since there is no advantage, in terms of performance, to the 'arc4random' setting, the 'getrandom' setting should be preferred from an availability perspective. (Also, the current uses of csprng_bytes() are not in any hot path). In order to set an appropriate default, set the CSPRNG_METHOD build variable to 'getrandom' in the Linux section of the 'config.mak.uname' file. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous commit started to insist TAG_F1_ONLY to be missing, which was not in the original. Let's not be overly eager in the conversion. Also, the other hunk in the commit introduced a shell syntax error, causing the test to fail. Fix it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
The ci/install-dependencies.sh script used in a very early phase of
our CI jobs downloads Perforce, Git-LFS, and JGit, used for running
the test scripts. The test framework is prepared to properly skip
the tests that depend on these external software, but the CI script
is unnecessarily strict (due to its use of "set -e" in ci/lib.sh)
and fails the entire CI run before even starting to test the rest of
the system.
Notice a failure to download to any of these external software, but
keep going. We need to be careful about cleaning after a failed
wget, as a later part of the script that does:
if type jgit >/dev/null 2>&1
then
echo "$(tput setaf 6)JGit Version$(tput sgr0)"
jgit version
else
echo >&2 "WARNING: JGit wasn't installed, see above for clues why"
fi
will (surprise!) succeed running "type jgit", and then fail with
"jgit version", taking the whole thing down due to "set -e".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Squelch false-positive from sparse. * dd/sparse-glibc-workaround: sparse: ignore warning from new glibc headers
Adjust to the deprecation of use of Ubuntu 20.04 GitHub Actions CI. * js/ci-github-update-ubuntu: ci: upgrade `sparse` to supported build agents
Work around CI breakage due to fedora base image getting updated. * js/ci-fedora-gawk: ci(pedantic): ensure that awk is installed
Make sure outage of third-party sites that supply P4, Git-LFS, and JGit we use for testing would not prevent our CI jobs from running at all. * jc/ci-skip-unavailable-external-software: ci: skip unavailable external software
Ever since we issued 2.49, external forces broke our CI jobs in various ways, and we had to adjust our code to work them around. Backmerge them from the 'master' front to make it easier to test real changes to the maintenance track. Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make sure outage of third-party sites that supply P4, Git-LFS, and JGit we use for testing would not prevent our CI jobs from running at all. * jc/ci-skip-unavailable-external-software: ci: skip unavailable external software
Test updates. * aw/t9811-modernize: t9811: fix misconversion of tests t9811: be more precise to check importing of tags
Code clean-up. * ps/object-file-cleanup: object-store: merge "object-store-ll.h" and "object-store.h" object-store: remove global array of cached objects object: split out functions relating to object store subsystem object-file: drop `index_blob_stream()` object-file: split up concerns of `HASH_*` flags object-file: split out functions relating to object store subsystem object-file: move `xmmap()` into "wrapper.c" object-file: move `git_open_cloexec()` to "compat/open.c" object-file: move `safe_create_leading_directories()` into "path.c" object-file: move `mkdir_in_gitdir()` into "path.c"
Document the convention to disable hooks altogether by setting the hooksPath configuration variable to /dev/nulll * ds/doc-disable-hooks: docs: document core.hooksPath=/dev/null
Update parse-options API to catch mistakes to pass address of an integral variable of a wrong type/size. * ps/parse-options-integers: parse-options: detect mismatches in integer signedness parse-options: introduce precision handling for `OPTION_UNSIGNED` parse-options: introduce precision handling for `OPTION_INTEGER` parse-options: rename `OPT_MAGNITUDE()` to `OPT_UNSIGNED()` parse-options: support unit factors in `OPT_INTEGER()` global: use designated initializers for options parse: fix off-by-one for minimum signed values
Various build tweaks, including CSPRNG selection on some platforms. * rj/build-tweaks: config.mak.uname: set CSPRNG_METHOD to getrandom on Linux config.mak.uname: add arc4random to the cygwin build config.mak.uname: add sysinfo() configuration for cygwin builtin/gc.c: correct RAM calculation when using sysinfo config.mak.uname: add clock_gettime() to the cygwin build config.mak.uname: add HAVE_GETDELIM to the cygwin section config.mak.uname: only set NO_REGEX on cygwin for v1.7 config.mak.uname: add a note about NO_STRLCPY for Linux Makefile: remove NEEDS_LIBRT build variable meson.build: set default help format to html on windows meson.build: only set build variables for non-default values Makefile: only set some BASIC_CFLAGS when RUNTIME_PREFIX is set meson.build: remove -DCURL_DISABLE_TYPECHECK
Signed-off-by: Junio C Hamano <gitster@pobox.com>
|
Mode: paranoid | Total findings: 5 | Considered vulnerability: 5 Insecure Processing of Data (5)
More info on how to fix Insecure Processing of Data in C/C++. 👉 Go to the dashboard for detailed results. 📥 Happy? Share your feedback with us. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )