Re: How could we get society to adequately fund free software developers

In both examples (xz-utils and the event-stream example Brian points to
below), there was a divergence between the tarball and github.

Perhaps a github-based function should be developed to verify that the
primary publishing destination of the packages tarball is a true
representation of the github repository?
(providing some kind of green tick on GitHub that the referenced tarball
(presumably on another site) is legitimate)
-N

On Sun, 31 Mar 2024 at 09:41, Brian May via linux-aus <
[email protected]> wrote:

> Aníbal Monsalve Salazar via luv-main <luv-main-mJLk/csuh/[email protected]> writes:
>
> > How could we get society to adequately fund free software developers to
> > avoid this type of security threat?
> >
> > At this time, the consequences of this injection of malicious code into
> > xz-utils are not yet known with certainty.
>
> On one had, free software developers do need to be funded. Especially if
> people are using and relying on their software.
>
> https://xkcd.com/2347/
>
> On the other hand, it is perfectly normal part of OSS for one maintainer
> to pass the reins on to another developer. I have seen it happen
> numerous times (as orginal developer, as new developer, and as
> user). And I am the maintainer of a number of projects that I only
> barely keep up with.
>
> This requires the new users trust the new maintainer. But I imagine in
> many cases users aren't even aware that there is a new maintainer.
>
> Even if you trust the new maintainer, do you also trust their security
> practises? There was at least one case where malware was found due to a
> hacked account.
>
>
> https://therecord.media/malware-found-in-npm-package-with-millions-of-weekly-downloads
>
> Most of the time none of is a news worthy story however. Either The new
> maintainers do a good job of contining the project. Or the circumstances
> change and the new maintainers end up in the exact same situation as the
> old maintainer. I have seen both sitations happen.
>
> This story reminds me of an npm package. The maintainer passed on the
> job to a new maintainer as they were no longer interested in maintaining
> the package. The new maintainer added a dependancy on another package
> which had back door code. Or something like that. Oh, think I found it:
>
>
> https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502
>
> Then again for another example, have a look at redis. Seems they managed
> to alienate the entire community with one PR
> (https://github.com/redis/redis/pull/13157). As a result there are a
> number of forks, such as keydb. How do we know we can trust the new
> maintainers? It probably is going to be OK, right? But is anybody
> checking the commits they make?
>
> It also makes me a bit uncomfortable with how shared libraries work. The
> recent attack demonstrates that a shared library can compromise a
> completely unrelated binary. It is a bit unfair to blame systemd here,
> it could be a NSS or PAM module that pulls in the compromised
> library. Makes me think maybe we need better isolation - but not sure
> how you would do this or if it is feasible.
> --
> Brian May @ Linux Penguins
> _______________________________________________
> linux-aus mailing list
> [email protected]
> http://lists.linux.org.au/mailman/listinfo/linux-aus
>
> To unsubscribe from this list, send a blank email to
> linux-aus-unsubscribe-cunTk1MwBs8iFSDQTTA3OBCuuivNXqWP@public.gmane.org

_______________________________________________
linux-aus mailing list
[email protected]
http://lists.linux.org.au/mailman/listinfo/linux-aus

To unsubscribe from this list, send a blank email to
linux-aus-unsubscribe-cunTk1MwBs8iFSDQTTA3OBCuuivNXqWP@public.gmane.org