unofficial mirror of gwl-devel@gnu.org
 help / color / mirror / Atom feed
From: Konrad Hinsen <konrad.hinsen@fastmail.net>
To: zimoun <zimon.toutoune@gmail.com>
Cc: gwl-devel@gnu.org
Subject: Re: Getting started with GWL 0.3.0
Date: Wed, 24 Mar 2021 11:08:00 +0100	[thread overview]
Message-ID: <m1v99gkgov.fsf@ordinateur-de-catherine--konrad.home> (raw)
In-Reply-To: <CAJ3okZ3=ey3Z8FqwGROveFg4L-E=y+EH-p1=CDafmR9kbOJB7w@mail.gmail.com>

Hi Simon,

>> As for trusting channels and packages, this is not much of an issue
>> today, but if Guix ever becomes as popular as Debian is today, then we
>> will have plenty of users with no clue about who or what they can trust.
>
> ...and you can do the same with any package manager.  For instance,

Yes, exactly. Trusting software sources is becoming an ever more
important issue everywhere, as people rely on ever more complex software
assemblies whose components they can no longer verify individually.
Which is also why package managers now become targets of attacks.

> The issue at first is the channel.  There is official channels that
> you are trusting and other channels that you cannot trust.  Well, your

The channel is only the top level. Do I trust the "Guix" channel? More
than other channels, but I don't really know how much the current
maintainers check each individual package submission. They certainly
look at the package definition itself, but do they also check that the
packaged software itself is free from malware? If so, how thorough are
those checks? There are so many possible levels of attack today.

> Well, checking at each command invocation could slow Guix, since it is
> already not the fastest CLI of West. :-)

Such checks could happen at a higher level, e.g. shell or terminal, to
cover not only Guix but also everything else. As Ricardo pointed out,
such checks cannot be perfect, but that's true for spell checkers as
well, which nevertheless turn out to be useful. The goal is not provably
absolute security, but noticeably increased security.

BTW, I consider IT security and reproducibility in research as almost
the same problem. The former's enemy is malice, the latter's enemy
is mistakes, but the common aspect of both is users not fully knowing
which exact software they are running. In reproducibility, typos are a
well-known issue and one reason why we recommend scripting everything,
to turn the random typo into a reproducible typo.

Cheers,
  Konrad.


  reply	other threads:[~2021-03-24 10:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-22 10:32 Getting started with GWL 0.3.0 Konrad Hinsen
2021-03-22 11:03 ` zimoun
2021-03-22 13:04   ` Konrad Hinsen
2021-03-22 13:51     ` zimoun
2021-03-22 15:07       ` Konrad Hinsen
2021-03-22 18:16         ` zimoun
2021-03-23 12:57           ` Konrad Hinsen
2021-03-23 13:16             ` Ricardo Wurmus
2021-03-23 13:24               ` Roel Janssen
2021-03-23 20:16             ` zimoun
2021-03-24 10:08               ` Konrad Hinsen [this message]
2021-03-24 10:44                 ` zimoun
2021-03-23 15:51 ` Konrad Hinsen
2021-03-23 17:34   ` Ricardo Wurmus
2021-03-23 19:30     ` Roel Janssen
2021-03-23 20:14       ` Ricardo Wurmus
2021-03-23 20:30         ` Roel Janssen
2021-03-26 21:01           ` Ricardo Wurmus
2021-04-30 21:50       ` Ricardo Wurmus
2021-03-24  9:52     ` Konrad Hinsen

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://www.guixwl.org/

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

  git send-email \
    --in-reply-to=m1v99gkgov.fsf@ordinateur-de-catherine--konrad.home \
    --to=konrad.hinsen@fastmail.net \
    --cc=gwl-devel@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).