My previous employer used to donate to the sole maintainer of a php library we used extensively (I'm not a php developer, so I don't remember the name). It wasn't much, but it was something and it is unfortunate that it is not the norm

we should bake something like that in whenever we feel like doing GPLv5 or something.

"free for people, paid for corpos" or something

I agree with this wholeheartedly,

but if you feel about this methodology strongly you're going to get hit with nay-sayers that use the same argument anti-VAT people use, as it's ostensibly the same mechanism: that the developers farthest downstream would have to take the full amount of the percents piled up in their pricing scheme.

Yeah, and when we find cases like this the best thing for the industry would be for a company or two who are very affected (e.g. Red Hat) to step up and offer a trustworthy person payment for maintaining it.

The test case purported to be bad data, which you presumably want to test the correct behaviour of your dearchiver against.

Nothing this did looks to involve memory safety. It uses features like ifunc to hook behaviour.

The notion of reproducible CI is interesting, but there's nothing preventing this setup from repeatedly producing the same output in (say) a debian package build environment.

There are many signatures here that look "obvious" with hindsight, but ultimately this comes down to establishing trust. Technical sophistication aside, this was a very successful attack against that teust foundation.

It's definitely the case that the stack of C tooling for builds (CMakeLists.txt, autotools) makes obfuscating content easier. You might point at modern build tooling like cargo as an alternative - however, build.rs and proc macros are not typically sandboxed at present. I think it'd be possible to replicate the effects of this attack using that tooling.

looking at the official timeline it is not completely a microsoft product, but...

1. microsoft hated all of linux/open source for ages, even publicly called it a cancer etc.
2. microsoft suddenly stopped it's hatespeech after the long-term "ineffectivenes" (as in not destroying) of its actions against the open source world became obvious by time
3. systemd appeared on stage
4. everything within systemd is microsoft style, journald is literally microsoft logging, how services are "managed" started etc is exactly the flawed microsoft service management, how systemd was pushed to distributions is similar to how microsoft pushes things to its victi... eh.. "custumers", systemd breaks its promises like microsoft does (i.e. it has never been a drop-in-replacement, like microsoft claimed its OS to be secure while making actual use of separation of users from admins i.e. by filesystem permissions first "really" in 2007 with the need of an extra click, where unix already used permissions for such protection in 1973), systemd causes chaos and removes the deterministic behaviour from linux distributions (i.e. before systemd windows was the only operating system that would show different errors at different times during installtion on the very same perfectly working hardware, now on systemd distros similar chaos can be observed too). there AFAIK still does not exist a definition of the 'binary" protocol of journald, every normal open source project would have done that official definition in the first place, systemd developers statement was like "we take care for it, just use our libraries" wich is microsoft style saying "use our products", the superflous systems features do harm more than they help (journald's "protection" from log flooding use like 50% cpu cycles for huge amount of wanted and normal logs while a sane logging system would be happily only using 3%cpu for the very same amount of logs/second whilst 'not' throwing away single log lines like journald, thus journald exhaustively and pointlessly abuses system resources for features that do more harm where they are said to help with in the first place), making the init process a network reachable service looks to me like as bad as microsoft once put its web rendering enginge (iis) into kernelspace to be a bit faster but still beeing slower than apache while adding insecurity that later was an abused attack vector. systemd adding pointless dependencies all along the way like microsoft does with its official products to put some force on its customers for whatever official reason they like best. systemd beeing pushed to distributions with a lot of force and damage even to distributions that had this type of freedom of choice to NOT force their users to use a specific init system in its very roots (and the push to place systemd inside of those distros even was pushed furzher to circumvent the unstable->testing->stable rules like microsoft does with its patches i.e.), this list is very far from complete and still no end is in sight.
5. "the" systemd developer is finally officially hired by microsoft

i said that systemd was a microsoft product long before its developer was then hired by microsoft in 2022. And even if he wasn't hired by them, systemd is still a microsoft-style product in every important way with all what is wrong in how microsoft does things wrong, beginning with design flaws, added insecurities and unneeded attack vectors, added performance issues, false promises, usage bugs (like i've never seen an already just logged in user to be directly be logged off in a linux system, except for when systemd wants to stop-start something in background because of it's 'fk y' and where one would 'just try to login again and dont think about it" like with any other of microsofts shitware), ending in insecure and instable systems where one has to "hope" that "the providers" will take care for it without continueing to add even more superflous features, attack vectors etc. as they always did until now.

systemd is in every way i care about a microsoft product. And systemd's attack vectors by "needless dependencies" just have been added to the list of "prooven" (not only predicted) to be as bad as any M$ product in this regard.

I would not go as far to say that this specific attack was done by microsoft itself (how could i ?), but i consider it a possibility given the facts that they once publicly named linux/open source a "cancer" and now their "sudden" change to "support the open source world" looks to me like the poison "Gríma" used on "Théoden" as well as some other observations and interpretations. however i strongly believe that microsoft secretly actually "likes" every single damage any of systemd's pointlessly added dependencies or other flaws could do to linux/open source very much. and why shouldn't they like any damage that was done to any of their obvious opponents (as in money-gain and "dictatorship"-power)? it's a us company, what would one expect?

And if you want to argue that systemd is not "officially" a product of the microsoft company.... well people also say "i googled it" when they mean "i used one of the search engines actually better than google.com" same with other things like "tempo" or "zewa" where i live. since the systemd developer works for microsoft and it seems he works on systemd as part of this work contract, and given all the microsoft style flaws within from the beginning, i consider systemd a product of microsoft. i think systemd overall also "has components" of apple products, but these are IMHO none of technical nature and thus far from beeing part of the discussion here and also apple does not produce "even more systemd" also apple has -as of my experience- very other flaws i did not encounter in systemd (yet?) thus it's clearly not an apple product.