If there is a known good copy of the repo from before the attacker had sufficient access to alter history, then that is an acceptable starting point.
From there you look at each update since and assess what they do to decide if you want to keep (as they are valid improvements/fixes) or discard them. If some are discarded, then later ones that are valid may need further work to integrate them into the now changed codebase. Similar to Debian assessing upstream security patches to the latest version to possibly back-port them to the version they have in stable, when there is significant disparity (due to a project being much faster moving than Debian:Stable).
As xz/xzutils is a relatively stable package, with very few recent changes, this should be quite practical. A full rewrite shouldn't be needed at all here.
> If there is a known good copy of the repo from before the attacker had sufficient access to alter history, then that is an acceptable starting point.
I heard someone calling themselves “Honest Ivan” has just the thing, totally trustworthy.
Given how spread the copies could be, and that we know when the bad actor gained the level of control needed to upset history, or if we want to go further back when that user started making contributions, it is likely that by comparing many claims we can prove to a reasonable level of assurance¹ that a given version is untouched in that regard.
Furthermore the original main maintainer seems to have a repository with an untouched lineage. While true paranoia says they can't be trusted without verification (he could be under external influence, as could anyone) I think we can safely give their claims more credence than those of Honest Ivan.
--
[1] to the level where a clean-room implementation is not significantly less likely to be compromised by external influence with bad motives.
If there is a known good copy of the repo from before the attacker had sufficient access to alter history, then that is an acceptable starting point.
From there you look at each update since and assess what they do to decide if you want to keep (as they are valid improvements/fixes) or discard them. If some are discarded, then later ones that are valid may need further work to integrate them into the now changed codebase. Similar to Debian assessing upstream security patches to the latest version to possibly back-port them to the version they have in stable, when there is significant disparity (due to a project being much faster moving than Debian:Stable).
As xz/xzutils is a relatively stable package, with very few recent changes, this should be quite practical. A full rewrite shouldn't be needed at all here.