Comment by djoldman
3 months ago
From
https://github.com/yt-dlp/yt-dlp/wiki/EJS
it looks like deno is recommended for these reasons:
> Notes
> * Code is run with restricted permissions (e.g, no file system or network access)
> * Supports downloading EJS script dependencies from npm (--remote-components ejs:npm).
It's fine for this project since google is probably not in the business of triggering exploits in yt-dlp users but please do not use deno sandboxing as a your main security measure to execute untrusted code. Runtime-level sandboxing is always very weak. Relying on OS-level sandboxing or VMs (firecracker & co) is the right way for this.
> It's fine for this project since google is probably not in the business of triggering exploits in yt-dlp
yt-dlp supports a huge list of websites other than youtube
But YouTube is the only one that yt-dlp uses Deno for. No other website on yt-dlp's list has put up enough of a fight to merit an external JS runtime; only YouTube.
From the September announcement:
> The JavaScript runtime requirement will only apply to downloading from YouTube. yt-dlp can still be used without it on the other ~thousand sites it supports
I assumed they only use this setup for youtube, that might be wrong
Is there a full list? I struggled to find one
4 replies →
I would not put it past them. And I'm not sure I trust the yt-dlp team to implement sandboxing securely. The codebase is already full of shortcuts that lead to vulnerabilities like file extension injection.
I mean, this gives me pause:
> Both QuickJS and QuickJS-NG do not fully allow executing files from stdin, so yt-dlp will create temporary files for each EJS script execution. This can theoretically lead to time-of-check to time-of-use (TOCTOU) vulnerabilities.
https://github.com/yt-dlp/yt-dlp/wiki/EJS
TOCTOU from temporary files is a solved problem.
i wonder if it would be legal if they did, as an anti-circumvention counter-measure.
> Runtime-level sandboxing is always very weak. Relying on OS-level sandboxing or VMs (firecracker & co) is the right way for this.
... Isn't the web browser's sandboxing runtime-level?
It used to be 100% runtime-level and it was the golden age of browser exploits. Each of your tabs are now a separate process that the OS sandboxes. They can only access a specific API over IPC for anything that goes beyond js/rendering (cookie management, etc...). An exploit in V8 today only gives access to this API. A second exploit is needed in this API to escape the sandbox and do anything meaningful on the target system.
Yes, but browser sandboxing is an absolute marvel of software design that also cost millions and millions of dollars in developers salaries and CVE bounties to develop. Neither Deno nor yt-dlp have anywhere close to millions of dollars to spend on implementing secure JS sandboxing.
Yes, and it's only reasonably secure because of years of exploits being found and fixed by some of the best (and very well-funded) software security engineers out there.
3 replies →
For a long time, yt-dlp worked completely with Python. They implemented a lightweight JavaScript interpreter that could run basic scripts. But as the runtime requirements became more sophisticated it struggled to scale
As they put it, it was less of an interpreter, and more like 3 regexes in a trench coat.