On Thu, Mar 20, 2025 at 11:48:06PM +0100, 'Ralf Hemmecke' via FriCAS - computer
algebra system wrote:
> Hi Waldek,
>
> On 3/20/25 23:12, Waldek Hebisch wrote:
> > There is now advisory about security break on Github due to
> > Github actions. Link to advisory:
> >
> > https://github.com/advisories/GHSA-mrrh-fwg8-r2c3
>
> Oh, how did you get notified? I haven't receive a mail from github, yet.
There was info in sage mailing list. And I followed links to
see more.
> > but AFAICS specific package (they say "tj-actions changed-files")
> > was modified by malicious actors so that it put info which
> > should be secret into log files.
>
> Do we have secret infos?
I do not know what our actions use and what they can
access.
> > I do not know if we use this package and what exactly could
> > be leaked (I hope that thing running as Github action
> > does not magically get extra priviledges to read things
> > that actions should not read, but who knows).
>
> Probably, Qian can say more. He initiated the automatic compilation.
> That's a good thing. But I don't think we overly rely on that.
> You certainly compile locally and I also have a setup that compiles every
> commit on a debian machine. So if bad things happen, FriCAS is not harmed if
> suddenly github disappears. As for the repository itself, it is even less
> problematic. Git is a distributed system, so we just would have to declare
> another (non-github) repository as "official". The only issue is that github
> is nowaday THE place where people look and build communities.
>
> Overall, FriCAS does not really depend much on Github.
>
> > However,
> > I think that there is actually bigger problem:
> > - dependence on Github infrastructure means that any
> > trouble there affects a lot of project. And Github
> > infrastructure is quite complex, so one should
> > expect troubles,
>
> Sure, but our dependency is very little.
>
> > - current trend is to have very large dependency graph.
> > Security problem at any point of dependency graph
> > may show up in seemingly unrelated place,
>
> Dependency in terms of what?
Code that is used directly or indirectly, both at runtime
and at build time.
> > - there is tendency for automatic updates and automatic
> > fetching of code via network.
>
> Do we do any of those with FriCAS? I'd say: no.
Well, in "core" no. jFriCAS needs packages installed
via pip. There is 'hsbcl' but some people advocate using
qucklisp to install Lisp dependencies. There were
recent story: popular system similar in principle
to pip or quicklisp (it probably was not pip, but I am
not sure) was used to break into several corporate
networks. Attackers created repositories claiming
to contain new versions of obscure packages, registered
them at distribution site and infrastructure picked
trojan packages and delivered to unuspecting
victims.
We need 'sphinx' for documentation build. We can get
it from Debian repo and Debian folks tend to be
careful with what they distribute. But one can get
it via pip and there seem to be less oversight in
such case.
> > More traditional
> > approach limited fetching to "known" things which
> > could be verified via cryptographic checksums and
> > that within a framework with well defined security
> > policy. Now automatic fetching from network
> > is widespread.
>
> I do not think that applies to FriCAS. By using git we automatically have
> cryptographic hashes. Nobody can easily sneek in code. And if for some weird
> reason it is done, then it can easily be undone.
At single stage it is not problem.
> > Open source has advantage due to people different than
> > authors looking at code and noticing bugs. But modern
> > tendencies make it hard to get at source code. And
> > routinely code is put in "production" use without
> > anybody looking at it.
>
> You seemingly are not talking about FriCAS itself, but about the libraries
> that FriCAS depends on. If true, why is this an issue with github?
One potential issue is that if say authorization to Github
actions leaked, somebody could create trojan binaries,
pretending to be official ones. That could be detected
reasonably fast, but could infect our users.
And concerning libraries, yes in "core" FriCAS we have good
situation, that is we depend only on system libraries
and few neccessary tools.
> > why I dislike downloads run as part of build process.
>
> Clear. Downloads should not be done during the build.
>
> > To put it differently, it is tempting to delegate
> > tricky problems to other guys. But when everybody
> > delegates, then eventually this will lead to
> > dependence on somebody incompent or malicious.
>
> Yes, yes. Delegating also means a responsibility that you watch what these
> guys are doing. But you also trust the underlying operating system and all
> the debian packages. There must be at least some trust in the world.
Yes. In general I trust that Debian packager do good job. But
there were story year ago, when malicious package entered Debian
testing. New maintainer of IIRC 'lzma' compression library
turned out to be malicious. From my point of view there were few
red signs before this happened: the bad guy commited "clever"
obfustated code to Makefiles, the claimed that for testing he
needs functionality that has noting to do with purpose of the
library, that is compression. Also, package produced from git
repository was different than package produced from distribution
tarball. And new binary version of library was twice as large
as older one. The thing was discovered when a guy from
Microsoft investigated why 'ssh' login in local network
suddenly takes more time. After that 'sshd' authors looked
why 'sshd' was linked to this library: actually, 'sshd' had
no use of the library, but 'sshd' linked to systemd library.
Supposedy, systemd was good way to handle some system
interaction. And it is not clear if systemd had good
reason to use this compression library, but it linked to
it. IIUC now 'sshd' authors decided that it is better to
implement what they need inside 'sshd' so newer 'sshd' no
longer links to systemd libraries.
Why I am writing this: trouble above was serious because
trojan allowed unauthorised login potentially to any
systed-using Linux system. And seriousness was because
of dependency chain. And malicous actions were detected
relatively late because people got desensitized to issues
like size of binary and needlessly complicated code.
So basicaly, I write that it is important to limit
dependencies, to look and try to explain various
anomalies like bigger size, sudden slowdown etc.
And to limit complexity, choose simpler variants of
code, ask if extra functionality is work complex code.
That are things that I try to do in FriCAS, but
seem to be rather unpopular in wider world.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/Z9zAsH9gBa_CJOc3%40fricas.org.
