On 02/06/2023 10.31, Michał Górny wrote:
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 […] 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.
I am sorry. I was unable to get my point across.The security impact is unrelated to what you describe. You always have a certain degree of trust in upstream. Regardless if upstream is consumed by 100 Gentoo packages or if there are 100 entries in EGO_SUM.
The point was and is about *non-upstream input* in the ebuild. While EGO_SUM fetches its artifacts from upstream, a dependency tarball does typically not originate from upstream.
Even if we would not trust EGO_SUM upstream, consuming inputs via EGO_SUM would still be better from a security perspective because EGO_SUM upstream is consumed by Gentoo and all of Go's ecosystem. Hence, if something gets compromised, it will likely be detected quickly. Compared to dependency tarballs, which are usually only consumed by Gentoo.
> 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.How do you verify the output, that is, final product? This is hard, for example, reproducible builds are far from trivial to achieve.
On the other hand, ensuring that the input matches what upstream provides and expects is far more manageable.
- Flow
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
