Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(wontfix?): perl -c executes BEGIN and CHECK blocks #5590

Open
p6rt opened this issue Aug 18, 2016 · 7 comments
Open

(wontfix?): perl -c executes BEGIN and CHECK blocks #5590

p6rt opened this issue Aug 18, 2016 · 7 comments
Labels
RFC Request For Comments

Comments

@p6rt
Copy link

p6rt commented Aug 18, 2016

Migrated from rt.perl.org#128984 (status was 'open')

Searchable as RT128984$

@p6rt
Copy link
Author

p6rt commented Aug 18, 2016

From nxadm@apt-get.be

Hi,

This is more of a post-it note than a real feature request, but here it goes (related with #​128983)

Tools like vim-syntastic and atom use 'perl6-c' (the only valid linter for now) to report syntax errors. Because "perl6 -c" executes code (BEGIN and CHECK blocks as documented), this is a security concern for external code. Because of this, the perl 5 (perl -c) and perl 6 syntax checkers are disabled by default and must be explicitly enabled by the user.

C.

@p6rt
Copy link
Author

p6rt commented Aug 18, 2016

From @geekosaur

On Thu, Aug 18, 2016 at 9​:13 AM, Claudio <perl6-bugs-followup@​perl.org>
wrote​:

Tools like vim-syntastic and atom use 'perl6-c' (the only valid linter for
now) to report syntax errors. Because "perl6 -c" executes code (BEGIN and
CHECK blocks as documented), this is a security concern for external code.

The problem is that you probably can't parse the code successfully if you
can't run BEGIN blocks. While this is currently less true of perl 6 code in
the wild, it's actually even worse in potential than perl 5's ability to
mutate its parser because a module can implement entire new languages.

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

@p6rt
Copy link
Author

p6rt commented Aug 18, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Aug 18, 2016

From @pmichaud

On Thu, Aug 18, 2016 at 10​:38​:57AM -0400, Brandon Allbery wrote​:

On Thu, Aug 18, 2016 at 9​:13 AM, Claudio <perl6-bugs-followup@​perl.org>
wrote​:

Tools like vim-syntastic and atom use 'perl6-c' (the only valid linter for
now) to report syntax errors. Because "perl6 -c" executes code (BEGIN and
CHECK blocks as documented), this is a security concern for external code.

The problem is that you probably can't parse the code successfully if you
can't run BEGIN blocks. While this is currently less true of perl 6 code in
the wild, it's actually even worse in potential than perl 5's ability to
mutate its parser because a module can implement entire new languages.

Also, many things in Perl 6 get executed at BEGIN time even if they're
not explicitly in a BEGIN block. Constant and class declarations come
to mind, but I'm sure there are more.

For example​:

  $ cat xyz.p6
  use v6;
 
  say "1​: mainline";
  constant $a = say "2​: constant";
  BEGIN { say "3​: BEGIN"; }
 
  $ ./perl6 xyz.p6
  2​: constant
  3​: BEGIN
  1​: mainline

Pm

@p6rt
Copy link
Author

p6rt commented Aug 18, 2016

From nxadm@apt-get.be

On Thu, Aug 18, 2016 at 6​:21 PM, Patrick R. Michaud via RT <
perl6-bugs-followup@​perl.org> wrote​:

On Thu, Aug 18, 2016 at 10​:38​:57AM -0400, Brandon Allbery wrote​:

On Thu, Aug 18, 2016 at 9​:13 AM, Claudio <perl6-bugs-followup@​perl.org>
wrote​:

Tools like vim-syntastic and atom use 'perl6-c' (the only valid linter
for
now) to report syntax errors. Because "perl6 -c" executes code (BEGIN
and
CHECK blocks as documented), this is a security concern for external
code.

The problem is that you probably can't parse the code successfully if you
can't run BEGIN blocks. While this is currently less true of perl 6 code
in
the wild, it's actually even worse in potential than perl 5's ability to
mutate its parser because a module can implement entire new languages.

Also, many things in Perl 6 get executed at BEGIN time even if they're
not explicitly in a BEGIN block. Constant and class declarations come
to mind, but I'm sure there are more.

For example​:

$ cat xyz.p6
use v6;

say "1​: mainline";
constant $a = say "2​: constant";
BEGIN { say "3​: BEGIN"; }

$ ./perl6 xyz.p6
2​: constant
3​: BEGIN
1​: mainline

Patrick,

Taking Brandon's answer in considiration, does this mean that no perl6 code
could be parsed as correct without (implicit) BEGIN blocks or that it will
only work in -let's say- 99% of the time (file without a begin block)?

C.

@p6rt
Copy link
Author

p6rt commented Aug 18, 2016

From @geekosaur

On Thu, Aug 18, 2016 at 6​:18 PM, Claudio <nxadm@​apt-get.be> wrote​:

Taking Brandon's answer in considiration, does this mean that no perl6
code could be parsed as correct without (implicit) BEGIN blocks or that it
will only work in -let's say- 99% of the time (file without a begin block)?

I did say "while this is less true for perl 6 code in the wild" --- in perl
5, disabling BEGIN blocks means losing all "use" directives. But for perl
6, you still have to worry about classes not being defined properly because
their definitions are run (!) at compile time.

--
brandon s allbery kf8nh sine nomine associates
allbery.b@​gmail.com ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

@p6rt
Copy link
Author

p6rt commented Aug 20, 2016

From nxadm@apt-get.be

Thank you for the clarification. That means that at the moment, most files
(i.e. the ones written in OO) will have a have errors without a BEGIN block
(i.e. the use of self).

As 'perl6 -c' being for now the *only* way to check the syntax of a code
file, the security concerns should not be easily disregarded. In the best
case, users will have to jump through loops to have the functionality
enabled 'at their own risk', in the worst case people will blame Perl 6 for
stupid/dangerous done to their environment while "reading a code file with
their editor".

I am just thinking out loud, but could a different restricted core binary
with only a subset of the code provide the necessary parsing capabilities?
An alternative could be external tools implementing the parsing/linting of
code (maybe something using DrForr's future Perl6​::Tidy?), but in that case
we would risk to have something playing catch-up to new Perl 6 releases.

C.

On Fri, Aug 19, 2016 at 1​:25 AM, Brandon Allbery via RT <
perl6-bugs-followup@​perl.org> wrote​:

On Thu, Aug 18, 2016 at 6​:18 PM, Claudio <nxadm@​apt-get.be> wrote​:

Taking Brandon's answer in considiration, does this mean that no perl6
code could be parsed as correct without (implicit) BEGIN blocks or that
it
will only work in -let's say- 99% of the time (file without a begin
block)?

I did say "while this is less true for perl 6 code in the wild" --- in perl
5, disabling BEGIN blocks means losing all "use" directives. But for perl
6, you still have to worry about classes not being defined properly because
their definitions are run (!) at compile time.

--
brandon s allbery kf8nh sine nomine
associates
allbery.b@​gmail.com
ballbery@​sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad
http://sinenomine.net

@p6rt p6rt added the RFC Request For Comments label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request For Comments
Projects
None yet
Development

No branches or pull requests

1 participant