all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: bokr@bokr.com
To: "Ludovic Courtès" <ludovic.courtes@inria.fr>
Cc: guix-devel <guix-devel@gnu.org>, guix-science@gnu.org
Subject: Re: “Building a Secure Software Supply Chain with GNU Guix”
Date: Thu, 30 Jun 2022 23:37:35 +0200	[thread overview]
Message-ID: <20220630213735.GA9726@LionPure> (raw)
In-Reply-To: <87zghu5jex.fsf@inria.fr>

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


  reply	other threads:[~2022-06-30 21:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-30 14:13 “Building a Secure Software Supply Chain with GNU Guix” Ludovic Courtès
2022-06-30 21:37 ` bokr [this message]
2022-07-01  9:21   ` zimoun
2022-07-03 10:38     ` Bengt Richter
2022-07-04  8:21       ` zimoun
2022-07-04 14:56         ` Bengt Richter
2022-07-04  7:44   ` Ludovic Courtès
2022-07-17  7:54 ` Zhu Zihao
2022-07-18  8:45   ` Ludovic Courtès
2022-07-18  9:40     ` Zhu Zihao
2022-07-18 12:30       ` Ludovic Courtès
2022-07-18 12:38         ` Ricardo Wurmus
2022-07-19 13:53     ` Maxime Devos
2022-07-19  7:21 ` Arun Isaac
2022-07-19 12:11   ` Ludovic Courtès
2022-07-20  6:17     ` Arun Isaac
2022-07-19 13:45   ` Maxime Devos
  -- strict thread matches above, loose matches on Subject: below --
2022-07-19  0:35 Jeremiah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220630213735.GA9726@LionPure \
    --to=bokr@bokr.com \
    --cc=guix-devel@gnu.org \
    --cc=guix-science@gnu.org \
    --cc=ludovic.courtes@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.