etc/reports/26-04.md
What a month! And one of the few where the report is late, and the first one where it's 3 days late! But at least I have a good reason for it: security!
In the course of just a couple of weeks a bunch of advisories were reported, and I wouldn't be surprised if this is no coincidence, with one of them openly being associated with Anthropic.
Nothing happened for a few weeks until 2 days before the report and associated release I decided to tackle them all, and opened a little security-rabbit hole in the process.
Of course, by now I can't justify doing anything purely by hand anymore so I unleashed Codex to sort out all the fixes.
After starting the review of these fixes, one advisory in particular stood out: doctored or malicious input causes panics, OOM or long runtimes in gix-pack. Isn't that something that a fuzzer would easily have found, too?
So I went in and instructed it to add fuzzers to everything that even remotely looked like a parser. 2 days of review later and a couple of discarded or severely simplified fuzz setups later, there were a lot more fixes where that one advisory came from.
The result of this effort is hardening for all even moderately complex parsers, along with all advisories fixed, making v0.82 of gix the most secure release yet.
Git uses file ownership to determine if it's allowed to open a repository, bailing completely if it's untrusted and not in safe.directory. gitoxide does it differently and merely avoids using untrusted configuration, while reducing its tolerance towards allocations that are controlled by a potential attacker (see gitoxide.objects.allocLimitIfReducedTrust).
For a long time, the implementation of said trust check was quite lacking on Windows predominantly due to my lack of skill (and pain tolerance) with the Windows API. Thankfully, LLMs feel no pain and motivated by a bug report, Codex could quite easily whip up a fix. A new Windows VM of mine that it could work on and validate fixes against definitely helped. And of course, Eliah Kagan who quickly found a fatal flaw in the first iteration that led to using a Windows VM in the first place.
Being able to run Codex on Windows definitely helps me to feel less averse to spinning it up, after all, I reduce my involvement to a couple of prompts.
As a side-effect of this work, we now also have gix free trust to evaluate the trust level of any system path, greatly helping with debugging curious cases.
As a close second major topic this month we must talk about blob diffing and the related merging in gitoxide. Thus far, we were dependent on the venerable imara-diff crate, and it just seemed to work. However, as gitoxide seems to be heavily fuzzed, Google OSS Fuzz found an imara-diff issue causing runaway computation with doctored input.
The seeming problem was quickly identified by Codex and just a one-line change. But getting that change released turned out to be a problem as I couldn't get ahold of the crate owner at all.
So I quickly decided to just fork it into gix-imara-diff, and get the fix this way. And I think it's for the better long-term as well, as I now feel much more confident to be able to maintain the crate, at least as long as I don't run out of tokens :D. Also I will finally be able to add all the tests I always wanted, also to better establish how close it is to the Git baseline.
For merges to work, two diffs are performed, base -> ours and base -> theirs. It turns out that Myers, the default, can create hunk configurations that look odd enough to cause conflicts even though that wouldn't have to be. And of course, Git doesn't suffer from the problem first reproduced by Mattias Granlund from GitButler (a company I am affiliated with).
It turns out that the solution was easy: simply apply Git-style hunk postprocessing to the diffs the merge needs, by default. This yields higher-quality and more standard diffs, along with reduced changes for inexplicable merge conflicts.
And my feeling is that this is just the beginning and line-based diffing can now get more conformant and faster as well.
PS: For best performance even in pathological cases, one should use the histogram diff (git config --global diff.algorithm histogram), which is now used in the fuzz-tests for gix-merge as otherwise the fuzzer would start tricking Myers into large runtimes with small input.
thiserror -> gix-errorLast month this section accidentally disappeared, apparently because I didn't push that topic forward for a whole month. Initially it was planned as my late-night review topic so auto-generated transitions could be reviewed one by one. It turned out to be hard to review in practice as Codex struggled with it, so review was subtle and tricky to get right, leading to me feeling faster if I had done it by hand and myself.
Maybe GPT 5.5 will make a difference and reinvigorate this topic that is very close to my heart. It will be so good to not have thiserror in gix anymore as it will allow for a much quicker implementation of new topics, while leaving excellent error chains nonetheless.
Finally gix is able to parse commit-trailers properly as these are now supported with all their intricacies (there are surprisingly many). The most useful of these improvements might be the multi-line support for trailers. The previous implementation might have only seen one line even though there were many, and the new one will correctly concatenate them into one line.
Thanks to the continuous effort of Christoph Rüßler more crates now correctly deal with SHA-256 hashes.
This includes the TreeRefIter in gix-object and SHA-256 tests run in gix-diff-tests, and many more that I can't recollect by heart.
Thank you!
Thanks to @datdenkikniet the ubiquitous tree parsing got much faster, which should be noticeable in all applications that perform a lot of tree-diffs or have to figure out 'blames', or traverse a lot of trees for other reasons.
There was also a subtle bug that prevented paths that start with a space from being parsed anymore, but that was never released fortunately.
Thanks to Fintan Halpenny from Radicle gitoxide now more correctly handles ref-prefixes when fetching, and from all I can tell they are now implemented just like in Git.
Thank you!
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.
Cheers Sebastian
PS: The latest timesheets can be found here (2026).