libav: mark as insecure

[dotlambda]

Motivation for this change

closes #90844 and closes #90852 and closes #90839
I didn't list all vulnerabilities under knownVulnerabilities.

Consequences of this change

This disables the following packages:

7 packages removed:
clickshare-csc1 (†01.07.00.033) keyfinder (†2.2) libav (†0.8.21) libav (†11.12) libav (†12.3) vdr-markad (†2017-03-13) vdr-xineliboutput (†2.2.0)

Is there a way to make ofborg ping their maintainers?

For those maintainers: Consider switching to ffmpeg.

• for beets cc @doronbehar @lovesegfault @austinbutler @mweinelt (fixed by updating keyfinder-cli, please test)
• for clickshare-csc1 cc @Yarny0
• for gerbera cc @ardumont
• for guitarix cc @orivej @magnetophon~ (I don't see any dependency on libav/ffmpeg in other distros and the output of the configurePhase)
• for jabref cc @wamserma (doesn't actually depend on libav/ffmpeg)
• for musly cc @ggPeti (fixed by replacing libav with ffmpeg, please test)
• for oraclejdk @lourkeur @Ma27 (fixed in oraclejdk8: remove dependency on libav #111528)
• for signumone-ks cc @WolfangAukang
• for steam cc @Atemu @tadfisher @abbradar @jonringer @danieldk @bbigras @Flakebi @nyanloutre
• for untrunc cc @erikarvstedt @peti (fixed by making it an alias of untrunc-anthwlock)
• for vdr-markad and vdr-xineliboutput cc @ck3d
• for zulu cc @fpletz @yaroot

[erictapen]

Thats a lot of packages to break. Why don't we patch for the vulnerabilities?

[dotlambda]

Thats a lot of packages to break. Why don't we patch for the vulnerabilities?

I guess we could find some patches over at ffmpeg, but wouldn't it be easier to patch everything to use ffmpeg instead?

[vcunat]

I'm not aware of a way to notify them. steam* is certainly used; I'm not sure how important libav is in there and perhaps ffmpeg is perfectly OK.

[dotlambda]

@jtojnar @IvarWithoutBones @prusnak Libav is not in https://github.com/AppImage/pkg2appimage/blob/master/excludelist. Should we just remove it from appimageTools's dependencies or replace it by ffmpeg?

[dotlambda]

Thats a lot of packages to break.

We brought the number down from 74 to 7.

[rycee]

Checked the unpaper change and it is OK. Thanks!

[twhitehead]

My only experience is with the ovito package. I changed libav in the buildInputs to ffmpeg and it built fine, so certainly seems worthwhile trying the same with any of these other packages that people may be using.

[twhitehead]

That's a huge list of CVEs with no hope of being fixed upstream. With ffmpeg being pretty much a drop in replacement, makes sense to start the process of phasing out its usage.

[twhitehead]

The complete list from the links you provided is

CVE-2014-5271
CVE-2015-3395
CVE-2015-5479
CVE-2016-3062
CVE-2016-6832
CVE-2016-7393
CVE-2016-7424
CVE-2016-8675
CVE-2016-8676
CVE-2017-16803
CVE-2017-9051
CVE-2018-11102
CVE-2018-11224
CVE-2018-18826
CVE-2018-18827
CVE-2018-18828
CVE-2018-18829
CVE-2018-19128
CVE-2018-19129
CVE-2018-19130
CVE-2018-20001
CVE-2018-5684
CVE-2018-5766
CVE-2019-14371
CVE-2019-14372
CVE-2019-14441
CVE-2019-14442
CVE-2019-14443
CVE-2019-9717
CVE-2019-9719
CVE-2019-9720

Definitely makes the case that this package should be gone. I guess the thinking then is it isn't really worth the time to lay these all out? I'm okay with that.

[dotlambda]

Alternative suggestion: Just use libav as an alias for ffmpeg and drop the expressions for libav. This will cause some packages not to build which should also catch the maintainers' attention.

[dotlambda]

@erikarvstedt @peti @romildo Can we make untrunc an alias of untrunc-anthwlock?

[romildo]

@erikarvstedt @peti @romildo Can we make untrunc an alias of untrunc-anthwlock?

It is ok for me. untrunc-anthwlock has more features than untrunc.

[WolfangAukang]

#111693 for signumone-ks. Removing libav_0_8

[yaroot]

@dotlambda I don't think zulu should depend on libav or ffmpeg, I've checked all the so files it should be fine to remove them.

[ajs124]

It seems to work for someone #18475 (comment)

[dotlambda]

False positive: #18475 (comment) ;-)

[dotlambda]

@ajs124 Or would say we should keep it anyway? It would defiitely be marked as insecure.

[dotlambda]

Instead of removing it, I now added a commit updating it to version 2.4.

[Yarny0]

Thanks for the notification about clickshare-csc1. Sadly, clickshare won't build with ffmpeg: It needs libswscale.so.2 which is not provided by any of the ffmpeg versions currently in nixpkgs. I suspect it would need a much older ffmpeg version which we no longer package. Sadly, there is no hope for an update of clickshare as the company no longer produces a linux version.

As long as libav_0_8 isn't removed from nixpkgs, it's probably best to leave clickshare as it is. Users are warned about the situation and can decide themselves if they accept the risk of installing a vulnerable package. I don't know of any other solution.

[dotlambda]

Is anything preventing us from merging?

[dotlambda]

backport: #112396