xign

The whole point of open source license is that they are a legal document that can be enforced and have legal meaning. It's not just a feel-good article. Your argument is like saying to a client who you are drafting a contract to and say "oh yeah don't worry about the word by word terms in the contract, wink".

Also, this "non-AI" license is plainly not open source nor is it permissive. You can't really say you are a fan of open source when you use a license like this. The whole pt of the MIT license is that you just take it with no strings attached. You can use the software for good or for evil. It's not the license's job to decide.

There is nothing wrong with not liking open source, btw. The largest tech companies in the world all have their most critical software behind closed doors. I just really dislike it when people engage in double-speak and go on this open source clout chasing. This is also why all these hipsters startups (MongoDB, Redis, etc) all ended up enshittifying their open source products IMO, because culturally we are all trying to chase this "we ♥ open source" meme without thinking whether it makes sense.

If people say they "truly love open source", they should mean it.

I can't even reproduce your supposed "issue" regarding the Zig compiler "bug". I have an Apple Silicon Mac and tried your reproducer and zig compiled and ran the program just fine.

Honestly, I really suggest reading up on what self-reflection means. I read through your various PRs, and the fact that you can't even answer why a random author name shows up in your PR means the code can't be trusted. It's not just about attribution (although that's important). It's that it's such a simple thing that you can't even reason through.

You may claim you have written loads of tests, but that means literally nothing. How do you know they are testing the important parts? Also you haven't demonstrated that it "works" other than in the simplest use cases.

Timed disclosure is just a compromise between giving project time and public interests. People have been doing this for years now. Why are people acting like this is new just because ffmpeg is whining?

And occasionally you do see immediate disclosures (see below). This usually happens for vulnerabilities that are time-sensitive or actively being exploited where the user needs to know ASAP. It's very context dependent. In this case I don't think that's the case, so there's a standard delayed disclosure to give courtesy for the project to fix it first.

Note the word "courtesy". The public interest always overrides considerations for the project's fragile ego after some time.

(Some examples of shortened disclosures include Cloudbleed and the aCropalypse cropping bug, where in each case there were immediate reasons to notify the public / users)

Whether the codec is from 1995 or 2025 does not matter. What matters is that the codec is compiled in and working by default on ffmpeg as they intend to bundle all codecs for the user. You can just craft a file, send it to a user pretending to be a regular mp4 file, and trigger the bug. It literally wouldn't matter if the codec was this Lucas Arts one of HEVC. An attacker wouldn't care if they walk in the front door or a random broken window in the back.

But the vulnerability exists already. You are making it sound like Google invented a problem for the project. Maybe the project should be name called if it has hundreds of vulnerabilities? Whether it's run by volunteers or not does not matter for a user of the software.

No one is forcing anyone to do anything. Ffmpeg does not have to fix this bug, btw. If they don't have time, just let the disclosure happen.

Also, in this case, the simple fix is to turn off the codec. They just didn't want to do that because they want to have all codecs enabled. This is a conscious choice and no one is forcing them to do that. If the CVE was allowed to disclose without ffmpeg fixing the issue, at least the downstream users can turn off the codec themselves.

Just to be clear here: Googles' responsibility here is to the public (aka the users of ffmpeg), not the project.

Also, let's go back to your "cooked a meal" analogy. If I cook a meal for you, for free, that's nice. But that doesn't entitle me to be careless in hygiene and gives you salmonella poisoning because I didn't wash my hands. Doing things for free doesn't absolve me of any responsibility.

What makes you think the bad actors aren't already finding these bugs? From the looks of it, there isn't really any rocket science going on here. There are equally well-funded bad actors who will and do find these issues.

With Google finding these bugs, at least the user can be informed. For this instance for example, the core problem here is the codec is in *active use*. Ffmpeg utilizes a disingenuous argument that it's old and obscure, but omits the fact that it's still compiled in meaning that an attacker can craft a file and send it to you and still works.

A user (it could be a distro who packages ffmpeg) can use this information to turn off the codec that virtually no one uses today and make their distribution of ffmpeg more secure. Not having this information means they can't do that.

If ffmpeg doesn't have the resources to fix these bugs, at least let the public know so we can deal with it.

