* There are significant improvements in the gstreamer0.10 branch (which is separately packaged and maintained in Fedora)

Since I've moved my last dependent package off of this old stack, I've retired gstreamer & gstreamer-plugins-base in rawhide (again).

Before reviving these poor and tired packages, please consider the following: * Upstream is not maintaining this code branch anymore. * There are significant improvements in the gstreamer0.10 branch (which is separately packaged and maintained in Fedora)

On Fri, Jan 31, 2020 at 2:47 pm, Dominik 'Rathann' Mierzejewski <dominik(a)greysector.net&gt; wrote: > I'm very well aware of the above, but I'm forced to use some proprietary > software that is linked against gstreamer 0.10, so I need to maintain > these until the software in question gets ported to gstreamer1. gstreamer0.10 has not received security updates -- or security advisories -- since... 2012? I think you should maintain these packages in a copr or other repo outside Fedora.

FESCo is actively trying to remove packages with security issues from the distribution and keeping an ancient multimedia library around is counter to that goal.

On Friday, 31 January 2020 at 14:52, Michael Catanzaro wrote: > On Fri, Jan 31, 2020 at 2:47 pm, Dominik 'Rathann' Mierzejewski > <dominik(a)greysector.net&gt; wrote: >> I'm very well aware of the above, but I'm forced to use some proprietary >> software that is linked against gstreamer 0.10, so I need to maintain >> these until the software in question gets ported to gstreamer1. > > gstreamer0.10 has not received security updates -- or security advisories -- > since... 2012? I think you should maintain these packages in a copr or other > repo outside Fedora. I don't see any bugs open against these components. I can't move them to COPR as then RPM Fusion cannot consume them.

On Fri, Jan 31, 2020 at 2:47 pm, Dominik 'Rathann' Mierzejewski <dominik(a)greysector.net&gt; wrote: > I'm very well aware of the above, but I'm forced to use some > proprietary > software that is linked against gstreamer 0.10, so I need to maintain > these until the software in question gets ported to gstreamer1. gstreamer0.10 has not received security updates -- or security advisories -- since... 2012? I think you should maintain these packages in a copr or other repo outside Fedora. FESCo is actively trying to remove packages with security issues from the distribution and keeping an ancient multimedia library around is counter to that goal.

On Friday, January 31, 2020 7:58:55 AM MST Peter Robinson wrote: > Feankly if a proprietary piece of software hasn't migrated in 8+ years I > would be looking for a replacement. Proprietary software works at the speed of eventually. This is why RHEL maintains compat libraries going back a ridiculous amount of time, and why RHEL 5, for example, is still used today.

On Sunday, February 9, 2020 3:54:51 PM MST Neal Gompa wrote: > On Sun, Feb 9, 2020 at 5:36 PM John M. Harris Jr <johnmh(a)splentity.com&gt; > wrote: > > > > > > On Friday, January 31, 2020 7:58:55 AM MST Peter Robinson wrote: > > > > > Feankly if a proprietary piece of software hasn't migrated in 8+ years > > > I > > > would be looking for a replacement. > > > > > > > > Proprietary software works at the speed of eventually. This is why RHEL > > maintains compat libraries going back a ridiculous amount of time, and > > why > > RHEL 5, for example, is still used today. > > > > > > > At some point, someone has to push to eject button. Speaking from > experience, it's rare that ISVs are willing to be proactive and move > forward as the community does. The difference between FOSS ISVs and > proprietary software ISVs is that the community cannot do anything to > help fix software for the latter. They only move forward when forced to. > > I'm sorry, but it simply does not make sense to keep gstreamer0.10 in > Fedora anymore. I don't say that lightly: the first package I ever > contributed to Fedora was a pygtk2 application using gstreamer0.10 > called oggconvert. But it is dead this days, and I retired it for > Fedora 31. Nobody is caring for these things, and stuff like this is > usually a source of major security issues. > > Even today, those people using RHEL 5 are only *now* moving to RHEL 7 > because it was EOLed three years ago. Folks depending on RHEL 6 who > are slow to move are starting their plans to move to RHEL 8. It is > what it is. But Fedora is not RHEL. Fedora is supposed to be the place > where everything happens first. And if we want RHEL releases without > old, unmaintained stuff, we have to chuck it in Fedora first. I don't know about you, but I'd rather the software keeps working, rather than ceasing to function because a library it depends on is no longer available. As long as it builds and functions, why remove it?

John M. Harris, Jr. Splentity _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

On 10.02.2020 09:43, John M. Harris Jr wrote: > As long as it builds and functions, why remove it? Because it has lots of critical vulnerabilities and endangers end-user devices.

> On Monday, 10 February 2020 at 10:07, Vitaly Zaitsev via devel wrote: > > On 10.02.2020 09:43, John M. Harris Jr wrote: > > > As long as it builds and functions, why remove it? > > > > Because it has lots of critical vulnerabilities and endangers end-user > > devices. > > Please name a couple. Nobody has provided a single specific case of an > unfixed security vulnerability affecting gstreamer 0.10.x yet. CVE-2016-9634, CVE-2016-9635, CVE-2016-9636, CVE-2016-9808, CVE-2016-9807, CVE-2016-9445, CVE-2016-9446, CVE-2016-9447, CVE-2016-9809

> > > > > As long as it builds and functions, why remove it? > > > > > > > > Because it has lots of critical vulnerabilities and endangers > > > > end-user devices. > > > > > > Please name a couple. Nobody has provided a single specific case > > > of an unfixed security vulnerability affecting gstreamer 0.10.x > > > yet. > > > > CVE-2016-9634, CVE-2016-9635, CVE-2016-9636, CVE-2016-9808, > > CVE-2016-9807, CVE-2016-9445, CVE-2016-9446, CVE-2016-9447, > > CVE-2016-9809 > > I asked for unfixed ones. All the above are fixed in RHEL7 and most > are fixed in RHEL6 as well. Also most of them are low impact. So, > where are all the critical ones that are not fixed? What's this got to do with RHEL?

On Tue, Feb 11, 2020 at 10:00 am, Dominik 'Rathann' Mierzejewski <dominik(a)greysector.net&gt; wrote: > It means that the fixes are available and can be applied to Fedora > package if necessary. I'm still waiting for someone to point out a > specific *unfixed* *critical* vulnerability that some of the folks > posting in this thread mentioned. Otherwise, I see no reason to prevent > me or anyone else from keeping gstreamer 0.10 packages alive in Fedora. CVE-2019-9928, buffer overflow in RTSP parsing

Yeah it would be a one-line patch to fix that, but that's not the point. Point is the vast majority of security issues never get CVEs and we rely on regular updates to the latest upstream version to avoid those.

We don't have any problem to retire open source packages that works because they don't move to python 3 for example, but at the same time we hold dead old libraries due to proprietary software. It looks unfair at least