[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [groff] [PATCH] Avoid Perl's unsafe "<>" operator
From: |
Deri |
Subject: |
Re: [groff] [PATCH] Avoid Perl's unsafe "<>" operator |
Date: |
Thu, 24 Jan 2019 15:38:38 +0000 |
On Thursday, 24 January 2019 14:34:35 GMT Colin Watson wrote:
> The "<>" operator is implemented using the two-argument form of "open",
> which interprets magic such as pipe characters, allowing execution of
> arbitrary commands which is unlikely to be expected. Perl >= 5.22 has a
> "<<>>" operator which avoids this, but also forbids the use of "-" to
> mean the standard input, which is a facility that the affected groff
> programs document.
>
> ARGV::readonly would probably also fix this, but I fundamentally dislike
> the approach of escaping data in preparation for a language facility to
> unescape it, especially when the required escaping is as non-obvious as
> it is here. (For the same reason, I prefer to use subprocess invocation
> facilities that allow passing the argument list as a list rather than as
> a string to be interpreted by the shell.) So I've abandoned this
> dubious convenience and changed the affected programs to iterate over
> command-line arguments manually using the three-argument form of open.
>
> This change involves an extra level of indentation, so it's a little
> awkward to review. It consists of changing this form:
>
> while (<>) { # or foreach, which is similar but less efficient
> ...
> }
>
> ... into this:
>
> unshift @ARGV, '-' unless @ARGV;
> foreach my $filename (@ARGV) {
> my $input;
> if ($filename eq '-') {
> $input = \*STDIN;
> } elsif (not open $input, '<', $filename) {
> warn $!;
> next;
> }
> while (<$input>) {
> ...
> }
> }
>
> Local variations: glilypond doesn't need the initial unshift since
> that's already handled in contrib/glilypond/args.pl; gropdf declares
> $input in a slightly different way since it's also used in the LoadAhead
> function.
>
> Fixes: https://bugs.debian.org/920269
Hi Colin,
Have you seen:-
https://savannah.gnu.org/bugs/?55557
Perhaps the patch could be uploaded there?
Cheers
Deri