public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Florian Schmaus <flow@gentoo.org>
To: gentoo-dev@lists.gentoo.org, "Michał Górny" <mgorny@gentoo.org>
Subject: Re: [gentoo-dev] [PATCH] cargo.eclass: Emit a warning if the package uses 300+ crates
Date: Tue, 14 Jan 2025 17:56:04 +0100	[thread overview]
Message-ID: <130ccb28-fcfd-48ef-9470-957b56f9c073@gentoo.org> (raw)
In-Reply-To: <5da5fd440acbae19aba855f284d58978b2aa97d6.camel@gentoo.org>


[-- Attachment #1.1.1: Type: text/plain, Size: 2488 bytes --]

On 13/01/2025 14.36, Michał Górny wrote:
> On Mon, 2025-01-13 at 10:40 +0100, Florian Schmaus wrote:
>> First, switching from individual crates to a single crate tarball
>> disallows inter-package crate archive reuse. Often, users will already
>> have the required crates downloaded because another installed package
>> used them. With an artificial create count limit, users must download
>> rather large crate tarballs, causing unnecessary traffic and increasing
>> the disk space on Gentoo's mirrors and end-user systems. The crate
>> tarballs quickly eat away the saved disk space in the ebuild repository.
> 
> I'm sure you've also done a thorough analysis on how much crate reuse
> actually happens, as well as of the impact of adding thousands of tiny
> files to Gentoo mirrors, the inefficiency of fetching them one by one,
> and especially how badly crates.io actually handles that.
> 
> I'm also sure you've done a thorough analysis of actual disk space use,
> that also takes into consideration the space wasted by thousands of
> tiny, inefficiently compressed files, compared to crate tarballs that
> benefit both from much stronger compression algorithm, as well
> as the opportunity to process much larger data blocks.

If you have numbers backing up the claimed adverse effects, please share 
them. I have demonstrated my calculations regarding ::gentoo size growth 
and its negligible effect.

I think I should *not* be the one to prove that your change is required. 
It is the responsibility of the person suggesting the change.


>> Even worse, crate tarballs negatively impact the security of Gentoo
>> users as they make it harder to audit ebuilds, and third-party crate
>> tarballs add a further distinct party that can inject malicious code.
>> Considering the recent supply chain attacks, this alone is a show-stopper.
> 
> `cargo audit` does not care about how crates are delivered to Gentoo
> systems.

I was referring to "detecting malicious modifications" as auditing. What 
'cargo audit' does is unrelated to this.


>> Why is this warning suddenly necessary? Did a user run into an issue
>> caused by more than 300 entries?
> 
> It is not "sudden".  It is an ongoing effort.

It certainly feels like all of a sudden to me. At least, as far as I 
understand, there is no trigger event or similar. I am sorry, but 
instead, it appears that you have decided that today is the day when we 
need this.

- Flow

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 21567 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

  reply	other threads:[~2025-01-14 16:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-12 12:56 [gentoo-dev] [PATCH] cargo.eclass: Emit a warning if the package uses 300+ crates Michał Górny
2025-01-12 13:15 ` Agostino Sarubbo
2025-01-12 14:30   ` Alexey Sokolov
2025-01-12 21:20     ` Ionen Wolkens
2025-01-13  9:40 ` Florian Schmaus
2025-01-13 13:23   ` orbea
2025-01-13 16:10     ` Ionen Wolkens
2025-01-13 13:36   ` Michał Górny
2025-01-14 16:56     ` Florian Schmaus [this message]
2025-01-14 17:43       ` Michał Górny

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=130ccb28-fcfd-48ef-9470-957b56f9c073@gentoo.org \
    --to=flow@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=mgorny@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