Projects with bigger problems [LWN.net]

Projects with bigger problems

Posted Apr 28, 2026 12:03 UTC (Tue) by marcH (subscriber, #57642)
In reply to: Projects with bigger problems by farnz
Parent article: Dependency-cooldown discussions warm up

> > Instead, I could write all the functions in my project as dependencies, one function per dependency, so most of the pass-through money would go to me instead of the other project

Rewards lines of code instead of each project equally? You could still game that but it would pretty obvious and look really bad.

With good test coverage tooling you could even reward lines of code actually used, excluding optional features.

> I vendor it and make some licensing compliant changes to make it "my" library.

That one looks pretty easy to detect automatically TBH. If not automatically, at least very obvious to humans.

to post comments

Projects with bigger problems

Posted Apr 28, 2026 13:56 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

Code obfuscation techniques have been a thing for a long time, and are something LLMs are good at (while introducing new bugs, of course).

That makes detecting that "EasyCrypto" is in fact a wrapper around OpenSSL, and not a bunch of carefully written new cryptography code hard - because the obfuscation stops it being obvious. And sure, a detailed inspection by a human will catch this, and it'll be a scandal - but I can just clear off and disappear with my ill-gotten gains.

Projects with bigger problems

Posted Apr 28, 2026 14:08 UTC (Tue) by marcH (subscriber, #57642) [Link] (1 responses)

But a project must have users in the first place to have any gain.

> And sure, a detailed inspection by a human will catch this, and it'll be a scandal - but I can just clear off and disappear with my ill-gotten gains.

This assumes there will be a significant number of users for long enough with NONE noticing anything weird. And no AI check noticing anything either. It's not impossible of course but that seems a bit of stretch. Definitely not "routine" enough to threaten the model as a whole.

Projects with bigger problems

Posted Apr 28, 2026 14:55 UTC (Tue) by farnz (subscriber, #17727) [Link]

If it were genuinely uncommon, then we wouldn't be seeing issues with the supply chain to begin with - people would be noticing weird, and not using it.

The whole reason we're having this discussion is that people motivated by financial gain are attacking F/OSS software sources with the intention of clearing off with their ill-gotten gains - this is just an extra money path for them to take.

Projects with bigger problems

Posted Apr 30, 2026 10:39 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

We really don't want to encourage projects using more lines of code and more verbose programming languages.

Projects with bigger problems

Posted Apr 30, 2026 13:29 UTC (Thu) by marcH (subscriber, #57642) [Link]

Right, splitting across dependencies is not easy. Maybe it could simply be up to each project to value each of their own dependencies. They would be "politics" of course but projects should have the best knowledge. Also, "politics" is not always a bad word: an endangered dependency really difficult to substitute or re-implement could be valued more for no real "technical" reason and that would be OK.