It's the nature of Debian however that anything and everything may be packaged while someone is willing to package it and then maintain it.

It is also the nature of Debian that, with very few exceptions, no new versions of "upstream" software are introduced after the "freeze". Note: I'm not defending this model, just explaining the basics of how it works.

Around 15 - 20 years ago, this manifested itself most publicly, in the multitudes of "I want the latest firefox" rant threads. This was where users who were running Debian stable, e.g. 1.5 years into a release, were still at easily a 2 year old firefox release (rebranded to "iceweasel" due to licence and trademark issues).

The obvious answer was to just go to mozilla and download it, but many still complained and felt entitled to the latest version. Unlike the example in this thread, Iceweasel did receive backported security patches, but functionality wise could be 2+ years behind.

This situation is similar - few will be happy with the packaged version, so it is indeed pointless.

To be honest, I believe installing yt-dlp from a distro repository is pointless, on any distro. I don’t get why distros even want to include it in their repositories, because it is such a movable target.

Indeed, this isn't just a Debian/Devuan issue. Virtually every distro has this problem with a subset of its packages.

For something updated as frequently as yt-dlp (or ffmpeg, in my case), I've resorted to using the nightlies when I'm pressed. Even Sid isn't going to be cutting-edge 100% of the time.

If a distro really, really, really wants to provide a way to install yt-dlp through its repositories, then won’t it make more sense to distribute a “yt-dlp installer” or some such, that will download and install the latest yt-dlp whenever it is run? Somewhat akin to the “Adobe Flash installer” that Debian used to have in its repositories? Maybe provide some way to rerun the installer periodically, or to allow the user to easily rerun it manually on request, to keep yt-dlp up-to-date?

In any case, I manually run a bash script to update yt-dlp whenever I want to make sure that my installed copy of yt-dlp is up-to-date; in fact, I do the same to keep deno (“a modern runtime for JavaScript and TypeScript” that is used by yt-dlp) updated as well.

Cannot but agree that you do have a point.

That said, I have not noticed that CVEs get slept on.
From memory (make what you will of that), the CVEs I have read about have usually been solved/worked out in three or four days.

This from using Devuan since ~2017.

Best,

A.

there is a reason why the main webpage is a very very long slog:

https://github.com/yt-dlp/yt-dlp

Not sure where all the hostility is coming from?

I wouldn't call it hostility, but if you write a reply that clearly shows that you didn't read the previous posts in the thread and therefore write incorrect or redundant stuff then don't expect to be also thanked for that.

I'm a Devuan user and this affects Devuan too so I'm writing it here, I have no interest in joining the Debian forum or ML. Also as I suspected there must be Debian Devs keeping an eye on this forum too, as it's too much of a coincidence that they started working on the yt-dlp package for trixie last night a few hours after I started this thread here.

Yep, the latest upstream version, I'm using that right now since I'm no longer using the outdated and insecure packaged Debian version.

This is not about me, as I already wrote I have now moved on to the upstream binaries anyway, it's about all other Debian 13 / Devuan 6 users who use the Debian yt-dlp package and might not even be aware of this CVE.

But if we have to manually install binaries from upstream to avoid security issues then what's the point of a distro?

My main concern now is how many other long known CVEs are there in other Debian packages that have not been fixed yet?

Do I really have to start checking all the packages that I use for known CVEs that Debian hasn't fixed yet?

Does this not make you concerned?

FYI: latest version, as of date of writing this, was released yesterday.

Yes and for anyone supposedly concerned with their security in using it, it is a less than five minute process to upgrade to the latest version like I did last night after seeing this thread. But those that would rather bitch and complain about how hard done by they are by the very busy Debian maintainer not doing it, that is too much of a burden on them. And to top it off the complaint is made in a place that that maintainer is likely never to see.

zeus@9600k:~$ which yt-dlp
/usr/bin/yt-dlp
zeus@9600k:~$ chmod +x /home/zeus/Downloads/yt-dlp_linux
zeus@9600k:~$ mv /home/zeus/Downloads/yt-dlp_linux /home/zeus/bin/yt-dlp
zeus@9600k:~$ which yt-dlp
/home/zeus/bin/yt-dlp
zeus@9600k:~$ yt-dlp -v
[debug] Command-line config: ['-v']
[debug] System config "/etc/yt-dlp.conf": []
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version stable@2026.08.19 from yt-dlp/yt-dlp (linux_exe)
[debug] Python 3.14.7 (CPython x86_64 64bit) - Linux-6.12.101+deb13-amd64-x86_64-with-glibc2.41 (OpenSSL 3.5.7 9 Jun 2026, glibc 2.41)
[debug] exe versions: ffmpeg 7.1.5-0 (setts), ffprobe 7.1.5-0
[debug] Optional libraries: Cryptodome-3.23.0, brotli-1.2.0, certifi-2026.07.22, curl_cffi-0.16.0, mutagen-1.48.1, requests-2.34.2, secretstorage-3.5.0, sqlite3-3.53.4, urllib3-2.7.0, websockets-17.0.1, yt_dlp_ejs-0.8.0
[debug] JS runtimes: none
[debug] Proxy map: {}
[debug] Request Handlers: urllib, requests, websockets, curl_cffi
[debug] Plugin directories: none
[debug] Loaded 1744 extractors

If you don't use those options (--write-link, --write-url-link, or --write-desktop-link), this particular issue won't affect you.  If you do use them, and don't want to check the output files, then by all means, update to a newer version (which is probably necessary anyway for it to work with youtube)

My source of the version info is here: https://tracker.debian.org/pkg/yt-dlp

But there are inconsistencies between the source and binary package versions for stable backports:

https://packages.debian.org/source/trix … rts/yt-dlp
https://packages.debian.org/trixie-backports/yt-dlp

The source is ahead of the binary, which may mean the update is in the works... so yes you're correct that it's still behind for now.

All we know about this particular CVE is that there is no DSA against it and thus no patch. For some reason Debian security aren't in a hurry to fix it.

This isn't the Debian official forum or mailing lists though, so maybe take it up with them using one of those channels? Mailing list is preferred - perhaps search the list first.

Currently, the backports version is the same as the version in unstable, so the solution seems to be to install the bacports version and follow that.

As I said I was already using the version from excalibur backports but that's 2026.03.17, which is not the latest version and it's not the same as unstable which has the latest version (2026.07.04-1), so your statement is simply incorrect.

What nonsense comment, my concern is that debian has a known vulnerable version since more than a month in stable with no security update available, upstream has nothing to do with that.

I don't care whether Debian backports the security patch or the latest version as long as the CVE is fixed, but so far they haven't done either of the two options.

https://www.cvedetails.com/vulnerabilit … oject.html

Currently, the backports version is the same as the version in unstable, so the solution seems to be to install the bacports version and follow that. I thought it was commonly known that, with few exceptions, Debian "freezes" packages at a specific version and any security patches are backported as necessary. So any newer version will never  be available in stable. As it stands, there is no DSA for this as yet. You would have to search the mailing lists / ask the maintainer.

A serious CVE should be a good enough reason to update it.