I’d like to point out that Sage, by it’s very nature, *is* a large bundle of other people’s packages, offering them a (more or less) unified interface, thus ensuring interoperability. To reuse a simile used in Sage’s initial statements of intent, Sage is a car using many already- pepared wheels.
Any of these wheels *is* by definition, a gateway for attacking Sage. Reducing the number of packages we use entails developing suitable replacements. Do we have the manpower necessary to such development ? . Le jeudi 18 avril 2024 à 16:09:00 UTC+2, Lorenz Panny a écrit : > > This also seems like a good time to reiterate an old comment of mine: > https://groups.google.com/g/sage-devel/c/Dq83PiiCAsU/m/RKSpD9_rDQAJ > ...pasted below for your convenience. > > On Tue, 21 Dec 2021 04:04:31 +0100, Lorenz Panny <l.s....@tue.nl> wrote: > > On Mon, 20 Dec 2021 14:41:27 +0100, Michael Orlitzky < > mic...@orlitzky.com> > > wrote: > > > We already have 214 standard packages. That's 214 pieces of software > > > copy & pasted into the sage releases... and 214 SPKGs that the sage > > > developers need to keep updating, and 214 distro packages that every > > > distro maintainer needs to keep track of as dependencies of the sage > > > package. > > > > It's also 214 software packages which might, for all we know, at any > > time be hijacked by The Bad Guys to run arbitrarily malicious code on > > every Sage user's machine. > > > > This is terrifying. > > > > (For examples where the modern "import * from internet" mentality has > > led to security disasters, just search for terms like "malicious npm". > > Luckily it seems less bad with pip packages for now, but not for any > > real reason. Every single piece of code we import adds huge security > > questions, because updates to the dependency may be published at any > > time totally invisible to Sage developers and the review process used > > in Sage development. The build scripts will simply pull and run it.) > > > > We should reduce dependencies, not add more. _Especially_ when it's > > about non-essential convenience libraries. > > > On Wed, 17 Apr 2024 09:43:28 +0300, Georgi Guninski <ggun...@gmail.com> > wrote: > > If the recent xz backdoor drama didn't induce enough paranoia in you, > > here is a second chance exception: > > > > https://www.theregister.com/2024/04/16/xz_style_attacks_continue/ > > > > > > Open sourcerers say suspected xz-style attacks continue to target > maintainers > > Social engineering patterns spotted across range of popular projects > > Tue 16 Apr 2024 // 14:07 UTC > > > > Open source groups are warning the community about a wave of ongoing > > attacks targeting project maintainers similar to those that led to the > > recent attempted backdooring of a core Linux library. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "sage-devel" group. To unsubscribe from this group and stop receiving > emails > > from it, send an email to sage-devel+...@googlegroups.com. To view > > this discussion on the web visit > > > https://groups.google.com/d/msgid/sage-devel/CAGUWgD82%3DoROFFxZwrKZG6eB0Kd5GEKW8wrPw_Q4gm8WJjioCA%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/bb468057-3a03-4bfe-8e20-ce6a4c06ed77n%40googlegroups.com.