On Tue, 2024-04-02 at 12:29 +0200, Robin Candau wrote:
> On 4/2/24 11:59 AM, Robin Candau wrote:
Couple of comments.
* In lkml thread on same topic not everyone is on board with this [1]
* Where to put this kind of thing
Would it make sense to collect these kind of "system" settings, that
dont clearly belong to a specific application, into a separate package
(arch-system-settings or whatever). Admittedly at moment this would be
very small package 🙂
[1]Â https://lkml.org/lkml/2024/4/2/404
--
Gene
On Fri, 2024-03-29 at 18:55 +0000, Arch Linux: Recent news updates:
David Runge wrote:
> TL;DR: Upgrade your systems and container images **now**!
>
>
Thanks for sharing. Truly an astounding revelation.
This is a very, very sophisticated tool-chain attack along the lines of
Ken Thompson's famous compiler trust example [1]
Arch has been a strong advocate for reproducible builds [2] which can
be part of a defense strategy [2]. I note that our xz package is marked
as good in this regard [3]. I wonder what more we can reasonably do in
the near term.
Since git gives us decent tools to check what changed etc., I would
imagine that can provide a stronger base on which to check things than
working with tarballs or tarballs alone. Â
This may have gone largely un-noticed for so long as people are
probably more likely to check the source than the tarball itself. In
this case, it seems, it was a primary developer doing the naughty - but
they chose to leave the git repo alone and only infect the tarball.
Question:
--------
Would it make sense, therefore, to switch builds, where possible, away
from tar files and instead pull directly from git source (signed tags
where possible as usual etc)? Of course a git repo can also carry
infections - perhaps taht's a little less likely.
Or is this not worth the trouble?
Gene
[1] https://wiki.c2.com/?TheKenThompsonHack
[2] https://reproducible-builds.org/https://wiki.archlinux.org/title/DeveloperWiki:ReproducibleBuildshttps://bootstrappable.org/
[3] https://reproducible.archlinux.org/
--
Gene