Hacker Newsnew | past | comments | ask | show | jobs | submit | simjnd's commentslogin

FFMPEG has consistently expressed their frustration with the fact that there is a large number of people willing and eager to publish vulnerabilities found in the project, but a comparatively minuscule number of people willing to work on patches to fix them.

On the other hand, there's been an endless parade of recent posts from other FOSS maintainers saying "we don't want your drive-by PRs": it's not hard to see people getting dissuaded from the whole dance of determining whether a project is receptive at all, then whether it has a reasonable number of hoops for outsiders to jump through.

Now, personally, when I file a bug report for a FOSS project I like to suggest an underlying cause and fix if I can figure it out, but I more rarely just submit a PR outright.


If I have to choose between no PR and a "drive-by PR" where the author doesn't understand the changes to have a discussion, or isn't available to do changes and expects me to "take it from there", then I'd much rather go with "no PR" for the sake of everyone.

On the third hand, pestering and shaming open-source maintainers because they don't accept your PR is how you get the XZ backdoor situation.

There is a different dynamic between this and that.

Well this is nothing but an obvious expectation given the technical level required for doing good quality contributions, no?

I felt this is kinda like there being a large number of people willing to send spam email, but a comparatively minuscule number of people willing to work on ML filters to block it.


If there are so many vulnerabilities, should not they change approach to development, for example, use memory-safe languages, static analysis, do not use dubious "hacks" that break it?

Memory safety and critical performance rarely go together. Big chunk of FFmpeg is written in assembly to sqweeze most hardware performance.

https://news.ycombinator.com/item?id=43140614


It would be interesting to see the results from a fuzzer, developed for FFmpeg style assembly code.

Sure but it seems like most of these vulnerabilities are being found in the C code.

No. They tried that with coreutils and look what happened. More CVEs.

99% of what I throw though ffmpeg is trusted i.e. I created it. It’s not a major risk.


coreutils was a category error: they took a set of tools which were not very exposed to memory safety errors and rewrote them in a language which does nothing to prevent the kind of logic errors coreutils has suffered from (mostly races around file operations). It’s like complaining that an airbag didn’t save you after driving into a lake.

In contrast, ffmpeg is exactly the sweet spot for a memory-safe language with those complex decoders operating on data which is often untrusted. I wouldn’t suggest a project of that scale lightly but it’s at least a near-perfect fit on the problem domain.


I would say it’s the opposite. coreutils is core utils, you cannot write shell scripts without them, they are widely and almost unavoidably used in trusted environments. They are also relatively simple.

With ffmpeg, anyone who knows anything about secure application development in the past 20 years knows that it is a huge security tarpit and throwing it untrusted inputs in trusted environment is asking to be owned. You thoroughly sandbox that shit. That’s true for all untrusted media conversion, but absolutely with ffmpeg.


My point about coreutils was that they’re rarely used in situations where an attacker can provide arbitrary input - it’s more like race conditions with code already running on the same system trying to escalate access – so what you need to protect against are things like race conditions around file operations or symlink safety.

> you cannot write shell scripts without them, they are widely and almost unavoidably used in trusted environments.

True.

That doesn't make them "very exposed to memory safety errors".


The coreutils rewrite was shit because of the license change. Most of the other founding ideas were also bad as you say, but the license change was absolutely a much worse signal. Just a bunch of people rolling over and showing big corps their belly. And for what? So they can be more exploited by people that treat them like cattle.

Rust does not do "nothing" to prevent logic errors. On the contrary, its strong type system makes them much less likely than in C.

Also security isn't the only reason to prefer Rust to C.

But I do agree ffmpeg would see a much bigger benefit from being written in Rust.


Look, I like Rust and ported every bit of C I used to it a decade ago but this is not a compelling argument. The coreutils rewrite is an existence proof that the typing system doesn’t motivate this class of error and a moment’s thought would explain why (you’d have to be very familiar with the attack patterns to know to create types like “handle to private file failing if the name exists” and they weren’t).

What could help would be a modern API implementing the same patterns that GNU coreutils evolved over the last 4 decades but that’d be less the language than the library and it’d only go so far because some of those utilities legitimately need to things which are otherwise rare in most applications.


In case with coreutils, as I remember, there were mostly race conditions. Not memory safety issues. Maybe we just need better I/O libraries.

Or use a buffer abstraction in C. This is not exactly rocket science. The "this is impossible to prevent in C" nonsense does far more harm than good.

Errors are easily found and corrected for a modest one-person project in C.

But we’re combining probability of error creation (which is effectively constant) and the limits of human cognition.

Some things are impossible at one scale, become possible at another, and become inevitable at yet another.


To be fair, C is a pain to use, so it is better to improve Rust. It is annoying when for example, you have to free several allocated structures when there is an error in the middle of a functon.

I personally like to use C and find Rust annoyingly complex. I think it may be an alternative to C++, but C++ is also too complex for my taste. I do not find it annoying to free several allocated structures when there is an error, but one could also automate this with a often used extension.

There is also the question whether trading memory safety against supply chain risks is really worth it.


Why would it be ideological? There was an AI involved, sure, but your comment ignores the continued disrespect for these volunteers time AND RESOURCES/MONEY (because as the post mentions several times: letting that AI go on could have shut down the whole network exhausting resources at least temporarily).

