←back to thread

798 points bertman | 3 comments | | HN request time: 0.001s | source
Show context
embedding-shape ◴[] No.45900337[source]
Seems its already in Arch's repositories, and seems to work, just add another flag to the invocation:

    yt-dlp --cookies-from-browser firefox --remote-components ejs:github -f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best" 'https://www.youtube.com/watch?v=XXX'
It is downloading a solver at runtime, took maybe half a second in total, downloads are starting way faster than before it seems to me.

    [youtube] [jsc:deno] Solving JS challenges using deno
    [youtube] [jsc:deno] Downloading challenge solver lib script from  https://github.com/yt-dlp/ejs/releases/download/0.3.1/yt.solver.lib.min.js
It would be great if we could download the solver manually with a separate command, before running the download command, as I'm probably not alone in running yt-dlp in a restricted environment, and being able to package it up together with the solver before runtime would let me avoid lessening the restrictions for that environment. Not a huge issue though, happy in general the start of downloads seems much faster now.
replies(8): >>45900780 #>>45901047 #>>45901146 #>>45901292 #>>45902245 #>>45902494 #>>45903312 #>>45906436 #
Wowfunhappy ◴[] No.45901292[source]
What environment are you using that: - Has access to Youtube - Can run Python code - Can’t run JS code

If the concern is security, it sounds like the team went to great lengths to ensure the JS was sandboxed (as long as you’re using Deno).

If you’re using some sort of weird OS or architecture that Deno/Node doesn’t support, you might consider QuickJS, which is written in pure C and should work on anything. (Although it will be a lot slower, I’m not clear just how slow.) Admittedly, you then loose the sandboxing, although IMO it seems like it should safe to trust code being served by Google on the official Youtube domain. (You don’t have to trust Google in general to trust that they won’t serve you actual malware.)

replies(5): >>45902060 #>>45902074 #>>45902207 #>>45902465 #>>45907442 #
dspillett ◴[] No.45902060[source]
> What environment are you using that: - Has access to Youtube - Can run Python code - Can’t run JS code

They didn't say “can't run JS code”, but that from that location the solver could not be downloaded currently. It could be that it is an IPv6-only environment (IIRC youtube supports IPv6 but github does not), or just that all external sites must be assessed before whitelisted (I'm not sure why youtube would be but not github, but it is certainly possible).

replies(2): >>45902260 #>>45903515 #
1. embedding-shape ◴[] No.45902260[source]
It's just me being paranoid after seeing npm/pypi supply chain attacks, and since then I basically run most software touching the internet in a VM one way or another.

I think in this case, my own laziness is what makes it worse than it has to, currently I'm doing whitelisting by domains, so youtube.com for the yt-dlp runner is obviously OK, and I'd want to avoid whitelisting github.com for that, since it's just downloading one JS file.

For now manually copying the config file into my SCM or just whitelisting GitHub for initial download does the trick. I guess I just had to squeeze in one complaint in my previous comment so I could get the HN stamp of approval, can't be too positive.

replies(2): >>45902825 #>>45902886 #
2. j45 ◴[] No.45902825[source]
It's not paranoid, it's more attack surfaces that don't need to be.

Happy to read and learn more about the setups you've found helpful to do this.

3. dspillett ◴[] No.45902886[source]
You could serve the files yourself from a server populated by updating them from github after review. You'd need to either sign the domain with your own CA that the host running yt-dlp trusts, or patch yt-dlp to use a different server name, but neither of those steps should be too onerous.