Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.kernel.org/pub/scm/git/git.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDerrick Stolee <derrickstolee@github.com>2023-08-10 23:39:40 +0300
committerJunio C Hamano <gitster@pobox.com>2023-08-11 00:04:16 +0300
commit89024a0ab018bb6e8ad2e4a6500b98b889088c54 (patch)
tree446ff717dc358f798accddb8a9403cf1d640e71c /wrapper.c
parenta82fb66fed250e16d3010c75404503bea3f0ab61 (diff)
maintenance: add get_random_minute()
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 <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'wrapper.c')
-rw-r--r--wrapper.c10
1 files changed, 10 insertions, 0 deletions
diff --git a/wrapper.c b/wrapper.c
index 5160c9e28d..48065c4f53 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -819,3 +819,13 @@ int csprng_bytes(void *buf, size_t len)
return 0;
#endif
}
+
+uint32_t git_rand(void)
+{
+ uint32_t result;
+
+ if (csprng_bytes(&result, sizeof(result)) < 0)
+ die(_("unable to get random bytes"));
+
+ return result;
+}