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.

Reply via email to