<div dir="ltr"><div>In both examples (xz-utils and the event-stream example Brian points to below), there was a divergence between the tarball and github.</div><div><br></div><div>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?</div><div>(providing some kind of green tick on GitHub that the referenced tarball (presumably on another site) is legitimate)</div><div>-N</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 31 Mar 2024 at 09:41, Brian May via linux-aus <<a href="mailto:linux-aus@lists.linux.org.au">linux-aus@lists.linux.org.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Aníbal Monsalve Salazar via luv-main <<a href="mailto:luv-main@luv.asn.au" target="_blank">luv-main@luv.asn.au</a>> writes:<br>
<br>
> How could we get society to adequately fund free software developers to<br>
> avoid this type of security threat?<br>
><br>
> At this time, the consequences of this injection of malicious code into<br>
> xz-utils are not yet known with certainty.<br>
<br>
On one had, free software developers do need to be funded. Especially if<br>
people are using and relying on their software.<br>
<br>
<a href="https://xkcd.com/2347/" rel="noreferrer" target="_blank">https://xkcd.com/2347/</a><br>
<br>
On the other hand, it is perfectly normal part of OSS for one maintainer<br>
to pass the reins on to another developer. I have seen it happen<br>
numerous times (as orginal developer, as new developer, and as<br>
user). And I am the maintainer of a number of projects that I only<br>
barely keep up with.<br>
<br>
This requires the new users trust the new maintainer. But I imagine in<br>
many cases users aren't even aware that there is a new maintainer.<br>
<br>
Even if you trust the new maintainer, do you also trust their security<br>
practises? There was at least one case where malware was found due to a<br>
hacked account.<br>
<br>
<a href="https://therecord.media/malware-found-in-npm-package-with-millions-of-weekly-downloads" rel="noreferrer" target="_blank">https://therecord.media/malware-found-in-npm-package-with-millions-of-weekly-downloads</a><br>
<br>
Most of the time none of is a news worthy story however. Either The new<br>
maintainers do a good job of contining the project. Or the circumstances<br>
change and the new maintainers end up in the exact same situation as the<br>
old maintainer. I have seen both sitations happen.<br>
<br>
This story reminds me of an npm package. The maintainer passed on the<br>
job to a new maintainer as they were no longer interested in maintaining<br>
the package. The new maintainer added a dependancy on another package<br>
which had back door code. Or something like that. Oh, think I found it:<br>
<br>
<a href="https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502" rel="noreferrer" target="_blank">https://medium.com/intrinsic-blog/compromised-npm-package-event-stream-d47d08605502</a><br>
<br>
Then again for another example, have a look at redis. Seems they managed<br>
to alienate the entire community with one PR<br>
(<a href="https://github.com/redis/redis/pull/13157" rel="noreferrer" target="_blank">https://github.com/redis/redis/pull/13157</a>). As a result there are a<br>
number of forks, such as keydb. How do we know we can trust the new<br>
maintainers? It probably is going to be OK, right? But is anybody<br>
checking the commits they make?<br>
<br>
It also makes me a bit uncomfortable with how shared libraries work. The<br>
recent attack demonstrates that a shared library can compromise a<br>
completely unrelated binary. It is a bit unfair to blame systemd here,<br>
it could be a NSS or PAM module that pulls in the compromised<br>
library. Makes me think maybe we need better isolation - but not sure<br>
how you would do this or if it is feasible.<br>
-- <br>
Brian May @ Linux Penguins<br>
_______________________________________________<br>
linux-aus mailing list<br>
<a href="mailto:linux-aus@lists.linux.org.au" target="_blank">linux-aus@lists.linux.org.au</a><br>
<a href="http://lists.linux.org.au/mailman/listinfo/linux-aus" rel="noreferrer" target="_blank">http://lists.linux.org.au/mailman/listinfo/linux-aus</a><br>
<br>
To unsubscribe from this list, send a blank email to<br>
<a href="mailto:linux-aus-unsubscribe@lists.linux.org.au" target="_blank">linux-aus-unsubscribe@lists.linux.org.au</a></blockquote></div></div>