unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Phil <phil@beadling.co.uk>
To: zimoun <zimon.toutoune@gmail.com>
Cc: help-guix@gnu.org
Subject: Re: Security of packages in official repo
Date: Thu, 26 Nov 2020 19:07:01 +0000	[thread overview]
Message-ID: <854klcq6ne.fsf@beadling.co.uk> (raw)
In-Reply-To: <86eekgrtsl.fsf@gmail.com>

Thanks for the reply Simon.

zimoun writes:

> Nothing.  It is about trust, as with any distribution.  Now, you can
> audit by yourself the source code, compiled by yourself and check if it
> is the same that the substitutes serve you.

I understand that Guix makes the process of reproducability and auditing
much more rock-solid than most other distributions - and this more than
satisfies any requirements I have for proving that software package X,
is a true representation of source code X, built with toolchain Y.

This is great - but my question is more mundane than that.

The good news is I think it's answered here:
https://guix.gnu.org/manual/en/guix.html#Submitting-Patches

Say I have a new piece of software I've developed and I want to make it
available through Guix's offical repo.  I define a new Guix package for
that app - and create a patch for it.

The important point is that the patch is vetted by the members of
guix-patches@gnu.org mail list.  And I assume packages which appear
inappropriate for whatever reason are not accepted by members of this
list?

This is different to PyPi for example where (I believe) anyone can upload
any content and have the public downloading it immediately without any
approval or vetting - it's pretty Wild West.

This makes some institutions unwilling to give students/employees/etc
access to systems like PyPi... but on other systems where there is a
degree of scrutiny required (such as patch vetting on Guix) - this can
make a world of difference in terms of getting a tick in the right box.

Whether there is wisdom or any real protection is a separate question
of course (nobody will guarantee every line of every source repo!), but
nevertheless from a practical point of view, it can prove useful in
getting software like Guix adopted - which is what I'm keen to do.

As a workaround it would seem perfectly possible to host a private Guix
channel with a subset of packages on that have been internally vetted,
but it would be more in the spirit of Guix to contribute and use the
official package repo.


Thanks - hopefully I haven't overly laboured my point!

Phil


  parent reply	other threads:[~2020-11-26 19:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-26 12:32 Security of packages in official repo Phil
2020-11-26 16:01 ` zimoun
2020-11-26 16:51   ` Ricardo Wurmus
2020-11-26 19:30     ` zimoun
2020-11-26 21:10       ` Ricardo Wurmus
2020-11-26 21:35         ` zimoun
2020-11-26 19:07   ` Phil [this message]
2020-11-26 19:50     ` zimoun

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=854klcq6ne.fsf@beadling.co.uk \
    --to=phil@beadling.co.uk \
    --cc=help-guix@gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).