FAQ
I'm currently nearing the completion of a patch that (where possible)
adds the variable name to the "Use of uninitialized value" warning, eg

#!/usr/bin/perl -w

my $a;
my @b = (1,undef);
my %c = ('foo' => 1, 'bar' => undef);

my $x = join '', $a, @b, %c;

outputs:

Use of uninitialized value $a in join or string at /tmp/p line 7.
Use of uninitialized value $b[1] in join or string at /tmp/p line 7.
Use of uninitialized value $c{bar} in join or string at /tmp/p line 7.

Which is kinda neat. However...

I'm a bit undecided about the last bit, which prints out the hash key
associated with the undefined hash value; part of me worries that it might
be a security hole, especially in CGI/mod_perl environments. The other
half of me thinks that if a web page is spitting out warnings to the end
user, it's probably broken anyway.

Anyway, some of the options that spring to mind are:

* always display the hash key as is

* ditto, but sanitize it; ie truncate it and escape non-printable chars
(in which case what constitutes non-printable chars in this charset- and
locale-riven world)?

* only display when the key is derived from a constant, eg display it
when the perl source contains $foo{bar} but not $foo{$bar} or %foo

* display unless tainting is enabled

* display unless key is tainted (can a hash key be tainted?)

* never display.

Opinions?

Dave.

--
"Foul and greedy Dwarf - you have eaten the last candle."
-- "Hordes of the Things", BBC Radio.

Search Discussions

  • Nicholas Clark at Mar 22, 2004 at 10:28 pm

    On Mon, Mar 22, 2004 at 10:12:35PM +0000, Dave Mitchell wrote:

    * always display the hash key as is

    * ditto, but sanitize it; ie truncate it and escape non-printable chars
    (in which case what constitutes non-printable chars in this charset- and
    locale-riven world)?
    I'd think that anything outside >126 should be \x notation, anything <32
    should be something else. Presumably there is already to do this. Although
    it does consider characters 160-255 printable, it seems:

    $ perl -we 'foreach (map {chr} 0, 10, 27, 127, 159, 175, 256) {$_ += 1}'
    Argument "\0" isn't numeric in addition (+) at -e line 1.
    Argument "\n" isn't numeric in addition (+) at -e line 1.
    Argument "^[" isn't numeric in addition (+) at -e line 1.
    Argument "^?" isn't numeric in addition (+) at -e line 1.
    Argument "M-^_" isn't numeric in addition (+) at -e line 1.
    Argument "¯" isn't numeric in addition (+) at -e line 1.
    Argument "\x{100}" isn't numeric in addition (+) at -e line 1.

    This will go where the existing warnings go, so I don't see that we're really
    giving that much more away if someone's setup is already configured to leak
    warnings to the user
    * only display when the key is derived from a constant, eg display it
    when the perl source contains $foo{bar} but not $foo{$bar} or %foo

    * display unless tainting is enabled

    * display unless key is tainted (can a hash key be tainted?)
    Not currently. I believe I know how to do this, but I'm loathe to say, given
    that my opinion is that modifying a hash using a tainted key should taint
    the entire hash (ie no need to taint individual keys). This is for another
    thread.

    Nicholas Clark
  • Yitzchak Scott-Thoennes at Mar 22, 2004 at 10:29 pm

    On Mon, Mar 22, 2004 at 10:12:35PM +0000, Dave Mitchell wrote:
    Use of uninitialized value $a in join or string at /tmp/p line 7.
    Use of uninitialized value $b[1] in join or string at /tmp/p line 7.
    Use of uninitialized value $c{bar} in join or string at /tmp/p line 7.

    Which is kinda neat. However...

    I'm a bit undecided about the last bit, which prints out the hash key
    associated with the undefined hash value; part of me worries that it might
    be a security hole, especially in CGI/mod_perl environments. The other
    half of me thinks that if a web page is spitting out warnings to the end
    user, it's probably broken anyway.
    Perhaps even spitting it out to an error log could be considered a
    security hole?
    Anyway, some of the options that spring to mind are:

    * always display the hash key as is

    * ditto, but sanitize it; ie truncate it and escape non-printable chars
    (in which case what constitutes non-printable chars in this charset- and
    locale-riven world)?

    * only display when the key is derived from a constant, eg display it
    when the perl source contains $foo{bar} but not $foo{$bar} or %foo

    * display unless tainting is enabled

    * display unless key is tainted (can a hash key be tainted?)

    * never display.

    Opinions?

    Dave.
    It would be nice if you could make it print $foo{bar} for constants,
    $foo{$bar} where the key is a simple scalar variable, and $foo{EXPR}
    for anything more complicated (or $foo{}?).

    And sanitizing the constant would be good.
  • Rafael Garcia-Suarez at Mar 22, 2004 at 10:36 pm

    Yitzchak Scott-Thoennes wrote:
    I'm a bit undecided about the last bit, which prints out the hash key
    associated with the undefined hash value; part of me worries that it might
    be a security hole, especially in CGI/mod_perl environments. The other
    half of me thinks that if a web page is spitting out warnings to the end
    user, it's probably broken anyway.
    Perhaps even spitting it out to an error log could be considered a
    security hole?
    (have you followed the apache2 development recently?)

    Remember also that variables names may have control chars in it.
    I remember having fixed a couple of places where perl or core modules
    used to report names like $^W or ${^ENCODING} without sanitizing them.

    There must be something in dump.c to print arbitrary strings. It even
    handles UTF-8 :)
    Anyway, some of the options that spring to mind are:

    * always display the hash key as is

    * ditto, but sanitize it; ie truncate it and escape non-printable chars
    (in which case what constitutes non-printable chars in this charset- and
    locale-riven world)?
    I favor this one at first glance.
    The user might want to know which key is undefined in its hash.
    * only display when the key is derived from a constant, eg display it
    when the perl source contains $foo{bar} but not $foo{$bar} or %foo

    * display unless tainting is enabled

    * display unless key is tainted (can a hash key be tainted?)

    * never display.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedMar 22, '04 at 10:11p
activeMar 22, '04 at 10:36p
posts4
users4
websiteperl.org

People

Translate

site design / logo © 2022 Grokbase