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 via email to