Also, just maybe, they wouldn't have that many vulnerabilities filed against them if the project took security more seriously to begin with? It's not a good sign for the software when you get so many valid security reports and just ask them to withhold them.

Yeah, ffmpeg's responses is really giving me a disingenuous vibe as their argument is completely misleading (and it seems to be working on a decent amount of people who don't try to read further into it). IMO it really damages their reputation in my eyes. If they handled it maturely I think I would have had a bit more respect for them.

As a user this is making me wary of running it tbh.

I'm an open source maintainer and I have never been in a situation where someone filing a security issue will withhold indefinitely, nor would I ever think of asking them to withhold forever. If there are some complications maybe we can discuss a delayed disclosure but ffmpeg is just complaining about the whole concept of delayed disclosures which seems really immature to me.

As a user of ffmpeg I would definitely want to know this kind of information. The responsibility the issue filer has is not to the project, but to the public.

Public disclosures also means users will know about it and distros can turn off said codec downstream. It's not that hard lol. Information is always better. You may also get third-party contributors who will then be motivated to fix the issue. If no one signs up to do so, maybe this codec should just be permanently shelved.

Note that ffmpeg doesn't want to remove the codec because their goal is to play every format known to man, but that's their goal. No one forces them to keep all codecs working.

Except users can act accordingly to work around the vulnerability.

For one, it lets people understand where ffmpeg is at so they can treat it more carefully (e.g. run it in a sandbox).

Ffmpeg is also open source. After public disclosure, distros can choose to turn off said codec downstream to not expose this attack vector. There are a lot of things users can do to protect themselves but they need to be aware of the problem first.

The key point here is: how would a distro know about this vulnerability if Google didn't disclose it? ffmpeg is acting as if Google should have just shut up about it instead of using a well-established timed disclosure mechanism. That means the vulnerability would be private, and downstream users (e.g. distros and individuals) would have no way of knowing said codec is insecure.

