develooper Front page | perl.perl5.porters | Postings from October 2015

Re: What should 'qr/\p{pkg::L}/ ' do?

Thread Previous
Dave Mitchell
October 12, 2015 10:10
Re: What should 'qr/\p{pkg::L}/ ' do?
Message ID:
On Sun, Oct 11, 2015 at 09:58:15PM -0600, Karl Williamson wrote:
> On 10/09/2015 06:08 AM, Abigail wrote:
> >On Fri, Oct 09, 2015 at 07:50:49AM -0400, Ricardo Signes wrote:
> >>* Karl Williamson <> [2015-10-08T10:58:23]
> >>>Currently it evaluates to the Unicode property 'Letter'.
> >>>
> >>>But I think that is the wrong thing to do.
> >>>
> >>>The pkg seems to me to want to force this into a user-defined property.
> >>>Recall that by defining a subroutine, a user can create their own
> >>>properties.  The catch is that their names have to begin with 'In' or 'Is'.
> >>>Therefore, I think that this should be a compile- or run-time failure that
> >>>the property pkg::L is not found.
> >>
> >>I agree, but I wonder whether a "illegal name" wouldn't be better than "Can't
> >>find."  The fix is for the user to rename their &L (if they made one) rather
> >>than to figure out why it can't be found.
> >>
> >>At any rate, acting like L is no good.
> >
> >
> >Is there actually a reason why user-defined properties must start
> >with 'In' or 'Is'? In 5.12, this requirement wasn't enforced, and
> >it "just worked". Considering there are predefined classes starting
> >with "In" and "Is", I can't imagine it's to prevent name clashes.
> I think there was a time when property names had to begin with 'In' and
> 'Is'.  And perhaps this dates from then, and was never updated when the
> restriction was relaxed.  In any event, I was really glad that these were
> the only legal names when we discovered a possible security hole. Dave
> Mitchell used this fact in his fix, but I don't remember the details.
> I would oppose relaxing the restriction, as there is now a better
> alternative that doesn't impose restrictions in doing logical operations on
> component properties, the regex sets feature: qr/(?[...])/.  And I don't see
> the need to do work on a feature that has a better alternative.

My commit which enforced the prefixes was d658a8a81.

The security issue is that /\p{foo::bar}/ would call foo::bar() if it
exists; now people can't call arbitrary functions, but only those prefixed
with In/Is. Which is less bad.

If life gives you lemons, you'll probably develop a citric acid allergy.

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About