Re-enable file URLs

[jxu]

Checklist

• I'm asking a question and not reporting a bug/feature request
• I've looked through the README
• I've read the guidelines for opening an issue
• I've searched the bugtracker for similar questions including closed ones

Question

Is it possible to force yt-dlp to read a file with generic extractor like it were a url? I have a RSS XML file and file:// prefix is forbidden, so I used a local python http.server as a workaround.

Verbose log

No response

[pukkandan]

file:// is disabled due to security concerns

so I used a local python http.server as a workaround.

Doesn't that work? (If not, show verbose log) So what is the question again?

[jxu]

Title. How do I get it to read a local podcast XML file? Is that just disabled due to file://

[jxu]

Also I don't see how parsing and downloading from a file on disk is more dangerous than parsing and downloading from some URL online

[coletdjnz]

We could add a switch to enable it (with a warning).

See ytdl-org/youtube-dl#8227 for why it was disabled

Related: ytdl-org/youtube-dl#22408

[jxu]

The limitation does not prevent malicious URLs hosted online and is pretty easy to circumvent with a local server, and shouldn't be an issue if yt-dlp not run with elevated permissions (which it should never need to be). I can open a PR but if you can make a quick fix with like --enable-file-url then that would be nice

[pukkandan]

The limitation does not prevent malicious URLs hosted online and is pretty easy to circumvent with a local server

It does not appear you have understood the problem. Read the linked issues again.

That said, an option to enable it should be fine. PR is welcome

[gamer191]

We could add a switch to enable it (with a warning).

Why would we need a warning? You'd expect a server administrator to be smart enough not to enable it, and afaik it doesn't pose any security risks to regular users (I could be wrong)

[pukkandan]

Why would we need a warning? You'd expect a server administrator to be smart enough not to enable it, and afaik it doesn't pose any security risks to regular users (I could be wrong)

I agree. Passing switches from untrusted sources is already not safe due to --exec and similar. The original issue is a vulnerability because it works with just the URL. As long as the new switch is not enabled by default, there is no issue and no warning is necessary

[gamer191]

afaik it doesn't pose any security risks to regular users (I could be wrong)

Now that I think about it though, I wonder if it would be possible for websites to maliciously gain access to yt-dlp's output. I doubt it, but I'm not 100% sure.

Also, I wonder if this could potentially be a privilege escalation vulnerability (which isn't necessarily enough reason to not do it)

[pukkandan]

Now that I think about it though, I wonder if it would be possible for websites to maliciously gain access to yt-dlp's output. I doubt it, but I'm not 100% sure.

Not sure what you mean here

Also, I wonder if this could potentially be a privilege escalation vulnerability (which isn't necessarily enough reason to not do it)

yt-dlp does not use any low level system APIs. So if any privilege escalation exists, it will because of reasons beyond our control - ie, vulnerability in either the OS or python.

Besides, I don't see how that is relevant here. The file:// protocol was disabled to account for just one specific vulnerability. As I mentioned before, as long as this feature is not enabled by default, that becomes a non-issue

[coletdjnz]

Another workaround for now that doesn't require hosting a server: read the file into a data url (which is supported by yt-dlp)

On bash/zsh you can do:
yt-dlp "data:,$(</path/to/file)"

[coletdjnz]

I have added an option to enable file urls in #2861