-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release Request #5507
Comments
A new 0.27.1 tag, with the CVE fixed, and a new 0.28.1 tag, with the CVE fixed, would both be great. Thanks! |
Making a new release of mpv will not solve the problem of requiring FFmpeg git master. This is still the case in mpv master. This can only be fixed once FFmpeg makes a new release. In the mean time, distros are welcome to continue using 0.27.0. Anyone who is having difficulty back-porting something they deem critical is welcome to request assistance on #mpv-devel. We are trying to avoid git master dependencies in future releases. |
What exactly is the objection to creating a 0.27.1 tag? |
Indeed. The undertone of my initial comment was essentially recognising that the ship had sailed for 0.28.0 but ideally
Gently putting it, I would hope that the potential for arbitrary code execution is something everyone would deem critical. The discussion on this is largely whether |
Moreover what is the point of numbering your release 0.27.0 if a critical CVE doesn't warrant a 0.27.1, especially when all binary downstreams are on <= 0.27.0: https://repology.org/metapackage/mpv/versions |
Normally, I don't like the "Mommy, can I have a package" crowd, but that's a valid point here. |
Yeah, "Mommy, can I have a package?" is very annoying when it's just about features. Critical CVEs, it's more of a "Mommy, can I please have at least one meal today?" |
Pretty simple to solve, see mpv-build. Other than that,mit's the distro's responsibility to backport fixes or to adapt the source to an outdated version of ffmpeg. I consider it an unacceptable burden to develop against outdated versions of ffmpeg, because that would require us to test with multiple versions of ffmpeg. |
I'm not sure why you're conflating backporting critical CVE fixes to the version your downstreams are actually using with developing against an outdated ffmpeg. |
Because the issue opener complained about that? Distros can either use ffmpeg/mpv git master, which will have all the security fixes, or will have to pick them out yourself. Not sure why you complain about that, because it's the distro's job in the first place. |
I think we have a fundamental disagreement about who is responsible for the security of your software. |
Seems pretty straight forward to me: if we distribute it (git master), it's our responsibility to fix known security bugs (which we do), and if it's the distro distributing older versions, it's the distro's responsibility (and strangely I'm seeing refusal from distros to do the work). I mean, we're seeing requests for 0.27.1 here, and the current release is 0.28.0 (which in my mind is already outdated). the responsibilities seem pretty clear. |
And what is your justification for not tagging 0.28.1 with the fix? |
Back when mpv used to do point-releases, distros would just ignore them, so mpv stopped doing them. Now distros want mpv to do their backporting work for them, which is just all kinds of ass-backwards. You, the distribution, is responsible for the security of the version you ship, not upstream mpv. You could've cherry-picked and backported the commits in the time you've spent arguing here.
@lachs0r could do one, he's the release manager as far as I know. Also, all of you wouldn't even care about this vulnerability if it wasn't assigned a CVE, the way to exploit it is to have someone download malicious code to a known location on their system, and then tell them to open an attacker-controlled URL in mpv. But the security circus claims that this is the most important bugfix mpv has received since 0.27 and MUST BE BACKPORTED BY UPSTREAM RIGHT NOW!!1!!1 |
@CounterPillow you've got your facts a little mixed up. We've already merged Debian's backport to Homebrew. |
That doesn't change the fact that you could've cherry-picked and backported the commits in the time you've spent arguing here. That you needed Debian to do this for you just goes to show how low the barrier for entry is to run a distribution these days. |
@CounterPillow Your abusive behavior is unacceptable. |
I've now shipped 0.27.1 in Homebrew. Thank you, @kevmitch 🙇 |
If you're going to start mouthing off again in future, may I recommend you have at least some basic grip of the facts before doing so. Perhaps that way you wouldn't seem like, at best, a cheap troll.
Thank you @kevmitch. That is appreciated. |
But that's literally true. The backport is trivial, so trivial kevmitch did it for you within a few minutes. I'm sorry to hurt your Homebrew hugbox feelings so much you had to ban me from the org even though I wasn't posting over there this time. If I was just a "cheap troll" you wouldn't keep replying and acting so flustered. |
Sorry for erasing the issue template; I'm aware it's annoying but it doesn't have much relevance to this issue. This is IRT CVE-2018-6360 & #5456.
Homebrew, and indeed other package managers like NixOS, Debian pre-experimental, MacPorts, FreeBSD all seem to be stuck on shipping
mpv
0.27.0 or lower. The logical explanation here, and certainly from Homebrew's point of view, is thatmpv
has chosen to mandate building a stable release ofmpv
against an unstable version offfmpeg
, which is an unacceptable burden for most package managers.Given the severity of #5456 are there plans to release a 0.27.1 that package managers can package without taking on an onerous maintenance burden themselves? FWIW, unless Debian had done the legwork backporting this to 0.27.0 it's unlikely this would've been patched in Homebrew (and likely other package managers) any time soon, leaving a significant chunk of
mpv
users exposed.In an ideal world future stable
mpv
releases would be pegged to stable dependencies, but I'm aware that's a subject that has been clubbed to death more than a few times already.The text was updated successfully, but these errors were encountered: