3 ms·

But this suggests reimplementing xz/lzma. Which would cost money. Hence, won't be done.

by lrem 3y ago

frankjr 3y ago
But there are alternatives, most notably zstd.
- WesolyKubeczek 3y ago
  It's a different algorithm made for a different purpose.
- fsniper 3y ago
  a half-arsed search resulted in this half-baked rust library: https://github.com/gendx/lzma-rs https://github.com/gendx/lzma-rs
- kzrdude 3y ago
  sadly, the zstd cli tool links to lzma right now (as installed by some distros) :/
dspillett 3y ago
> But this suggests reimplementing xz/lzma. 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.
- WesolyKubeczek 3y ago
  > 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.
  - dspillett 3y ago
    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.
    - kzrdude 3y ago
      It should be easy to go back to https://snapshot.debian.org/ https://snapshot.debian.org/ and one more repository and verify old untainted releases between the two archives.

But this suggests reimplementing xz/lzma. Which would cost money. Hence, won't be done.

by lrem 3y ago

But this suggests reimplementing xz/lzma. Which would cost money. Hence, won't be done.

frankjr 3y ago

But there are alternatives, most notably zstd.

WesolyKubeczek 3y ago
It's a different algorithm made for a different purpose.
fsniper 3y ago
a half-arsed search resulted in this half-baked rust library: https://github.com/gendx/lzma-rs https://github.com/gendx/lzma-rs
kzrdude 3y ago
sadly, the zstd cli tool links to lzma right now (as installed by some distros) :/

dspillett 3y ago

> But this suggests reimplementing xz/lzma. 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.

WesolyKubeczek 3y ago
> 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.
- dspillett 3y ago
  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.
  - kzrdude 3y ago
    It should be easy to go back to https://snapshot.debian.org/ https://snapshot.debian.org/ and one more repository and verify old untainted releases between the two archives.