Re: [gentoo-dev] [PATCH] cargo.eclass: Emit a warning if the package uses 300+ crates

2025-01-14 Thread Florian Schmaus

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


OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] cargo.eclass: Emit a warning if the package uses 300+ crates

2025-01-14 Thread Michał Górny
On Tue, 2025-01-14 at 17:56 +0100, Florian Schmaus wrote:
> 
> 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.

I know it's hard to imagine but some of us aren't paid to work
on Gentoo, and have to earn our living + deal with other
responsibilities, so we do things when we find time to do them.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Google Summer of Code for Gentoo for the year 2025

2025-01-14 Thread Yury German
Hey everyone!

The Google Summer of Code (GSoC) has announced the new application deadline for 
organizations. Gentoo needs to submit their application with proposed projects 
by February 11th. They’ve specifically requested more “Security and AI/ML” 
projects for GSoC.

We’re seeking volunteers to assist as Mentors or Co-Mentors for this year’s 
summer of code. As part of this initiative, we’re eager to come up with fresh 
ideas to replace (or ideally, all) of the projects from last year’s summer of 
code. You can find the ideas page for the 2024 Gentoo GSoC page.

 If you’re willing to volunteer as a mentor, please let me know via email or in 
IRC. There’s also an IRC channel set up for discussions related to SOC 
information (#gentoo-soc).

We are thrilled to welcome developers who are eager to contribute!

Thanks,
BlueKnight