On 05/11/2025 00:27, Christopher Schultz wrote:
Mark,
On 11/4/25 2:13 PM, Mark Thomas wrote:
On 04/11/2025 18:41, Christopher Schultz wrote:
Mark,
On 11/4/25 12:42 PM, Mark Thomas wrote:
On 04/11/2025 17:40, [email protected] wrote:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 76c9a625a6abf295444ad2aa23ec9106a5760815
Author: Mark Thomas <[email protected]>
AuthorDate: Tue Nov 4 17:28:12 2025 +0000
Complete the fix for BZ 69852 - align default digest order
with RFC 3112
https://bz.apache.org/bugzilla/show_bug.cgi?id=69852
This isn't the only way to fix this. Before I backport this (likely
first thing my time tomorrow) are there any objections to this
approach / suggestions for a different solution?
Doesn't this patch change the default behavior?
Or was the idea that main would contain a changed-default to be RFC
3112 and the backport would have a default of
digestInRfc3112Order=false?
My plan was to change the default for digestInRfc3112Order to false
for the back-ports and update the back-ported docs to align with that
change.
+1 for me, then.
I'm not sure how many different permutations there are for the ordering,
here. Assuming there is "oops Tomcat legacy" and "RFC 3112" then this is
fine. If there are other possibilities, perhaps we should have a string
configuration option and multiple possible values, rather than just a
boolean. But I suspect the boolean will be fine.
The choices are "salt then credentials" or "credentials then salt".
There are no other options so boolean should be fine.
I think this change is significant enough to warrant an entry on the
"Notable Changes" page, though. Since we don't have a "Notable Changes"
page for Tomcat 12... I'm not sure the best way to communicate this to
users. It's unlikely anyone will remember this change at the time of
Tomcat 12's initial release, unless we review the changelog and pull-out
selected changes for inclusion into that list.
Agreed. And reviewing the changelog and pulling out selected changes is
how I have done it for previous major releases and what I was expecting
to do this time.
Maybe we could have a policy of adding some metadata to the changelog
that indicates a particular item is a "notable change". Even if we have
to manually read it and manually build the "notable changes" list for an
initial release. We could also extract notable changes from the
changelog using that metadata and automatically build the Notable
Changes section if it made any sense. Unfortunately, the format of the
"Notable Changes" differs significantly from the changelog format. We
could make it work if we felt it was helpful enough. At this point, I'm
not sure it is.
Nor me.
Thanks for the review.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