I think the answer is pretty simple: ffmpeg is being thin-skinned here. They do care about the vulnerability (despite whining it's an old / obscure format), but they don't want to / have time to fix the issue, and don't want to publicly admit that their software is insecure with lots of attack vectors due to the gazillion codecs they have.

Judging from some online responses I think it's working too. I honestly don't see how ffmpeg's response is remotely acceptable.

What is a dick move is releasing an open source project and then getting mad at people cloning it and then go on a PR blitz to try to destroy said fork. You are basically saying "please take my $100" and then 1 week later accuse them of stealing.

When you make your project open source you are basically inviting people to clone and modify them. If you actually read the terms of MIT and GPL licenses you will realize that they aren't just legal documents but also a social contract telling people it is ok to do so. Otherwise why the F would you make it open source to begin with…?

This matters on a concrete level too. Contributors are much more likely to contribute to open source, so you immediately gain clout and contributors by doing so. So to use such a license and then renegade on the implicit promise is a dick move on the OpenFront's creator's part. Also, note how he keeps referring this to be his game and how it's his copyright? No it isn't. Legally the copyright belongs to each contributor for every bit of code each contributor wrote.

Notice how replies like this never get a response?

Seems like there are multiple ways to address that within the GitHub ecosystem.

For example, you can set up a GitHub Action trigged by `push_request_target` that will call CodeRabbit's API to generate a patch and then push a new commit to the branch. This way CodeRabbit is being polled by a well-defined and minimal action (since this action will have write access to repo) rather than it itself having crazy power to do anything it wants on your repository.

Alternatively, why can't they just comment and propose a patch? GitHub's code review UI allows the human code reviewer to hit a button and incorporate that change into the PR.

There are pros and cons to these other techniques but the clear pro is that it would be more secure.

It just seems like they took the easiest way out rather than thinking it through in typical AI-bro ways.

I don't think you should ever allow dependabot to make direct commits to the repository. The only sane setting (IMO) is that dependabot should just make PRs, and a human needs to verify that and hit merge. My personal opinion is for any serious repositories, allowing a robot to have commit access is often a bad time and ticking time bomb (security-wise).

Now, of course, if there are literally hundreds of dependencies to update every week, then a human isn't really going to go through each and make sure they look good, so that person just becomes a rubber-stamper, which doesn't help the situation. At that point the team should probably seriously evaluate if their tech stack is just utterly broken if they have that many dependencies.

I mean, I think there's a difference between trusting GitHub and trusting third parties. If I can't trust GitHub, then there's absolutely no point in hosting on GitHub or trusting anything in GitHub Actions to begin with.

But yes I do think using tags is problematic. I think for one, GitHub should ban re-tagging. I can't think of a good reason for a maintainer to re-publish a tag to another commit without malicious intent. Otherwise they should provide a syntax to pin to both a tag and a commit, something like this:

`uses: actions/[email protected]@abcdef9876543210`

The action should only work if both conditions are satisfied. This way you can still gain semantics version info (so things like dependabot can work to notify an update) but the commit is still pinned.

---

I do have to say though, these are all just band-aids on top of the actual issue. If you are actually using a dependency that is compromised, someone is going to get screwed. Are you really going to read through the commit and the source code to scan for suspicious stuff? I guess if someone else got screwed before you did they may report it, but it's still fundamentally an issue here. The simple answer is "don't use untrustworthy repositories" but that is hard to guarantee. Only real solution is to use as few dependencies as possible.

I don't trust apps. I trust Apple (enough) that they engineered iOS to have a secure enough sandbox that a random calculator app can't just compromise my phone.

Most developer packages have much higher permission levels because they integrate it with your code without a clear separation of boundaries. This is why attackers now like to attack GitHub Actions because if you get access to secrets you can do a lot of damage.

Because LLM generated mediocre code tends to more buggy with more edge cases and harder to debug that those a good programmer wrote.

With the garbage collection aspect, I do want to point out that eventually people rediscover the benefit of lower level ways to do things and instead come up with improved methods of doing them. See how Rust and Zig have been gaining in popularity for example as a modern alternative to C/C++. As you said, learning how to write in such languages also yield benefits in general as you learn to be more efficient.

Old ideas being new again happens all the time. It's easy to get masked by the new hotness before the disadvantages start to pile up and you need to do a more honest evaluation on the pros and cons of each technique. For example with garbage collection, turns out computers are actually still dog slow today in an absolute sense and squeezing performance is still worth it (people who want to argue otherwise and say "computers are lightning fast", please tell me why a video game cannot render 4K / 120 fps even today, or why an LLM takes months to train with a gazillion GPUs, or why VSCode loads slower than an old copy of Visual Studio on an ancient machine).

I think AI / LLM will probably stick around, but programmers who have become too reliant on them will eventually be filtered out much quicker than people who bother to learn to program well and retain more useful skillsets (even if they end up using LLMs themselves).

That's a future that's not the case today. With compilers, I rarely have to dig into assembly code and generally I just work in the domain (programming languages) that I'm comfortable in. Compiler bugs are rare (but they do exist and I have had to dig into assembly to debug them before).

LLMs are nowhere close to that level today. It spits out a bunch of mediocre code that the programmer then needs to maintain and fix bugs on. And the larger / more complicated the code base the harder it is for the LLM to work with. There's a huge leaky abstraction here going from initial vibe coding to then having to dig into the weeds, and generally fixing bugs written by another human is difficult enough, not to mention written by some random LLM.

I have worked in other large companies that use libcurl and they aren't even listed above. It's pretty much the de facto way to do HTTP requests in C-land unless you really want to write your own backend for some reason. The world still primarily runs on C/C++, not Rust.

No? Adding a Rust backend does not change the API. It just calls into the Rust backend via C bindings. If all you care is ABI stability from the user side none of this would break.

cURL already supports other Rust-written backends as the article pointed out. See https://everything.curl.dev/internals/backends.html.

I think this has to be put against the larger context of Rust… fans that push very hard for the entire world to be rewritten in Rust. Just look at how many Rust projects where their front page / README has the first line as "written in Rust" as if that's the number 1 feature a user should care about. As such I think there was an outsized voice of re-writting cURL in Rust and whatnot as occasionally there will be buffer overflow bugs that admittedly would not have existed if the code in question was written in Rust. That's why there was the experiment to add a new backend using Hyper because in theory they should not be prone to the same class of memory bugs.

As for why not making it the default, the post already made it clear? The new backend did not pass all the tests and therefore could not possibly be the default backend until that was fixed and turned out fixing the last few issues were quite hard. cURL has also supported different backends for a while now. For HTTP/3 for example you can swap out the backend for something else. This is like driving a car. If you literally don't care at all, just use the stock tires/engines and it will drive fine. But sometimes you may care and swap out the stock components for something else that suits your needs, and cURL allows that. cURL / libcurl gives a stable ABI as a glue but it's intentional that you can swap out the backend.

I think usually people like to blame GitHub Action's design, but this repository here seems to have not done the bare minimum in securing itself and more focused on producing a "state-of-the-art (SOTA)" "YOLO" model instead.

There are just a lot of things wrong with just format.yml itself. It honestly seems kind of weird that it needs commit access to push a new commit under the PR author's name/email just to format their code. I personally would find this kind of rude if I'm the PR author as I sign all my Git commits and a bot masquerading as me in submitting a Git commit is not appreciated even for something like code formatting. And of course the author of format.yml didn't seem to know the different between `pull_request` and `pull_request_target` and just threw both in.

I also think these days people go way overboard in CI/CD because things that are automated are obviously better right? I personally do not like any CI pipeline that has the capability to directly commit to the main Git branch without review/signoff (which [this commit](https://github.com/ultralytics/ultralytics/commit/cb260c243f...) did which removed the author check). Things like deploying to PyPI should be more than just a single commit and involves a human. Yes, it introduces a piece of friction to the process, but if you are maintaining a big piece of open source software, a release you made is going to be deployed to lots of people's computers so a little bit of annoyance on the maintainer's side is a small price to pay to make sure you get everything right.

I guess I'm weird. I maintain an OSS macOS app and I see other similar apps just upload their private signing keys to GitHub and just let the CI sign everything for them but I still sign my releases offline and never upload my keys to a public service.

What I'm saying is I don't think we want CI to do everything for us, especially for powerful actions (e.g. making a release) that do not need human approval, and if you do, you should think really hard about whether that's something desired and whether you want to spend the extra mental energy to think about all the security ramifications etc which might just offset the little bits of time you saved.

Ultralytics' README gives me a headache to read lol, for similar reasons you gave. But then the package is called YOLO and the author abbreviated state-of-the-art to SOTA (wat…). It's exactly the kind of "modern" GitHub repository that I like to stay away from lol. My only critique of this README was that it didn't have enough emojis. If you want to truly YOLO, may as well fill half your text with emojis.

This hilariously tech bro optimistic auto-response (made by a bot) from the linked issue (https://github.com/ultralytics/ultralytics/issues/18027#issu...) also gave me a laugh in how out of touch it was with what the issue was.

The reason why this is tricky to do is that websites have custom designs. It's not a trivial problem to make a dark mode version of the design. You can't just flip the colors. There are design work in making sure your design works well in both dark and light modes. Most automatic dark mode solutions don't usually work across the board.

Wasn't there some controversies around this before? I remember there was some talk of why Asahi Lina (anonymous vtuber working on Asahi Linux) can contribute code to Linux. From casual search: https://www.spinics.net/lists/kernel/msg4888830.html

FWIW I like Asahi Lina, just trying to understand the discrepencies

At the same time no one is obligated to use your source code. I think the point here is from now on people (companies and large projects) may be more paranoid about anonymous contributors and refuse to sign off on using code maintained exclusively by them. It's fine for people to stay anonymous, but they just run the risk of not having the credibility for adoption and need to accept that.

But yes, I do trust certain figures like that, e.g. Asahi Lina. It's a fine ambiguous line. But at least in Asahi Linux there are real known human figures and they know who Asahi Lina is.

Personally, I do find it hard to trust an open source project maintained by an anonymous person. (I'm talking about maintainership, not regular contributions that need to be code reviewed by another maintainer) I may toy around with them but I will probably not use them in a manner where I need to trust them continuously.

It's totally cool for you to do whatever you want, since it's a free world after all, but if you want other people to use your code, then it's a two-way street no? Your code has a direct effect on their computers, and so they are placing their trust on you. You may value your privacy, but you need to balance that with other people's valuing their own security, and it's likely that whatever project you maintain may have an alternative as well.

If you just want to commit some code and not have people use them then that's another issue altogether.

I guess what I'm saying is: it's a two-way street. You can do things anonymously, but big companies / projects also don't have an obligation to use your code.