Hi all,
in the monthly meeting that just ended, there was a bit about security patches and their handling; I promised to send a mail elaborating on it further. In short, I believe there are 2 things that can be improved here: - raising the bar on what constitutes a security-critical fix - not mingling security notifications with release procedure The first bit connects directly to the issue that was just fixed, and I'm making the argument that it didn't even deserve this handling. Regular patch procedures would've been just fine. Why? - the issue is in MPLS-VPN handling code, which only a very small number of users use - Quagga can only perform as route reflector in MPLS-VPNs currently, it cannot operate as P or even PE router. - it's only exploitable on a configured bgp session. - in the particular MPLS-VPN use case, that session is in 99.99% of cases an iBGP session. eBGP MPLS-VPN exists but is incredibly rare, especially with Quagga. Further than that, similar logic applies to a lot of bug scenarios in Quagga - most won't be exploitable except by local/"trusted" attackers. The only exception would be CLI, transitive-BGP, or injectable packet exploitable issues. The second bit on not mixing security and release procedures is an entirely independent topic. From my experience, a lot of open source projects -if they have a procedure at all- use a different approach, which works like this: - there's a closed, trusted list of security notification receivers (for Quagga, this would include downstreams, e.g. Debian, RedHat, Cumulus, 6WIND, etc.) - patches are created and sent to that list - there's a first embargo window for downstreams to check into it, possibly distribute updated binary packages (but the patch isn't public yet, which for example means Debian can't do so) - OPTIONAL: patch is released publicly but not announced - OPTIONAL: second embargo time for downstreams to push binaries - patch is sent to mailing list, discussed normally, picked up in normal procedures. It *is* announced as security-critical, but that doesn't imply any short-circuit. - OPTIONAL: if the project does stable releases, that's done. If there is no stable release, that leaves source/non-distro users to apply the patch themselves. - at some later point, a normal release is done. Really doesn't matter. The real argument here is that a security fix is really orthogonal to a release. Intermingling these two not only broke the last Quagga release, it also doesn't work out too well with any kind of downstream advance notification. And, IMHO, the downstream notification is the single most important bit here. If distros fail to pick up the fix, that's game over. So - thoughts? -David _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
