Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
xign
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
1.
▲
by
xign
8mo ago
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
2.
▲
by
xign
10mo ago
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
3.
▲
by
xign
10mo ago
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
4.
▲
by
xign
10mo ago
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
5.
▲
by
xign
10mo ago
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 n
6.
▲
by
xign
10mo ago
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 Goo
7.
▲
by
xign
10mo ago
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 the
8.
▲
by
xign
10mo ago
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 ca
9.
▲
by
xign
10mo ago
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 th
10.
▲
by
xign
10mo ago
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, di
11.
▲
by
xign
10mo ago
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
12.
▲
by
xign
10mo ago
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&
13.
▲
by
xign
1y ago
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 t
14.
▲
by
xign
1y ago
Notice how replies like this never get a response?
15.
▲
by
xign
1y ago
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
16.
▲
by
xign
2y ago
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 an
17.
▲
by
xign
2y ago
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
18.
▲
by
xign
2y ago
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 th
19.
▲
by
xign
2y ago
Because LLM generated mediocre code tends to more buggy with more edge cases and harder to debug that those a good programmer wrote.
20.
▲
by
xign
2y ago
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 pop
21.
▲
by
xign
2y ago
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 e
22.
▲
by
xign
2y ago
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
23.
▲
by
xign
2y ago
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 ar
24.
▲
by
xign
2y ago
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 "writt
25.
▲
by
xign
2y ago
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
26.
▲
by
xign
2y ago
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
27.
▲
by
xign
2y ago
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
28.
▲
by
xign
2y ago
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/li
29.
▲
by
xign
2y ago
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 excl
30.
▲
by
xign
2y ago
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 th
More ›