I had no idea this issue had been identified. While I find this tool very useful, the project is seeming rather questionable to me now.
I had no idea this issue had been identified. While I find this tool very useful, the project is seeming rather questionable to me now.
I too wish the developer would respond, but I don’t think this is the catastrophe people are making it out to be. One comment seems to explain why these binaries are included:
If the hashes match the files from the Fedora or OpenSUSE releases, then does this really matter?
It matters because nobody is going to check the hashes for all of the files match whenever there’s a change so the maintainer can just replace them with whatever he wants.
that’s what automation is for - nobody is going to manually check them, but anyone is able to automatically set something up to check their hashes in change… the fact that it’s possible that anyone is doing that now that it’s a known issue perhaps makes it less problematic as an attack vector
That is true, but also nobody is doing it. Just like nobody is verifying Signal’s “reproducible builds”.
are you sure?
there could be thousands just waiting for a failure to come out and say “HEY THIS IS DODGY”
Yea because I tested it myself. Nobody else seems to care, and if they did, I would think there would be a public way to see regular test results regardless.
I know this exists for some projects, but somehow nothing privacy-sensitive
On the contrary: that just goes to show what a fucking catastrophe for software freedom “Secure[sic] Boot” is.
While this is true, it only requires the shim and grub to be copied for another distro.
From other comments there are a lot more blobs than just these two.
It sounds like most, if not all, come from upstream projects.
Would be nice if the dev can respond and confirm that…
It sounds to me as a documentation issue, as the next comment says, simply including a
wgetscript should solve this.that’s only a few files out of the 153
153 binaries? where?