Most of them involve very weird and unlikely scenarios and bad security practices or access to the ffmpeg binaries and being allowed to run arbitrary commands at an elevated permission.

In and of itself there's not a massive issue from what I can see, they're entry vectors that can lead to worse situations.

That's not to say they're not serious but if a Russian hacking group is using one of them it's in conjunction with other exploits or security flaws. Which is common in practice when it comes to decoding.

Yeah, then you need to stream content in real time between multiple processes. And not screw up the licensing.

And get hardware acceleration working...

Speed and security are not good bedfellows. Combine that with really shitty standards and dozens of years of development...

Oh, and licensing. Licensing is the real killer. I could just write my own mp3 decoder easily (the format not the file type) but I'm not gonna risk my company getting sued into the ground by doing that.

    > I could just write my own mp3 decoder easily (the format not the file type) but I'm not gonna risk my company getting sued into the ground by doing that.

I am confused.

    > The MP3 format is now patent-free and requires no licensing fees to distribute or use. Fraunhofer IIS and Technicolor officially terminated their MP3 licensing programs, with all core patents having expired. Anyone can encode, decode, and distribute MP3 files or software without paying royalties.

Ref: https://forum.gamemaker.io/index.php?threads/do-you-still-ha...

Ref: https://www.reddit.com/r/gamedev/comments/5stq8z/mp3_licensi...

Ref: https://www.audioblog.iis.fraunhofer.com/mp3-software-patent...

Sorry I was painting a broad image. I'm also worried about copyright infringement, discovery, someone switching to a different different that requires glpl, etc

You raise a good point. You can substitute "MP3" with any patent-/copyright-/license-laden important media codec and you will face the same issues. Your comment would be very timely in the year 2005, when MP3 licensing was a serious issue for game devs.

I don’t think this is necessarily true! Constraints can be liberating: a language that allows strong encoding of invariants makes it easier for the language’s compiler to optimize.

I agree about long periods of development and difficult standards, though.

Forcing developers to consider and more is harmful though. You're arguing to put all of the forethought upfront, when you have the least context and least understanding of what can go wrong, and carrying that complexity forward rather than starting simple and refactoring over time.

I was also able to set this up entirely with a web interface.

So I've got a foot in each camp, I think you're just using different languages - you guys mean different things with the same words.

You can't claim he doesn't know what he's talking about with a single point he may have gotten run, the makes a tonne of valid points, especially around the existing problems of C++ that this library doesn't help with.

In addition to that, he's not wrong about this library from a user perspective. I can't use this. I wrote something very similar back in 2016 - at the time it served my needs but now it's hilariously outdated.

To be honest Rust has the exact same supply chain attack pattern - it's just newer and more maintained at the moment. Give it a decade.

Programs in Rust (or almost every other language) normally have fewer dependencies by 2 or 3 orders of magnitude.

And that number tends to reduce even more when the ecosystem matures.

It may be fewer but it still doesn't feel good when cargo pulls in hundreds of deps for a seemingly simple application. But maybe it seems simple because of all the deps...

Agreed, but that's the reason why it keeps being a huge problem in JS while other languages only have an eventual small trouble.

But also, almost all of those deps on all simple apps are the same in Rust. They are the same for a large part in JS too, but it's for a smaller part than on most languages.

This; even Golang for medium sized projects (NNCP, Yggdrasil) have about 8-10 deps on average. Rust's dependency chain it's unmanageable for a distro manager.

From Golang the Rust dependency size it's closer to NPM than Go.

Supply chain attacks are available to every language and framework that uses dependencies or modules you don’t control.

Yea I’m a big fan of rust but it does feel uncomfortable to see my dependency blowing up to the hundreds when I build

There is build.rs, proc macros are unsandboxed, and lastly you install the binary so that you can run it. Even if the build and install were fully sandboxed, the binary could still do malicious stuff if ran.

Even without post-install script, a malicious payload could be hiding in some function and just wait until the developer invokes `cargo run`. Not that many people audit the crates they pull into their projects.

Yeah no shit, if you download malicious code from the internet and run it on your computer you will get pwned. No matter if it’s from a package manager a zip file or a submodule.

However the current npm vulns used a post install script.

I maintain that NPM malware use postinstall scripts just because they exist and are convenient. Had NPM not had postinstall scripts, the malware would have used a different mechanism and been almost exactly as effective.

It has build.rs that will run as soon as you compile the dependency. That's not the same thing but pretty close to a post install script: it's very likely to run.

They have build.rs (https://doc.rust-lang.org/cargo/reference/build-scripts.html)

It has build.rs, which has essentially the same problems.

Is it? It's kind of the heart of the matter - just because something is common doesn't mean it's acceptable. The difference is that in our society we've all agreed the sacrificing is no longer acceptable.