Adding upstream version 4.22.0.upstream/4.22.0

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 673 insertions, 0 deletions

diff --git a/upstream/mageia-cauldron/man1/perlsec.1 b/upstream/mageia-cauldron/man1/perlsec.1
new file mode 100644
index 00000000..08d811b4
--- /dev/null
+++ b/upstream/mageia-cauldron/man1/perlsec.1
@@ -0,0 +1,673 @@
+.\" -*- mode: troff; coding: utf-8 -*-
+.\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
+.ie n \{\
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is >0, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{\
+.    if \nF \{\
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{\
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\" ========================================================================
+.\"
+.IX Title "PERLSEC 1"
+.TH PERLSEC 1 2023-11-28 "perl v5.38.2" "Perl Programmers Reference Guide"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH NAME
+perlsec \- Perl security
+.SH DESCRIPTION
+.IX Header "DESCRIPTION"
+Perl is designed to make it easy to program securely even when running
+with extra privileges, like setuid or setgid programs.  Unlike most
+command line shells, which are based on multiple substitution passes on
+each line of the script, Perl uses a more conventional evaluation scheme
+with fewer hidden snags.  Additionally, because the language has more
+builtin functionality, it can rely less upon external (and possibly
+untrustworthy) programs to accomplish its purposes.
+.SH "SECURITY VULNERABILITY CONTACT INFORMATION"
+.IX Header "SECURITY VULNERABILITY CONTACT INFORMATION"
+If you believe you have found a security vulnerability in the Perl
+interpreter or modules maintained in the core Perl codebase,
+email the details to
+perl\-security@perl.org <mailto:perl-security@perl.org>.
+This address is a closed membership mailing list monitored by the Perl
+security team.
+.PP
+See perlsecpolicy for additional information.
+.SH "SECURITY MECHANISMS AND CONCERNS"
+.IX Header "SECURITY MECHANISMS AND CONCERNS"
+.SS "Taint mode"
+.IX Subsection "Taint mode"
+By default,
+Perl automatically enables a set of special security checks, called \fItaint
+mode\fR, when it detects its program running with differing real and effective
+user or group IDs.  The setuid bit in Unix permissions is mode 04000, the
+setgid bit mode 02000; either or both may be set.  You can also enable taint
+mode explicitly by using the \fB\-T\fR command line flag.  This flag is
+\&\fIstrongly\fR suggested for server programs and any program run on behalf of
+someone else, such as a CGI script.  Once taint mode is on, it's on for
+the remainder of your script.
+.PP
+While in this mode, Perl takes special precautions called \fItaint
+checks\fR to prevent both obvious and subtle traps.  Some of these checks
+are reasonably simple, such as verifying that path directories aren't
+writable by others; careful programmers have always used checks like
+these.  Other checks, however, are best supported by the language itself,
+and it is these checks especially that contribute to making a set-id Perl
+program more secure than the corresponding C program.
+.PP
+You may not use data derived from outside your program to affect
+something else outside your program\-\-at least, not by accident.  All
+command line arguments, environment variables, locale information (see
+perllocale), results of certain system calls (\f(CWreaddir()\fR,
+\&\f(CWreadlink()\fR, the variable of \f(CWshmread()\fR, the messages returned by
+\&\f(CWmsgrcv()\fR, the password, gcos and shell fields returned by the
+\&\f(CWgetpwxxx()\fR calls), and all file input are marked as "tainted".
+Tainted data may not be used directly or indirectly in any command
+that invokes a sub-shell, nor in any command that modifies files,
+directories, or processes, \fBwith the following exceptions\fR:
+.PP
+Support for taint checks adds an overhead to all Perl programs,
+whether or not you're using the taint features.
+Perl 5.18 introduced C preprocessor symbols that can
+be used to disable the taint features.
+.IP \(bu 4
+Arguments to \f(CW\*(C`print\*(C'\fR and \f(CW\*(C`syswrite\*(C'\fR are \fBnot\fR checked for taintedness.
+.IP \(bu 4
+Symbolic methods
+.Sp
+.Vb 1
+\&    $obj\->$method(@args);
+.Ve
+.Sp
+and symbolic sub references
+.Sp
+.Vb 2
+\&    &{$foo}(@args);
+\&    $foo\->(@args);
+.Ve
+.Sp
+are not checked for taintedness.  This requires extra carefulness
+unless you want external data to affect your control flow.  Unless
+you carefully limit what these symbolic values are, people are able
+to call functions \fBoutside\fR your Perl code, such as POSIX::system,
+in which case they are able to run arbitrary external code.
+.IP \(bu 4
+Hash keys are \fBnever\fR tainted.
+.PP
+For efficiency reasons, Perl takes a conservative view of
+whether data is tainted.  If an expression contains tainted data,
+any subexpression may be considered tainted, even if the value
+of the subexpression is not itself affected by the tainted data.
+.PP
+Because taintedness is associated with each scalar value, some
+elements of an array or hash can be tainted and others not.
+The keys of a hash are \fBnever\fR tainted.
+.PP
+For example:
+.PP
+.Vb 8
+\&    $arg = shift;               # $arg is tainted
+\&    $hid = $arg . \*(Aqbar\*(Aq;        # $hid is also tainted
+\&    $line = <>;                 # Tainted
+\&    $line = <STDIN>;            # Also tainted
+\&    open FOO, "/home/me/bar" or die $!;
+\&    $line = <FOO>;              # Still tainted
+\&    $path = $ENV{\*(AqPATH\*(Aq};       # Tainted, but see below
+\&    $data = \*(Aqabc\*(Aq;              # Not tainted
+\&
+\&    system "echo $arg";         # Insecure
+\&    system "/bin/echo", $arg;   # Considered insecure
+\&                                # (Perl doesn\*(Aqt know about /bin/echo)
+\&    system "echo $hid";         # Insecure
+\&    system "echo $data";        # Insecure until PATH set
+\&
+\&    $path = $ENV{\*(AqPATH\*(Aq};       # $path now tainted
+\&
+\&    $ENV{\*(AqPATH\*(Aq} = \*(Aq/bin:/usr/bin\*(Aq;
+\&    delete @ENV{\*(AqIFS\*(Aq, \*(AqCDPATH\*(Aq, \*(AqENV\*(Aq, \*(AqBASH_ENV\*(Aq};
+\&
+\&    $path = $ENV{\*(AqPATH\*(Aq};       # $path now NOT tainted
+\&    system "echo $data";        # Is secure now!
+\&
+\&    open(FOO, "< $arg");        # OK \- read\-only file
+\&    open(FOO, "> $arg");        # Not OK \- trying to write
+\&
+\&    open(FOO,"echo $arg|");     # Not OK
+\&    open(FOO,"\-|")
+\&        or exec \*(Aqecho\*(Aq, $arg;   # Also not OK
+\&
+\&    $shout = \`echo $arg\`;       # Insecure, $shout now tainted
+\&
+\&    unlink $data, $arg;         # Insecure
+\&    umask $arg;                 # Insecure
+\&
+\&    exec "echo $arg";           # Insecure
+\&    exec "echo", $arg;          # Insecure
+\&    exec "sh", \*(Aq\-c\*(Aq, $arg;      # Very insecure!
+\&
+\&    @files = <*.c>;             # insecure (uses readdir() or similar)
+\&    @files = glob(\*(Aq*.c\*(Aq);       # insecure (uses readdir() or similar)
+\&
+\&    # In either case, the results of glob are tainted, since the list of
+\&    # filenames comes from outside of the program.
+\&
+\&    $bad = ($arg, 23);          # $bad will be tainted
+\&    $arg, \`true\`;               # Insecure (although it isn\*(Aqt really)
+.Ve
+.PP
+If you try to do something insecure, you will get a fatal error saying
+something like "Insecure dependency" or "Insecure \f(CW$ENV\fR{PATH}".
+.PP
+The exception to the principle of "one tainted value taints the whole
+expression" is with the ternary conditional operator \f(CW\*(C`?:\*(C'\fR.  Since code
+with a ternary conditional
+.PP
+.Vb 1
+\&    $result = $tainted_value ? "Untainted" : "Also untainted";
+.Ve
+.PP
+is effectively
+.PP
+.Vb 5
+\&    if ( $tainted_value ) {
+\&        $result = "Untainted";
+\&    } else {
+\&        $result = "Also untainted";
+\&    }
+.Ve
+.PP
+it doesn't make sense for \f(CW$result\fR to be tainted.
+.SS "Laundering and Detecting Tainted Data"
+.IX Subsection "Laundering and Detecting Tainted Data"
+To test whether a variable contains tainted data, and whose use would
+thus trigger an "Insecure dependency" message, you can use the
+\&\f(CWtainted()\fR function of the Scalar::Util module, available in your
+nearby CPAN mirror, and included in Perl starting from the release 5.8.0.
+Or you may be able to use the following \f(CWis_tainted()\fR function.
+.PP
+.Vb 4
+\&    sub is_tainted {
+\&        local $@;   # Don\*(Aqt pollute caller\*(Aqs value.
+\&        return ! eval { eval("#" . substr(join("", @_), 0, 0)); 1 };
+\&    }
+.Ve
+.PP
+This function makes use of the fact that the presence of tainted data
+anywhere within an expression renders the entire expression tainted.  It
+would be inefficient for every operator to test every argument for
+taintedness.  Instead, the slightly more efficient and conservative
+approach is used that if any tainted value has been accessed within the
+same expression, the whole expression is considered tainted.
+.PP
+But testing for taintedness gets you only so far.  Sometimes you have just
+to clear your data's taintedness.  Values may be untainted by using them
+as keys in a hash; otherwise the only way to bypass the tainting
+mechanism is by referencing subpatterns from a regular expression match.
+Perl presumes that if you reference a substring using \f(CW$1\fR, \f(CW$2\fR, etc. in a
+non-tainting pattern, that
+you knew what you were doing when you wrote that pattern.  That means using
+a bit of thought\-\-don't just blindly untaint anything, or you defeat the
+entire mechanism.  It's better to verify that the variable has only good
+characters (for certain values of "good") rather than checking whether it
+has any bad characters.  That's because it's far too easy to miss bad
+characters that you never thought of.
+.PP
+Here's a test to make sure that the data contains nothing but "word"
+characters (alphabetics, numerics, and underscores), a hyphen, an at sign,
+or a dot.
+.PP
+.Vb 5
+\&    if ($data =~ /^([\-\e@\ew.]+)$/) {
+\&        $data = $1;                     # $data now untainted
+\&    } else {
+\&        die "Bad data in \*(Aq$data\*(Aq";      # log this somewhere
+\&    }
+.Ve
+.PP
+This is fairly secure because \f(CW\*(C`/\ew+/\*(C'\fR doesn't normally match shell
+metacharacters, nor are dot, dash, or at going to mean something special
+to the shell.  Use of \f(CW\*(C`/.+/\*(C'\fR would have been insecure in theory because
+it lets everything through, but Perl doesn't check for that.  The lesson
+is that when untainting, you must be exceedingly careful with your patterns.
+Laundering data using regular expression is the \fIonly\fR mechanism for
+untainting dirty data, unless you use the strategy detailed below to fork
+a child of lesser privilege.
+.PP
+The example does not untaint \f(CW$data\fR if \f(CW\*(C`use locale\*(C'\fR is in effect,
+because the characters matched by \f(CW\*(C`\ew\*(C'\fR are determined by the locale.
+Perl considers that locale definitions are untrustworthy because they
+contain data from outside the program.  If you are writing a
+locale-aware program, and want to launder data with a regular expression
+containing \f(CW\*(C`\ew\*(C'\fR, put \f(CW\*(C`no locale\*(C'\fR ahead of the expression in the same
+block.  See "SECURITY" in perllocale for further discussion and examples.
+.SS "Switches On the ""#!"" Line"
+.IX Subsection "Switches On the ""#!"" Line"
+When you make a script executable, in order to make it usable as a
+command, the system will pass switches to perl from the script's #!
+line.  Perl checks that any command line switches given to a setuid
+(or setgid) script actually match the ones set on the #! line.  Some
+Unix and Unix-like environments impose a one-switch limit on the #!
+line, so you may need to use something like \f(CW\*(C`\-wU\*(C'\fR instead of \f(CW\*(C`\-w \-U\*(C'\fR
+under such systems.  (This issue should arise only in Unix or
+Unix-like environments that support #! and setuid or setgid scripts.)
+.ie n .SS "Taint mode and @INC"
+.el .SS "Taint mode and \f(CW@INC\fP"
+.IX Subsection "Taint mode and @INC"
++When the taint mode (\f(CW\*(C`\-T\*(C'\fR) is in effect, the environment variables
++\f(CW\*(C`PERL5LIB\*(C'\fR, \f(CW\*(C`PERLLIB\*(C'\fR, and \f(CW\*(C`PERL_USE_UNSAFE_INC\*(C'\fR
+are ignored by Perl.  You can still adjust \f(CW@INC\fR from outside the
+program by using the \f(CW\*(C`\-I\*(C'\fR command line option as explained in
+perlrun.  The two environment variables are
+ignored because they are obscured, and a user running a program could
+be unaware that they are set, whereas the \f(CW\*(C`\-I\*(C'\fR option is clearly
+visible and therefore permitted.
+.PP
+Another way to modify \f(CW@INC\fR without modifying the program, is to use
+the \f(CW\*(C`lib\*(C'\fR pragma, e.g.:
+.PP
+.Vb 1
+\&  perl \-Mlib=/foo program
+.Ve
+.PP
+The benefit of using \f(CW\*(C`\-Mlib=/foo\*(C'\fR over \f(CW\*(C`\-I/foo\*(C'\fR, is that the former
+will automagically remove any duplicated directories, while the latter
+will not.
+.PP
+Note that if a tainted string is added to \f(CW@INC\fR, the following
+problem will be reported:
+.PP
+.Vb 1
+\&  Insecure dependency in require while running with \-T switch
+.Ve
+.PP
+On versions of Perl before 5.26, activating taint mode will also remove
+the current directory (".") from the default value of \f(CW@INC\fR. Since
+version 5.26, the current directory isn't included in \f(CW@INC\fR by
+default.
+.SS "Cleaning Up Your Path"
+.IX Subsection "Cleaning Up Your Path"
+For "Insecure \f(CW$ENV{PATH}\fR" messages, you need to set \f(CW$ENV{\*(AqPATH\*(Aq}\fR to
+a known value, and each directory in the path must be absolute and
+non-writable by others than its owner and group.  You may be surprised to
+get this message even if the pathname to your executable is fully
+qualified.  This is \fInot\fR generated because you didn't supply a full path
+to the program; instead, it's generated because you never set your PATH
+environment variable, or you didn't set it to something that was safe.
+Because Perl can't guarantee that the executable in question isn't itself
+going to turn around and execute some other program that is dependent on
+your PATH, it makes sure you set the PATH.
+.PP
+The PATH isn't the only environment variable which can cause problems.
+Because some shells may use the variables IFS, CDPATH, ENV, and
+BASH_ENV, Perl checks that those are either empty or untainted when
+starting subprocesses.  You may wish to add something like this to your
+setid and taint-checking scripts.
+.PP
+.Vb 1
+\&    delete @ENV{qw(IFS CDPATH ENV BASH_ENV)};   # Make %ENV safer
+.Ve
+.PP
+It's also possible to get into trouble with other operations that don't
+care whether they use tainted values.  Make judicious use of the file
+tests in dealing with any user-supplied filenames.  When possible, do
+opens and such \fBafter\fR properly dropping any special user (or group!)
+privileges.  Perl doesn't prevent you from
+opening tainted filenames for reading,
+so be careful what you print out.  The tainting mechanism is intended to
+prevent stupid mistakes, not to remove the need for thought.
+.PP
+Perl does not call the shell to expand wild cards when you pass \f(CW\*(C`system\*(C'\fR
+and \f(CW\*(C`exec\*(C'\fR explicit parameter lists instead of strings with possible shell
+wildcards in them.  Unfortunately, the \f(CW\*(C`open\*(C'\fR, \f(CW\*(C`glob\*(C'\fR, and
+backtick functions provide no such alternate calling convention, so more
+subterfuge will be required.
+.PP
+Perl provides a reasonably safe way to open a file or pipe from a setuid
+or setgid program: just create a child process with reduced privilege who
+does the dirty work for you.  First, fork a child using the special
+\&\f(CW\*(C`open\*(C'\fR syntax that connects the parent and child by a pipe.  Now the
+child resets its ID set and any other per-process attributes, like
+environment variables, umasks, current working directories, back to the
+originals or known safe values.  Then the child process, which no longer
+has any special permissions, does the \f(CW\*(C`open\*(C'\fR or other system call.
+Finally, the child passes the data it managed to access back to the
+parent.  Because the file or pipe was opened in the child while running
+under less privilege than the parent, it's not apt to be tricked into
+doing something it shouldn't.
+.PP
+Here's a way to do backticks reasonably safely.  Notice how the \f(CW\*(C`exec\*(C'\fR is
+not called with a string that the shell could expand.  This is by far the
+best way to call something that might be subjected to shell escapes: just
+never call the shell at all.
+.PP
+.Vb 10
+\&        use English;
+\&        die "Can\*(Aqt fork: $!" unless defined($pid = open(KID, "\-|"));
+\&        if ($pid) {           # parent
+\&            while (<KID>) {
+\&                # do something
+\&            }
+\&            close KID;
+\&        } else {
+\&            my @temp     = ($EUID, $EGID);
+\&            my $orig_uid = $UID;
+\&            my $orig_gid = $GID;
+\&            $EUID = $UID;
+\&            $EGID = $GID;
+\&            # Drop privileges
+\&            $UID  = $orig_uid;
+\&            $GID  = $orig_gid;
+\&            # Make sure privs are really gone
+\&            ($EUID, $EGID) = @temp;
+\&            die "Can\*(Aqt drop privileges"
+\&                unless $UID == $EUID  && $GID eq $EGID;
+\&            $ENV{PATH} = "/bin:/usr/bin"; # Minimal PATH.
+\&            # Consider sanitizing the environment even more.
+\&            exec \*(Aqmyprog\*(Aq, \*(Aqarg1\*(Aq, \*(Aqarg2\*(Aq
+\&                or die "can\*(Aqt exec myprog: $!";
+\&        }
+.Ve
+.PP
+A similar strategy would work for wildcard expansion via \f(CW\*(C`glob\*(C'\fR, although
+you can use \f(CW\*(C`readdir\*(C'\fR instead.
+.PP
+Taint checking is most useful when although you trust yourself not to have
+written a program to give away the farm, you don't necessarily trust those
+who end up using it not to try to trick it into doing something bad.  This
+is the kind of security checking that's useful for set-id programs and
+programs launched on someone else's behalf, like CGI programs.
+.PP
+This is quite different, however, from not even trusting the writer of the
+code not to try to do something evil.  That's the kind of trust needed
+when someone hands you a program you've never seen before and says, "Here,
+run this."  For that kind of safety, you might want to check out the Safe
+module, included standard in the Perl distribution.  This module allows the
+programmer to set up special compartments in which all system operations
+are trapped and namespace access is carefully controlled.  Safe should
+not be considered bullet-proof, though: it will not prevent the foreign
+code to set up infinite loops, allocate gigabytes of memory, or even
+abusing perl bugs to make the host interpreter crash or behave in
+unpredictable ways.  In any case it's better avoided completely if you're
+really concerned about security.
+.SS "Shebang Race Condition"
+.IX Subsection "Shebang Race Condition"
+Beyond the obvious problems that stem from giving special privileges to
+systems as flexible as scripts, on many versions of Unix, set-id scripts
+are inherently insecure right from the start.  The problem is a race
+condition in the kernel.  Between the time the kernel opens the file to
+see which interpreter to run and when the (now-set-id) interpreter turns
+around and reopens the file to interpret it, the file in question may have
+changed, especially if you have symbolic links on your system.
+.PP
+Some Unixes, especially more recent ones, are free of this
+inherent security bug.  On such systems, when the kernel passes the name
+of the set-id script to open to the interpreter, rather than using a
+pathname subject to meddling, it instead passes \fI/dev/fd/3\fR.  This is a
+special file already opened on the script, so that there can be no race
+condition for evil scripts to exploit.  On these systems, Perl should be
+compiled with \f(CW\*(C`\-DSETUID_SCRIPTS_ARE_SECURE_NOW\*(C'\fR.  The \fIConfigure\fR
+program that builds Perl tries to figure this out for itself, so you
+should never have to specify this yourself.  Most modern releases of
+SysVr4 and BSD 4.4 use this approach to avoid the kernel race condition.
+.PP
+If you don't have the safe version of set-id scripts, all is not lost.
+Sometimes this kernel "feature" can be disabled, so that the kernel
+either doesn't run set-id scripts with the set-id or doesn't run them
+at all.  Either way avoids the exploitability of the race condition,
+but doesn't help in actually running scripts set-id.
+.PP
+If the kernel set-id script feature isn't disabled, then any set-id
+script provides an exploitable vulnerability.  Perl can't avoid being
+exploitable, but will point out vulnerable scripts where it can.  If Perl
+detects that it is being applied to a set-id script then it will complain
+loudly that your set-id script is insecure, and won't run it.  When Perl
+complains, you need to remove the set-id bit from the script to eliminate
+the vulnerability.  Refusing to run the script doesn't in itself close
+the vulnerability; it is just Perl's way of encouraging you to do this.
+.PP
+To actually run a script set-id, if you don't have the safe version of
+set-id scripts, you'll need to put a C wrapper around
+the script.  A C wrapper is just a compiled program that does nothing
+except call your Perl program.   Compiled programs are not subject to the
+kernel bug that plagues set-id scripts.  Here's a simple wrapper, written
+in C:
+.PP
+.Vb 4
+\&    #include <unistd.h>
+\&    #include <stdio.h>
+\&    #include <string.h>
+\&    #include <errno.h>
+\&
+\&    #define REAL_PATH "/path/to/script"
+\&
+\&    int main(int argc, char **argv)
+\&    {
+\&        execv(REAL_PATH, argv);
+\&        fprintf(stderr, "%s: %s: %s\en",
+\&                        argv[0], REAL_PATH, strerror(errno));
+\&        return 127;
+\&    }
+.Ve
+.PP
+Compile this wrapper into a binary executable and then make \fIit\fR rather
+than your script setuid or setgid.  Note that this wrapper isn't doing
+anything to sanitise the execution environment other than ensuring
+that a safe path to the script is used.  It only avoids the shebang
+race condition.  It relies on Perl's own features, and on the script
+itself being careful, to make it safe enough to run the script set-id.
+.SS "Protecting Your Programs"
+.IX Subsection "Protecting Your Programs"
+There are a number of ways to hide the source to your Perl programs,
+with varying levels of "security".
+.PP
+First of all, however, you \fIcan't\fR take away read permission, because
+the source code has to be readable in order to be compiled and
+interpreted.  (That doesn't mean that a CGI script's source is
+readable by people on the web, though.)  So you have to leave the
+permissions at the socially friendly 0755 level.  This lets 
+people on your local system only see your source.
+.PP
+Some people mistakenly regard this as a security problem.  If your program does
+insecure things, and relies on people not knowing how to exploit those
+insecurities, it is not secure.  It is often possible for someone to
+determine the insecure things and exploit them without viewing the
+source.  Security through obscurity, the name for hiding your bugs
+instead of fixing them, is little security indeed.
+.PP
+You can try using encryption via source filters (Filter::* from CPAN,
+or Filter::Util::Call and Filter::Simple since Perl 5.8).
+But crackers might be able to decrypt it.  You can try using the byte
+code compiler and interpreter described below, but crackers might be
+able to de-compile it.  You can try using the native-code compiler
+described below, but crackers might be able to disassemble it.  These
+pose varying degrees of difficulty to people wanting to get at your
+code, but none can definitively conceal it (this is true of every
+language, not just Perl).
+.PP
+If you're concerned about people profiting from your code, then the
+bottom line is that nothing but a restrictive license will give you
+legal security.  License your software and pepper it with threatening
+statements like "This is unpublished proprietary software of XYZ Corp.
+Your access to it does not give you permission to use it blah blah
+blah."  You should see a lawyer to be sure your license's wording will
+stand up in court.
+.SS Unicode
+.IX Subsection "Unicode"
+Unicode is a new and complex technology and one may easily overlook
+certain security pitfalls.  See perluniintro for an overview and
+perlunicode for details, and "Security Implications
+of Unicode" in perlunicode for security implications in particular.
+.SS "Algorithmic Complexity Attacks"
+.IX Subsection "Algorithmic Complexity Attacks"
+Certain internal algorithms used in the implementation of Perl can
+be attacked by choosing the input carefully to consume large amounts
+of either time or space or both.  This can lead into the so-called
+\&\fIDenial of Service\fR (DoS) attacks.
+.IP \(bu 4
+Hash Algorithm \- Hash algorithms like the one used in Perl are well
+known to be vulnerable to collision attacks on their hash function.
+Such attacks involve constructing a set of keys which collide into
+the same bucket producing inefficient behavior.  Such attacks often
+depend on discovering the seed of the hash function used to map the
+keys to buckets.  That seed is then used to brute-force a key set which
+can be used to mount a denial of service attack.  In Perl 5.8.1 changes
+were introduced to harden Perl to such attacks, and then later in
+Perl 5.18.0 these features were enhanced and additional protections
+added.
+.Sp
+At the time of this writing, Perl 5.18.0 is considered to be
+well-hardened against algorithmic complexity attacks on its hash
+implementation.  This is largely owed to the following measures
+mitigate attacks:
+.RS 4
+.IP "Hash Seed Randomization" 4
+.IX Item "Hash Seed Randomization"
+In order to make it impossible to know what seed to generate an attack
+key set for, this seed is randomly initialized at process start.  This
+may be overridden by using the PERL_HASH_SEED environment variable, see
+"PERL_HASH_SEED" in perlrun.  This environment variable controls how
+items are actually stored, not how they are presented via
+\&\f(CW\*(C`keys\*(C'\fR, \f(CW\*(C`values\*(C'\fR and \f(CW\*(C`each\*(C'\fR.
+.IP "Hash Traversal Randomization" 4
+.IX Item "Hash Traversal Randomization"
+Independent of which seed is used in the hash function, \f(CW\*(C`keys\*(C'\fR,
+\&\f(CW\*(C`values\*(C'\fR, and \f(CW\*(C`each\*(C'\fR return items in a per-hash randomized order.
+Modifying a hash by insertion will change the iteration order of that hash.
+This behavior can be overridden by using \f(CWhash_traversal_mask()\fR from
+Hash::Util or by using the PERL_PERTURB_KEYS environment variable,
+see "PERL_PERTURB_KEYS" in perlrun.  Note that this feature controls the
+"visible" order of the keys, and not the actual order they are stored in.
+.IP "Bucket Order Perturbance" 4
+.IX Item "Bucket Order Perturbance"
+When items collide into a given hash bucket the order they are stored in
+the chain is no longer predictable in Perl 5.18.  This
+has the intention to make it harder to observe a
+collision.  This behavior can be overridden by using
+the PERL_PERTURB_KEYS environment variable, see "PERL_PERTURB_KEYS" in perlrun.
+.IP "New Default Hash Function" 4
+.IX Item "New Default Hash Function"
+The default hash function has been modified with the intention of making
+it harder to infer the hash seed.
+.IP "Alternative Hash Functions" 4
+.IX Item "Alternative Hash Functions"
+The source code includes multiple hash algorithms to choose from.  While we
+believe that the default perl hash is robust to attack, we have included the
+hash function Siphash as a fall-back option.  At the time of release of
+Perl 5.18.0 Siphash is believed to be of cryptographic strength.  This is
+not the default as it is much slower than the default hash.
+.RE
+.RS 4
+.Sp
+Without compiling a special Perl, there is no way to get the exact same
+behavior of any versions prior to Perl 5.18.0.  The closest one can get
+is by setting PERL_PERTURB_KEYS to 0 and setting the PERL_HASH_SEED
+to a known value.  We do not advise those settings for production use
+due to the above security considerations.
+.Sp
+\&\fBPerl has never guaranteed any ordering of the hash keys\fR, and
+the ordering has already changed several times during the lifetime of
+Perl 5.  Also, the ordering of hash keys has always been, and continues
+to be, affected by the insertion order and the history of changes made
+to the hash over its lifetime.
+.Sp
+Also note that while the order of the hash elements might be
+randomized, this "pseudo-ordering" should \fBnot\fR be used for
+applications like shuffling a list randomly (use \f(CWList::Util::shuffle()\fR
+for that, see List::Util, a standard core module since Perl 5.8.0;
+or the CPAN module \f(CW\*(C`Algorithm::Numerical::Shuffle\*(C'\fR), or for generating
+permutations (use e.g. the CPAN modules \f(CW\*(C`Algorithm::Permute\*(C'\fR or
+\&\f(CW\*(C`Algorithm::FastPermute\*(C'\fR), or for any cryptographic applications.
+.Sp
+Tied hashes may have their own ordering and algorithmic complexity
+attacks.
+.RE
+.IP \(bu 4
+Regular expressions \- Perl's regular expression engine is so called NFA
+(Non-deterministic Finite Automaton), which among other things means that
+it can rather easily consume large amounts of both time and space if the
+regular expression may match in several ways.  Careful crafting of the
+regular expressions can help but quite often there really isn't much
+one can do (the book "Mastering Regular Expressions" is required
+reading, see perlfaq2).  Running out of space manifests itself by
+Perl running out of memory.
+.IP \(bu 4
+Sorting \- the quicksort algorithm used in Perls before 5.8.0 to
+implement the \fBsort()\fR function was very easy to trick into misbehaving
+so that it consumes a lot of time.  Starting from Perl 5.8.0 a different
+sorting algorithm, mergesort, is used by default.  Mergesort cannot
+misbehave on any input.
+.PP
+See <https://www.usenix.org/legacy/events/sec03/tech/full_papers/crosby/crosby.pdf> for more information,
+and any computer science textbook on algorithmic complexity.
+.SS "Using Sudo"
+.IX Subsection "Using Sudo"
+The popular tool \f(CW\*(C`sudo\*(C'\fR provides a controlled way for users to be able
+to run programs as other users.  It sanitises the execution environment
+to some extent, and will avoid the shebang race condition.  If you don't have the safe version of set-id scripts,
+then \f(CW\*(C`sudo\*(C'\fR may be a more convenient way of executing a script as
+another user than writing a C wrapper would be.
+.PP
+However, \f(CW\*(C`sudo\*(C'\fR sets the real user or group ID to that of the target
+identity, not just the effective ID as set-id bits do.  As a result, Perl
+can't detect that it is running under \f(CW\*(C`sudo\*(C'\fR, and so won't automatically
+take its own security precautions such as turning on taint mode.  Where
+\&\f(CW\*(C`sudo\*(C'\fR configuration dictates exactly which command can be run, the
+approved command may include a \f(CW\*(C`\-T\*(C'\fR option to perl to enable taint mode.
+.PP
+In general, it is necessary to evaluate the suitability of a script to
+run under \f(CW\*(C`sudo\*(C'\fR specifically with that kind of execution environment
+in mind.  It is neither necessary nor sufficient for the same script to
+be suitable to run in a traditional set-id arrangement, though many of
+the issues overlap.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+"ENVIRONMENT" in perlrun for its description of cleaning up environment
+variables.