Re: backdoor injection via release tarballs combined with binary artifacts (was Re: Backdoor in upstream xz-utils)

[Skyler Ferris]

Hi again,

On 4/12/24 23:50, Giovanni Biscuolo wrote:
> Hello,
>
> general reminder: please remember the specific scope of this (sub)thread
>
> --8<---------------cut here---------------start------------->8---
>
>   Please consider that this (sub)thread is _not_ specific to xz-utils but
>   to the specific attack vector (matrix?) used to inject a backdoor in a
>   binary during a build phase, in a _very_ stealthy way.
>
>   Also, since Guix _is_ downstream, I'd like this (sub)thread to
>   concentrate on what *Guix* can/should do to strenghten the build process
>   /independently/ of what upstreams (or other distributions) can/should
>   do.
>
> --8<---------------cut here---------------end--------------->8---
> (8734s1mn5p.fsf@xelera.eu/">https://yhetil.org/guix/8734s1mn5p.fsf@xelera.eu/)
>
> ...and if needed read that message again to understand the context,
> please.
>
>
I assume that this was an indirect response to the email I sent 
previously where I discussed the problems with PGP signatures on release 
files. I believe that this was in scope because of the discussion about 
whether to use VCS checkouts which lack signatures or release tarballs 
which have signatures. If the signatures on the release tarballs are not 
providing us with additional confidence then we are not losing anything 
by switching to the VCS checkout. Analysis of the effectiveness of what 
upstream projects are doing is relevant when trying to determine what we 
are capable of doing. I also pointed out that a change to Guix such as 
adding signature metadata to packages could help make up for problems 
with upstream workflows and how the review process provides additional 
confidence, demonstrating how this analysis is relevant to what to 
currently/could possibly do. Please let me know if you think that this 
is incorrect.

Additionally, I need to correct something that I previously said. I 
stated this:

On 4/12/24 17:14, Skyler Ferris wrote:
> even the tails project gets this part of security wrong and they are 
> generally diligent in their efforts

Without first double-checking the current state of the project. While 
this was true at one point, they have since updated their website and 
clearly explain the problem and what their new verification method is 
able to protect against at 
https://tails.net/contribute/design/download_verification/. I apologize 
for disseminating outdated information.