[Linux-aus] How could we get society to adequately fund free software developers

[Brian May]

Aníbal Monsalve Salazar via luv-main <luv-main at luv.asn.au> 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