On Thu, Mar 15, 2012 at 5:08 PM, William G. Thompson, Jr. <wgt...@gmail.com>wrote:
> So we all agree that the Ant-pattern approach for Service URL matching > is not working in the way that it is intended and likely deployed. > Actually that is exactly what I did not say. Ant pattern matching is working exactly how ant pattern matching is INTENDED to work. Therefore service url matching is working exactly as its intended to work. If you do not understand that, please read about ant-patterns. What I did say was there is an important use case that we do not support via ant pattern matching, and regular expressions better supports that use case. Therefore, I am in agreement about having support for regular expressions. > Preserving it in 3.5 just doesn't make any sense to me, especially > given that the release strategy dictates that deployers can expect > some amount of upgrade pain. Fortunately for our deployers, more than one voice is considered. It does make sense to me, especially considering it works for many people as is (and at most there is the"catch-all" that doesn't work). Just because we can cause upgrade pain with a 3.5 release doesn't mean we should. The burden of proof is on us, the committers, to show that the intended pain is worth it and that there was no viable alternative. I have not seen that. Adding a few if statements seems infinitely easier than converting all ant patterns to regular expressions right off the bat. > Getting Service URL matching that works > is worth the trouble of having to migrate to RegEx. > This is another inaccurate statement, and I highly recommend you stop making it. Service URL matching *does work* for what ant-patterns support. Forcing everyone to change every one of their patterns to support this additional use case is a dis-service to our deployers. > > Folks on 3.4.x should be notified of the vulnerability and take > appropriate measures now (i.e. don't use wild card URLs). If you're notifying them of a vulnerability in a specific pattern, then please be sure to enumerate all the regular expression patterns that could also be incorrectly used once we support regular expressions. > I'd also > suggest that this could be the workaround until they move to 3.5 with > RegEx support, and thus mitigating the need to cut a 3.4.12. I don't quite understand this. Either its an important issue or its not. If its important enough that it needs to be fixed, then we should cut a 3.4.12 of which Marvin and I have volunteered to port the change. If its not important enough, then there's no reason not to support both patterns. > This > approach is supported by the work that is already completed by Misagh > and is my preferred path. > > Supporting both RegEx and Ant in the way that has been described > requires more work and is a step backwards for the project in my > opinion, but I'm willing to live with it. > However, it's incumbent on > the folks who like to do more to either commit to doing more or allow > the other strategy to proceed. > Actually, unfortunately for you, its not. We're using Apache voting rules: http://www.apache.org/foundation/voting.html#Veto > > Either way this should be resolved before we cut RC1, ideally next Tuesday > 3/20. > > My -1 stands. I've given sufficient and appropriate justification. The onus is on the committer at this point. Cheers, Scott > I'm +1 for Misagh's commit for 3.5 (i.e. drop Ant for RegEx). > > -0 for the alternative RegEx/Ant proposal, assuming someone is going > to step up to do that work. > > Bill > > > On Thu, Mar 15, 2012 at 1:13 PM, Marvin S. Addison > <marvin.addi...@gmail.com> wrote: > >> It helps support an extremely useful Services Management use case of a > >> more general catch-all service versus having more specific catch-alls > for > >> each sub-domain you care about. > > > > > > This is a _vital_ use case for us. > > > > > >> Ant-patterns do not unfortunately support > >> that use case, which can lead to mismatched URLs during ticket > generation > >> if someone attempts to execute such a use case. > > > > > > *shiver* > > I hope everyone that's using catch-all registrations understands the > > implications of this statement. > > > > > >> I have expressed some reservations about an upgrade path for existing > >> deployers if we were to just turn off Ant-pattern matching and turn on > >> RegEx support. I'm starting this thread because I feel we can quickly > >> close the loop on that. > > > > > > The beauty of a backward-compatible solution is that it would be feature > > compatible with a 3.4.12 release. The functionality that regular > > expressions provide are vital for us, so time to release is paramount. > > Additionally, for folks that might want to deploy a solution for security > > reasons in an existing 3.4.x environment, it would be much faster to QA a > > 3.4.12 than 3.5. > > > > > >> Since we expect all Regular Expressions to start with ^ in order to > >> support > >> matching from the beginning, if the internal software detects that "^", > it > >> considers that we're using a regular expression. If it does not detect > >> that, it assumes you're providing an Ant Pattern match. > > > > > > Sounds reasonable to me. Unless someone has a better proposal, I'm a > strong > > +1 to go with this approach, get a working patch with reasonable review, > and > > pull it into master with a subsequent short turnaround for a 3.4.12 > release. > > > > > > M > > > > -- > > You are currently subscribed to cas-dev@lists.jasig.org as: > wgt...@gmail.com > > To unsubscribe, change settings or access archives, see > > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
