[fulafel]

Debian doesn't have this problem: the security team is collectively responsible for making security updates and frequently creates updated packages without maintainer involvement.

I'm not familiar with the Fedora process, but they seem to have a security team and a system of security advisories, which EPEL does not appear to have. Doesn't sound like the same at all.

Sure, most of the time packages in EPEL (and in Ubuntu universe section) will eventually get security updates, but there is no promise or organization of timely security updates.

[veeti]

EPEL is part of the Fedora project and shares the packaging infrastructure.

[jhasse]

> the security team is collectively responsible for making security updates and frequently creates updated packages without maintainer involvement.

How can they do this if a packaging (and especially backporting) a fix requires deeper knowledge of the package which probably only the maintainer has?

[Ltfe]

Not even the maintainers really understand what they are doing :

https://github.com/g0tmi1k/debian-ssh > There was an #ifndef PURIFY there for a reason. It's because the openssl authors knew that line would cause trouble in a memory debuger like Purify or Valgrind.

Where a debian maintainer screwed the RNG of OpenSSL to make valgrind happy. This made any key generated on a debian or ubuntu system from 2006 to 2008 very easily breakable.

Downstream should never touch packages beyond backporting fixes made by upstream.

Here's another example of upstream vs downstream conflict in debian :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477454

Or PHP developers being fed up with both RedHat and Debian messing with their runtime on whims :

https://derickrethans.nl/distributions-please-dont-cripple-p...

This is why I heavily support the desire for a new packaging system targeted at developers: snaps, flatpak. The downside of having multiple copies of the same libraries pale in comparison to giving back power to upstream. Distro maintainers are routinely modifying codebases they don't understand. Allow us to have a standard installation process that can install packages.. made by the developers themselves, upstream. Just like all other operating systems do.

And Debian, unlike RHEL/CentOS, packages a lot more than they can even reasonably maintain. The vast majority of packages in a Debian stable are insecure, the security team simply cannot handle the large amount of software outside of the truly core stuff (kernel, web servers) :

https://statuscode.ch/2016/02/distribution-packages-consider...

If you aren't supposed to use the packaged wordpress, phpmyadmin or node, why is debian distributing those packages? Debian by distributing these things in their repo encourages the naive first time linux user to install them through their facilities.