If you think it's ok to send an agent (or a human) wasting a bunch of people's time and resources, but it's not ok for them to do the same to you then you may have some reflecting to do.


Louis Rossmann's consumer rights wiki has an article about this issue [1].

The TLDR is that support officially ended in 2023, but Microsoft's notice back then assured that the app would keep on working.

That notice has been edited this year to remove the assurance that the app would keep working, with no explanation and redirecting people to the free trial of their subscription offering.

It seems to be due to a Microsoft certificate expiring (in all apps) [2] and causing the app to lose editing capability because no new build of the 2019 suite will be released with an up-to-date certificate.

[1]: https://consumerrights.wiki/w/Microsoft_Office_2019_and_2021...

[2]: https://learn.microsoft.com/en-us/microsoft-365-apps/mac/cer...


> but developed to be [...] integrated in another product that handles documents, for example a file sharing solution, an online wiki, a project management tool and so on

It looks like it only provides the document editing part and you need an app around it to actually open the document from a filesystem and provide its content to this editing interface, and take the output and save it back to the filesystem? (Filesystem, or whatever persistent storage medium)


Sadly the passthrough is black and white only. That's the one thing I love about the Vision Pro is it never feels claustrophobic thanks to very good passthrough quality.

Wow, Steam Frame has only B&W passthrough...[1]

The Quest 3S has color passthrough and it's hardly an Apple-level device, and it's $349 in comparison.

I guess as a gamer, I don't care that much. I put on my headset to game, and if I need to step away for a moment, I'm more likely to take it off than to wander around my house with a headset on. Still, I thought color passthrough was now table stakes for a headset.

[1] https://www.pcgamer.com/hardware/vr-hardware/the-steam-frame...


I think it's not purely unmotivated cost-cutting. They went for IR sensors and have embedded IR LEDs for low-light tracking, and i figure colour passthrough would have required additional cameras.

IIRC there were rumors that the headset would have an open PCIe slot for such things to be added. Presumably they were passed on as defaults for cost reasons.

Not rumors: https://www.theverge.com/games/816118/valve-steam-frame-vr-h...

> The Frame’s four outward-facing monochrome cameras and IR illuminator seem to provide excellent tracking, though in a brief demo, the black-and-white passthrough view wasn’t useful for much except getting a general idea of my surroundings. Rowe says sticking with monochrome passthrough was an intentional choice because color passthrough would have added to the Frame’s price. “The core focus of the device is the gaming,” Rowe says.

> For those who want color passthrough and other changes to the headset, Valve has made its headset modular, including a dedicated expansion port in the nose piece designed to support extra cameras. The expansion port offers 2.5Gbps of bandwidth via MIPI and one lane of PCIe data.


Yes, same. I'll still get one because I think it being a standalone Linux computer is huge, and I'm so interested in the Proton / Lepton stacks to run Windows and Android games but yeah this is a pretty big compromise.

I've switched from OpenRouter to using Deepseek directly from their platform since OpenRouter providers were pretty flaky and inconsistent.

Deepseek V4 Flash is suprisingly capable and insanely cheap. It takes so much to get the session cost to get to $0.01.


Nice, will do this this weekend. Been very impressed with deepseek. Did like 8 hours worth of work after that post and it costs less than $3.

The openrouter provider flakiness with deepseek was infuriating, but I’m happy in hindsight because direct deepseek has been very pleasant. Shocked by how low spend is.

What runs in cloud containers? The dev servers, builds, etc.? I tried to quickly glance at the Claude website and it doesn't mention cloud containers on their pricing page.

The dev environment runs in the cloud. Like devcontainers if you’re familiar with that, except the IDE is just the Claude app.

Having said that, I found the cloud dev environments slow to the point where I wasn’t sure if it had frozen, so I never looked back.


I don't think they were necessarily thinking of one EU-wide agency, but the recent attacks on encryption including Chat Control which almost passed, a lot of EU countries voting for far-right governments. I do believe we still have it better than in the US wrt privacy (e.g. we don't have Flock cameras), but we need to be careful considering what EU governments have been doing.

> EU governments

“European” governments. Non-european governments too.

By definition “not” the EU


Of course, but I'm replying to a comment that speaks like surveillance doesn't exist in the EU because there is not a European NSA, so I'm talking specifically about the EU surveillance risk.

> I'm talking specifically about the EU surveillance risk.

So specifically NOT MI6, GCHQ, the Swiss, Norway, FSB.

Only the members of an economic bloc that you envy.

Okay bro


You will get the features when you're in Japan, and have them for about 2 weeks when back in the EU, then they will be disabled until you leave again.

There is a saying "American trust companies more than their government, Europeans trust their governments more than companies" when nobody should trust either.

Sometimes a company's incentives are going to be aligned with their users, but a lot of the times they won't and consumer protection regulation is useful.

Sometimes a government will have the good of their citizens in mind, and a lot of the times they will seek money and power just like companies do. Lobbies, fines, overreaching regulation.

The UK (and EU's attempted Chat Control) is some fascist bullshit. But allowing you to own the device you paid for and use it as you please (including letting you install whatever software you choose to) isn't.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: