public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org, Arthur Zamarin <arthurzam@gentoo.org>
Subject: Re: [gentoo-dev] Re: EGO_SUM
Date: Fri, 02 Jun 2023 10:31:28 +0200	[thread overview]
Message-ID: <84c8b5eb6cef8bb7e292642c7ab9b8bab79dd849.camel@gentoo.org> (raw)
In-Reply-To: <012fa74d-2910-ea90-6008-26cc23604d2f@gentoo.org>

On Fri, 2023-06-02 at 10:17 +0200, Florian Schmaus wrote:
> On 30/05/2023 18.35, Arthur Zamarin wrote:
> > On 30/05/2023 18.52, Florian Schmaus wrote:
> > > To prevent harm from Gentoo, we should reach an agreement that everyone
> > > can live with. To achieve a consensus, and since I can not rule out that
> > > I missed a post that includes specific numbers, please share your ideas
> > > on how EGO_SUM could be reinstated in ::gentoo by replying to this mail.
> > 
> > I still want to ask why in ::gentoo should it be enabled? I'm trying to
> > understand why? 
> 
> In short: Auditability
> 
> Let me try to explain with a simplified example.
> 
> Gentoo's ebuilds contain the instructions to transform source code 
> (input) via a compilation process (transformation) into a binary image 
> (output).
> 
> A pseudo-example ebuild may contain the following
> 
> foo-1.0.ebuild:
> ```
> # Input
> SRC_URI="https://foo-soft.org/foo/1.0/foo-1.0.tar.gz"
> 
> # Transformation
> src_compile() {
>      emake foo
> }
> 
> # Output into imagedir $D
> src_install() {
>      emake DESTDIR="${D}" foo-install
> }
> ```
> 
> A Gentoo developer, Gentoo user, or, anyone can look at the ebuild and 
> immediately tell that it will likely not inject malicious code into the 
> resulting binary image. Furthermore, the only input is from upstream, 
> and while you may not look at every line of source code, you assign a 
> certain trust level to upstream and probably assume that the input is 
> also likely non-malicious.
> 

This reasoning is seriously flawed.  A "typical" EGO_SUM ebuilds
contains dozens to hundreds of different packages from dozens of
different authors.  You can't seriously expect anyone to be able to
reasonably establish trust to all of them.

In the end, gentoo.git security model is entirely reliant
on the developer verifying the final product and signing on it. 
Everything else is untrustworthy noise.

-- 
Best regards,
Michał Górny



  reply	other threads:[~2023-06-02  8:31 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-17  7:37 [gentoo-dev] EGO_SUM Florian Schmaus
2023-04-17  9:28 ` [gentoo-dev] EGO_SUM Anna (cybertailor) Vyalkova
2023-04-27 18:00   ` William Hubbs
2023-04-27 18:18     ` David Seifert
2023-04-24 16:11 ` Florian Schmaus
2023-04-24 20:28   ` Sam James
2023-04-24 22:52     ` Alexey Zapparov
2023-04-26 15:31     ` Florian Schmaus
2023-04-26 16:12       ` Matt Turner
2023-04-26 19:31         ` Andrew Ammerlaan
2023-04-26 19:38           ` Chris Pritchard
2023-04-26 20:47           ` Matt Turner
2023-04-27  7:58         ` Florian Schmaus
2023-04-27  9:24           ` Ulrich Mueller
2023-04-28  6:59             ` Florian Schmaus
2023-04-27 12:54           ` Michał Górny
2023-04-27 23:12             ` Pascal Jäger
2023-04-28  0:38               ` Sam James
2023-04-28  4:27                 ` Michał Górny
2023-04-28  5:31                   ` Sam James
2023-04-28  6:59             ` Florian Schmaus
2023-04-28 14:34               ` Michał Górny
2023-05-02 19:32                 ` Florian Schmaus
2023-05-02 19:38                   ` Sam James
2023-04-29 22:34               ` Robin H. Johnson
2023-04-27 21:16           ` Sam James
2023-05-02 19:32             ` Florian Schmaus
2023-05-02 19:45               ` Sam James
2023-05-08  7:53                 ` Florian Schmaus
2023-05-08 12:03                   ` Michał Górny
2023-05-22  7:14                     ` Florian Schmaus
2023-05-02 20:04               ` Matt Turner
2023-05-08  7:53                 ` Florian Schmaus
2023-04-26 20:51       ` Sam James
2023-05-30 15:52   ` Florian Schmaus
2023-05-30 16:30     ` Anna (cybertailor) Vyalkova
2023-05-31  5:02       ` Oskari Pirhonen
2023-05-30 16:35     ` Arthur Zamarin
2023-05-31  6:20       ` Andrew Ammerlaan
2023-05-31  8:40         ` Ryan Qian
2023-05-31  9:06         ` Arsen Arsenović
2023-05-31  6:30       ` pascal.jaeger leimstift.de
2023-06-01  4:00         ` William Hubbs
2023-06-02  8:17       ` Florian Schmaus
2023-06-02  8:31         ` Michał Górny [this message]
2023-06-09 10:07           ` Florian Schmaus
2023-06-01 19:55 ` [gentoo-dev] EGO_SUM William Hubbs
2023-06-02  7:13   ` Joonas Niilola
2023-06-02 18:06     ` William Hubbs
2023-06-02 18:42       ` Joonas Niilola
2023-06-09 10:07   ` Florian Schmaus

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=84c8b5eb6cef8bb7e292642c7ab9b8bab79dd849.camel@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=arthurzam@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /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