Re: “Building a Secure Software Supply Chain with GNU Guix”

[bokr@bokr.com]

On +2022-06-30 16:13:10 +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> I’m happy to announce the publication of a refereed paper in the
> Programming journal:
> 
>   https://doi.org/10.22152/programming-journal.org/2023/7/1
> 
> It talks about the “secure update” mechanism used for channels and how
> it fits together with functional deployment, reproducible builds, and
> bootstrapping.  Comments from reviewers showed that explaining the whole
> context was important to allow people not familiar with Guix or Nix to
> understand why The Update Framework (TUF) isn’t a good match, why
> Git{Hub,Lab} “verified” badges aren’t any good, and so on.
> 
> What’s presented there is not new if you’ve been following along, but
> hopefully it puts things in perspective for outsiders.
> 
> I also think that one battle here is to insist on verifiability when a
> lot of work about supply chain security goes into “attestation” (with
> in-toto, sigstore, Google’s SLSA, and the likes.)
> 
> Enjoy!
> 
> Ludo’.

Congratulations!

And thank you! I needed that assurance that guix really takes trust
seriously, and has a convincing internals story to back it up.

The "artifact" at [1] has a README.md [2] that's IMO definitely
also worth a read even if you aren't going to execute the image.

[1] <https://zenodo.org/record/6581453>
[2] <https://zenodo.org/record/6581453/files/README.md?download=1>

About this example (I like documentation that provides
things you can try):
--8<---------------cut here---------------start------------->8---
  5. Going back to our target revision, we can see that `gpg` can indeed
     verify signatures now: `git checkout
     20303c0b1c75bc4770cdfa8b8c6b33fd6e77c168 && git log --oneline
     --show-signature`.  `gpg` warns about expired keys but, as the
     paper notes, OpenPGP key expiration dates are ignored for our
     purposes (and the authentication code in Guix does *not* use
     `gpg`).
--8<---------------cut here---------------end--------------->8---

I think IWBN to have some kind of trust code come with that git output,
like gpg's 1-5 but indicating how well the committer/signer trusts
that using the code will *not* cause a problem.

I would like it if every commit had to have a code like that.

Even if it was "0," indicating that the committer judged
security to be irrelevant, I'd feel better knowing it was
part of committer workflow to be nudged into thinking
about the security aspect of the commit.

(Code alternative: an answer to the old real-opinon-extractor:
"How much money at what odds will you bet me this 
commit will not cause me problems?" ;-)

<ignorable class=rambling>
Hm, actually I think a 3-digit LTS code is required for reviewing:
with L indicating trust that the contribution is Legally ok,
and  T indicating trust in Technical competence of contributors
snd  S indicating trust in the Social aspect of the contribution crim/saint

OTTOMH encoding: digits 0-9: 0=NO Info, 1-9: subtract 5 =-> -4..+4,
with negatives meaning un-good opposites of positives. So code 191 would
be -4,+4,-4 for e.g.
  L-4: certain to have patent problems,
  T+4: contributed by a professional hacker,
  S-4: known criminal in supply chain.
</ignorable>

--
Regards,
Bengt Richter