[February 26] - Gitoxide in the Secure Open Source Fund

[Byron]

While the big bang supposedly happened very fast, the error conversion is still ongoing - please do read on :).

Our participation in the Secure Open Source Fund

As has recently been officially announced and as noted in #2439, gitoxide is one of the 67 projects that took part in Session 3 of the GitHub Secure Open Source Fund, a program run by the GitHub Security Lab. The aim of the program is to improve software supply chain security.

This consisted of an intensive 3-week training sprint in September, "office hours" and other channels of communication to members of the GitHub Security Lab, funding, forthcoming check-ins, Azure credits provided through Microsoft for Startups, opportunities to work together with maintainers of other projects to discuss and improve security, and a number of other resources. Applications for the next session of the Secure Open Source Fund have opened; some more information about the program is available here.

It has been an honor to take part in this, alongside maintainers of many remarkable free open source projects, which are listed on this page by category. Some of them are projects for which even to say we use them every day is an understatement--such as rustls, curl, and LLVM.

Concrete improvements so far that have arisen from our participation in the program have included writing and adopting an Incident Response Plan, as well as outlining a provisional threat model (#2192); avoiding persisting authentication tokens on CI, to prevent them from being exfiltrated even in the event of inadvertent coupling of the test suite with the checked-out gitoxide repository itself (#2187); reducing the attack surface for supply chain attacks by pinning actions dependencies and using a 7-day cooldown period for both Rust (Cargo) and GitHub Actions dependencies (#2337); increasing our use of security scanning, by enabling CodeQL for Rust, using both CodeQL and Zizmor to scan our CI workflows (rather than just CodeQL), and enabling more than the default queries in both; and some less visible changes such as enforcing more robust 2-factor authentication for contributors with write access. Some further improvements are ongoing.

Other benefits have included gaining a better understanding of some areas of security where we have been weaker or that are emerging, getting answers to a number of questions, being set on the right path toward figuring out some subtleties related to the intersection between portability and security, and the help of members of the GitHub Security Lab in answering some questions about both general and specific approaches to finding possible vulnerabilities in gitoxide.

Thanks to all the people at GitHub for running this program and for all their help, to the organizations that support and fund the program, and to Microsoft for Startups for the associated grant of Azure credits for gitoxide!

A slow burn: replace thiserror with gix-error

It all started with this blog post which inspired the massive changes that are in progress now.

By now, a certain level of dread has kicked in, though, as the conversion is incredibly tedious. While some of that can be caught by AI, it still needs careful review. And because it's tedious, it's difficult to stay laser-focused at all times.
By now, I have settled into an AI-driven crate-by-crate upgrade, and at this pace, it's probably only going to take until the end of the year.

Let's hope this speeds up over time, which also depends on me actually making time to work on it. These days I can only do that at night and often I just don't feel strong enough 😅. But since it's started, it will be brought to a conclusion, and I can only be looking forward to that rewarding feeling when it's finally all done.

As an interesting side effect, the plumbing crates using exn now suffer from the same issue as crates that use anyhow: they are harder to use for anyone who needs std::error::Error, as Exn can't implement it. And now that I am writing this, I realise that the only reason for this is the From implementation, which doesn't really have to be used by plumbing code. It's easy to avoid ? in exchange for a small extension trait, with possibly a great effect on downstream usability.

I will definitely take a look.

Community

Incubating SHA-256 support: the first SHA-256 tests

Thanks to Christoph Rüßler, the gix-testtools crate now comes with a new GIX_TEST_FIXTURE_HASH environment-variable-based flag that allows switching fixtures to SHA-256. These fixtures are then used transparently in tests specifically re-run with this environment variable set.

Just like Git, we now run the tests of ported crates twice, once for SHA-1, then once more for SHA-256.

Lastly, it's now clear that the gix-hash crate will come without a default hash enabled, so it can't be compiled without selecting one. gix-* plumbing crates also won't select a hash anymore, while gix itself will still use SHA-1 by default.
That way, users of gix as well as users of the plumbing crates can decide which hashes they want to support, but they must make that decision in order to build the plumbing.

Improve tree-diff performance

It turns out that all this time, diffing trees was much slower than it had to be, as it seemingly always traversed the entire tree, even if the tree OIDs already proved there was nothing to find. This is quite unbelievable, but apparently true.

Using ein t query on the Git repository yields db cache done 79.1k events in 4.72s (16.8k events/s), and with this fix it's done in 3.63s: db cache done 79.1k events in 3.63s (21.8k events/s), about 30% faster.

This will be a big deal for a lot of algorithms, as diffing trees is the bread and butter of Git.

Honorable mentions

• Broken/invalid symlink handling in gix status fixed in #2440
• Windows tempfile persist retry logic in #2419
• Repository/protocol correctness and type-safety improvements: broader non-empty modeling landed in #2433
• Date parsing/unsafe removal: named relative dates (now, today, yesterday) and safe UTF-8 handling in #2426

Gix in Cargo

There is nothing new here, but let's keep the horizon active:

With GitButler slated to have its checkout driven by a tailor-made implementation of 'reset' in gitoxide, this coincidentally is exactly what Cargo would need to also greatly speed up its checkouts and make them more compatible, too. We are talking proper Git filter support, and speedups in the realms of ~7x (see the GitButler paragraph for details).

Cheers
Sebastian

PS: The latest timesheets can be found here (2026).