[VOTE] Over-zealous svn commit to Tomcat 6.0

[Christopher Schultz <ch...@christopherschultz.net>]

All,

I recently, forgetting the current RTC policy, made a commit to the
Tomcat 6 trunk without making a proposal. Mark pointed out my mistake
and I'm prepared to revert the patch if necessary.

It is, however, a minor code patch (added a Connector configuration
property alias) and the rest is documentation. You can find the patch
here: http://svn.apache.org/r1521514

In order to avoid a whole round of svn acrobatics (revert, propose,
vote, re-commit), I'd like to ask the committers to vote retrospectively
on my patch. If the vote passes (3+ binding), then I'll consider the
proposal accepted and take no further action. If the vote fails to pass,
I shall revert the patch and make a formal proposal.

The VOTE will remain open for at least 48 hours.

Patch http://svn.apache.org/r1521514 is

[ ] Okay, leave it committed and don't do it again
[ ] Broken, revert and propose an alternate patch
[ ] Committed in violation of the RTC policy, revert and propose

Thanks,
-chris

Re: [VOTE] Over-zealous svn commit to Tomcat 6.0

[Mark Thomas <ma...@apache.org>]

On 10/09/2013 17:23, Christopher Schultz wrote:
> All,
> 
> I recently, forgetting the current RTC policy, made a commit to
> the Tomcat 6 trunk without making a proposal. Mark pointed out my
> mistake and I'm prepared to revert the patch if necessary.
> 
> It is, however, a minor code patch (added a Connector
> configuration property alias) and the rest is documentation. You
> can find the patch here: http://svn.apache.org/r1521514
> 
> In order to avoid a whole round of svn acrobatics (revert,
> propose, vote, re-commit), I'd like to ask the committers to vote
> retrospectively on my patch. If the vote passes (3+ binding), then
> I'll consider the proposal accepted and take no further action. If
> the vote fails to pass, I shall revert the patch and make a formal
> proposal.
> 
> The VOTE will remain open for at least 48 hours.
> 
> Patch http://svn.apache.org/r1521514 is
> 
> [X] Okay, leave it committed and don't do it again [ ] Broken,
> revert and propose an alternate patch [ ] Committed in violation of
> the RTC policy, revert and propose

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [VOTE] Over-zealous svn commit to Tomcat 6.0

[Konstantin Kolinko <kn...@gmail.com>]

2013/9/10 Christopher Schultz <ch...@christopherschultz.net>:
> All,
>
> I recently, forgetting the current RTC policy, made a commit to the
> Tomcat 6 trunk without making a proposal. Mark pointed out my mistake
> and I'm prepared to revert the patch if necessary.
>
> It is, however, a minor code patch (added a Connector configuration
> property alias) and the rest is documentation. You can find the patch
> here: http://svn.apache.org/r1521514
>
> In order to avoid a whole round of svn acrobatics (revert, propose,
> vote, re-commit), I'd like to ask the committers to vote retrospectively
> on my patch. If the vote passes (3+ binding), then I'll consider the
> proposal accepted and take no further action. If the vote fails to pass,
> I shall revert the patch and make a formal proposal.
>
> The VOTE will remain open for at least 48 hours.
>
> Patch http://svn.apache.org/r1521514 is
>
> [x] Okay, leave it committed and don't do it again

but please fix the following in documentation:

1) A typo in attribute name in changelog,
s/ sslEnableProtocols / sslEnabledProtocols /

2) Update documentation for "sslProtocol" attribute, in the same way
as it is in Tomcat 7,
to clarify its relation with sslEnabledProtocols.

It is a bit unusual that instead of documenting the two existing names
for this attribute ("sslProtocols", "protocols") we are introducing
the third one,  but I am OK with this, as this matches Tomcat 7.

I have not tested this new attribute, though.
Looking at JSSESocketFactory I see how the "protocols" attribute works,
but I am not sure how it handles incorrect values.

There was related bug report for Tomcat 7:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54406

>From the code it looks that JSSESocketFactory.getEnabledProtocols(...)
silently swallows incorrect values without any logging and I think
it may result in insecure configuration.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org