> What about providing an updated Jetty as an optional module in EPEL? I see we have 9.4.24 in Fedora. This seems like a pretty good example of what I'm saying about fast and slow streams -- we actually _have_ this in our ecosystem already, just not in a consumable way. If it were in EPEL, RHEL or CentOS users who want to strap a nitro-burning sidecar on their semi truck for their use case could do so. [Gregory Young] Providing them to RHEL/CentOS through EPEL is also a good idea, but I would suggest we include the older versions in EPEL as well and mirror the current stable version from EPEL in the CentOS base. This way, people can enable EPEL if they want the older stream (like Jetty 9.2). To be honest, it would be nice to see many of the Fedora packages in EPEL so they can be consumed by EL7 and 8. Even if the newer, less stable versions were available, but not as the default version. As an example, cPanel is currently building an EL7 version of OpenSSL 1.1.1 so they can enable TLS 1.3 on EL7. It would be nice if EL7 had access to the Fedora build of OpenSSL 1.1.1 through EPEL, even of 1.0.2k is the default at this time. I'm all for the defaults being stable versions, but they also need to be secure versions that are at the very least in the security fix supported stage of sunset. Once a third-party package hits EOL and no longer gets security updates, we should be moving to the next or latest stable, supported version as the default, and move the EOL version to EPEL. As the person who also reviews all security reports that come in for our appliance, I know that way too many vulnerability scanners work simply on version matching, and don't actually test for the vulnerability they are flagging. At this point my Support team has a pre-approved response on any OpenSSH vulnerabilities that come in that are version matching, directing our partners to the Red Hat Backporting policy. The issue is the number of cases Support is seeing is climbing as the world becomes more security aware, and nobody seems to be pushing back against these false positives (the vendor isn't going to want to fix them, it makes their report look like it is really good, look at all these vulnerabilities we found!!!). Now I know EL7 isn't going to move to the latest and greatest OpenSSH version, we need to be on a stable version, but at some point, there needs to be the discussion about bumping to the next stable version during a point release. With the lifecycle of the OS, and how fast the security field is changing, I think it warrants jumping to a newer stable release at least once during the lifetime of the OS, and in some cases, even more frequently.