Le 8/12/2016 à 11:49, Mark Thomas a écrit : > Added.
Thank you Mark. > The commits on the security pages are meant to be just those required to > fix the vulnerability. > > Back-porters may need additional commits for various reasons: > a) prior commits that aligned the code with later versions prior to the > security fix being applied > b) commits that create new configuration options to provide work-arounds > for side-effects of security fixes > c) commits that address regressions caused by security fixes. > to name the first few that come to mind. > > I'm +0.5 on including those under c) above although I wonder if we > should differentiate them on the security pages somehow. I'm not > convinced that a), b) or any others should be included. I agree a) is clearly out of scope for the security pages, and we already add the missing classes or methods required to backport the changes. b) is nice to have to preserve a strict backward compatibility, however if the behavior change has only minor or easily mitigable effects, I'd understand they are left out. c) on the other hand is very important, otherwise the security fix is guaranteed to break systems in production (and unfortunately it happened with CVE-2016-6797 and CVE-2016-5018). I'd like to add that I'm really grateful that the security pages exist and have such a level of detail, I haven't seen many OSS projects doing this. Without them it would be quite challenging to maintain a stable version of Tomcat in Debian (and probably in other distributions). So thank you very much. Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
