| 322 | | vendor unless you are sure you know what you are doing. |
| 323 | | |
| 324 | | By default, Configure will arrange for /usr/bin/perl to be linked to |
| 325 | | the current version of perl. You can turn off that behavior by running |
| 326 | | |
| 327 | | Configure -Uinstallusrbinperl |
| 328 | | |
| 329 | | or by answering 'no' to the appropriate Configure prompt. |
| | 322 | vendor unless you are sure you know what you are doing. If you insist |
| | 323 | on replacing your vendor's perl, useful information on how it was |
| | 324 | configured may be found with |
| | 325 | |
| | 326 | perl -V:config_args |
| | 327 | |
| | 328 | (Check the output carefully, however, since this doesn't preserve |
| | 329 | spaces in arguments to Configure. For that, you have to look |
| | 330 | carefully at config_arg1, config_arg2, etc.) |
| | 331 | |
| | 332 | By default, Configure will not try to link /usr/bin/perl to |
| | 333 | the current version of perl. You can turn on that behavior by running |
| | 334 | |
| | 335 | Configure -Dinstallusrbinperl |
| | 336 | |
| | 337 | or by answering 'yes' to the appropriate Configure prompt. |
| | 338 | (Note that before perl 5.8.1, the default behavior was to create |
| | 339 | or overwrite /usr/bin/perl even if it already existed.) |
| | 860 | |
| | 861 | =head2 Algorithmic Complexity Attacks on Hashes |
| | 862 | |
| | 863 | In Perls 5.8.0 and earlier it was easy to create degenerate hashes. |
| | 864 | Processing such hashes would consume large amounts of CPU time, |
| | 865 | enabling a "Denial of Service" attack against Perl. Such hashes may be |
| | 866 | a problem for example for mod_perl sites, sites with Perl CGI scripts |
| | 867 | and web services, that process data originating from external sources. |
| | 868 | |
| | 869 | In Perl 5.8.1 a security feature was introduced to make it harder |
| | 870 | to create such degenerate hashes. |
| | 871 | |
| | 872 | Because of this feature the keys(), values(), and each() functions may |
| | 873 | return the hash elements in different order between different runs of |
| | 874 | Perl even with the same data. One can still revert to the old |
| | 875 | repeatable order by setting the environment variable PERL_HASH_SEED, |
| | 876 | see L<perlrun/PERL_HASH_SEED>. Another option is to add |
| | 877 | -DUSE_HASH_SEED_EXPLICIT to the compilation flags (for example by |
| | 878 | using C<Configure -Accflags=-DUSE_HAS_SEED_EXPLICIT>), in which case |
| | 879 | one has to explicitly set the PERL_HASH_SEED environment variable to |
| | 880 | enable the security feature, or by adding -DNO_HASH_SEED to the compilation |
| | 881 | flags to completely disable the randomisation feature. |
| | 882 | |
| | 883 | B<Perl has never guaranteed any ordering of the hash keys>, and the |
| | 884 | ordering has already changed several times during the lifetime of |
| | 885 | Perl 5. Also, the ordering of hash keys has always been, and |
| | 886 | continues to be, affected by the insertion order. |
| | 887 | |
| | 888 | Note that because of this randomisation for example the Data::Dumper |
| | 889 | results will be different between different runs of Perl since |
| | 890 | Data::Dumper by default dumps hashes "unordered". The use of the |
| | 891 | Data::Dumper C<Sortkeys> option is recommended. |
| 932 | | with LD_LIBRARY_PATH; on Linux you can't. On Digital Unix, you can |
| 933 | | override LD_LIBRARY_PATH by setting the _RLD_ROOT environment variable |
| 934 | | to point to the perl build directory. |
| 935 | | |
| 936 | | The only reliable answer is that you should specify a different |
| 937 | | directory for the architecture-dependent library for your -DDEBUGGING |
| 938 | | version of perl. You can do this by changing all the *archlib* |
| 939 | | variables in config.sh to point to your new architecture-dependent library. |
| | 994 | with LD_LIBRARY_PATH; on Linux, you can only override at runtime via |
| | 995 | LD_PRELOAD, specifying the exact filename you wish to be used; and on |
| | 996 | Digital Unix, you can override LD_LIBRARY_PATH by setting the |
| | 997 | _RLD_ROOT environment variable to point to the perl build directory. |
| | 998 | |
| | 999 | In other words, it is generally not a good idea to try to build a perl |
| | 1000 | with a shared library if $archlib/CORE/$libperl already exists from a |
| | 1001 | previous build. |
| | 1002 | |
| | 1003 | A good workaround is to specify a different directory for the |
| | 1004 | architecture-dependent library for your -DDEBUGGING version of perl. |
| | 1005 | You can do this by changing all the *archlib* variables in config.sh to |
| | 1006 | point to your new architecture-dependent library. |
| 1043 | | In summary, here are the Configure command-line variables you can set |
| 1044 | | to turn off various extensions. All others are included by default. |
| | 1123 | To disable certain extensions so that they are not built, use |
| | 1124 | the -Dnoextensions=... and -Donlyextensions=... options. They both |
| | 1125 | accept a space-separated list of extensions. The extensions listed |
| | 1126 | in C<noextensions> are removed from the list of extensions to build, |
| | 1127 | while the C<onlyextensions> is rather more severe and builds only |
| | 1128 | the listed extensions. The latter should be used with extreme caution |
| | 1129 | since certain extensions are used by many other extensions and modules: |
| | 1130 | such modules include Fcntl and IO. The order of processing these |
| | 1131 | options is first C<only> (if present), then C<no> (if present). |
| | 1132 | |
| | 1133 | Another, older way to turn off various extensions (which is still good |
| | 1134 | to know if you have to work with older Perl) exists. Here are the |
| | 1135 | Configure command-line variables you can set to turn off various |
| | 1136 | extensions. All others are included by default. |
| 1553 | | newer version of BIND. If you can't, you can either link with the |
| 1554 | | updated resolver library provided with BIND 8.1 or rename |
| 1555 | | /usr/local/bin/arpa/inet.h during the Perl build and test process to |
| 1556 | | avoid the problem. |
| | 1657 | newer version of BIND (and remove the files the old one left behind). |
| | 1658 | If you can't, you can either link with the updated resolver library provided |
| | 1659 | with BIND 8.1 or rename /usr/local/bin/arpa/inet.h during the Perl build and |
| | 1660 | test process to avoid the problem. |
| | 1661 | |
| | 1662 | =item *_r() prototype NOT found |
| | 1663 | |
| | 1664 | On a related note, if you see a bunch of complaints like the above about |
| | 1665 | reentrant functions - specifically networking-related ones - being present |
| | 1666 | but without prototypes available, check to see if BIND 8.1 (or possibly |
| | 1667 | other BIND 8 versions) is (or has been) installed. They install |
| | 1668 | header files such as netdb.h into places such as /usr/local/include (or into |
| | 1669 | another directory as specified at build/install time), at least optionally. |
| | 1670 | Remove them or put them in someplace that isn't in the C preprocessor's |
| | 1671 | header file include search path (determined by -I options plus defaults, |
| | 1672 | normally /usr/include). |
| 1725 | | in the EPOC environment but the solutions from there |
| 1726 | | can't directly be used elsewhere. |
| 1727 | | |
| 1728 | | The one environment where cross-compilation has successfully been used |
| 1729 | | as of this writing is the Compaq iPAQ running ARM Linux. The build |
| 1730 | | host was Intel Linux, the networking setup was PPP + SSH. The exact |
| 1731 | | setup details are beyond the scope of this document, see |
| 1732 | | http://www.handhelds.org/ for more information. |
| | 1848 | in the EPOC environment, in the WinCE, and in the OpenZaurus |
| | 1849 | project, but all those use something slightly different setup |
| | 1850 | than what described here. For the WinCE setup, read the |
| | 1851 | wince/README.compile. For the OpenZaurus setup, read the |
| | 1852 | Cross/README. |
| | 1853 | |
| | 1854 | The one environment where this cross-compilation setup has |
| | 1855 | successfully been used as of this writing is the Compaq iPAQ running |
| | 1856 | ARM Linux. The build host was Intel Linux, the networking setup was |
| | 1857 | PPP + SSH. The exact setup details are beyond the scope of this |
| | 1858 | document, see http://www.handhelds.org/ for more information. |
| 1907 | | =item Test failures from lib/ftmp-security saying "system possibly insecure" |
| 1908 | | |
| 1909 | | Firstly, test failures from the ftmp-security are not necessarily |
| 1910 | | serious or indicative of a real security threat. That being said, |
| 1911 | | they bear investigating. |
| 1912 | | |
| 1913 | | The tests may fail for the following reasons. Note that each of the |
| 1914 | | tests is run both in the building directory and the temporary |
| 1915 | | directory, as returned by File::Spec->tmpdir(). |
| 1916 | | |
| 1917 | | (1) If the directory the tests are being run is owned by somebody else |
| 1918 | | than the user running the tests, or root (uid 0). This failure can |
| 1919 | | happen if the Perl source code distribution is unpacked in a way that |
| 1920 | | the user ids in the distribution package are used as-is. Some tar |
| 1921 | | programs do this. |
| 1922 | | |
| 1923 | | (2) If the directory the tests are being run in is writable by group |
| 1924 | | or by others (remember: with UNIX/POSIX semantics, write access to |
| 1925 | | a directory means the right to add/remove files in that directory), |
| 1926 | | and there is no sticky bit set in the directory. 'Sticky bit' is |
| 1927 | | a feature used in some UNIXes to give extra protection to files: if |
| 1928 | | the bit is on a directory, no one but the owner (or the root) can remove |
| 1929 | | that file even if the permissions of the directory would allow file |
| 1930 | | removal by others. This failure can happen if the permissions in the |
| 1931 | | directory simply are a bit too liberal for the tests' liking. This |
| 1932 | | may or may not be a real problem: it depends on the permissions policy |
| 1933 | | used on this particular directory/project/system/site. This failure |
| 1934 | | can also happen if the system either doesn't support the sticky bit |
| 1935 | | (this is the case with many non-UNIX platforms: in principle |
| 1936 | | File::Temp should know about these platforms and skip the tests), or |
| 1937 | | if the system supports the sticky bit but for some reason or reasons |
| 1938 | | it is not being used. This is for example the case with HP-UX: as of |
| 1939 | | HP-UX release 11.00, the sticky bit is very much supported, but HP-UX |
| 1940 | | doesn't use it on its /tmp directory as shipped. Also, as with the |
| 1941 | | permissions, some local policy might dictate that the stickiness is |
| 1942 | | not used. |
| | 2033 | =item Failures from lib/File/Temp/t/security saying "system possibly insecure" |
| | 2034 | |
| | 2035 | First, such warnings are not necessarily serious or indicative of a |
| | 2036 | real security threat. That being said, they bear investigating. |
| | 2037 | |
| | 2038 | Note that each of the tests is run twice. The first time is in the |
| | 2039 | directory returned by File::Spec->tmpdir() (often /tmp on Unix |
| | 2040 | systems), and the second time in the directory from which the test was |
| | 2041 | run (usually the 't' directory, if the test was run as part of 'make |
| | 2042 | test'). |
| | 2043 | |
| | 2044 | The tests may fail for the following reasons: |
| | 2045 | |
| | 2046 | (1) If the directory the tests are being run in is owned by somebody |
| | 2047 | other than the user running the tests, or by root (uid 0). |
| | 2048 | |
| | 2049 | This failure can happen if the Perl source code distribution is |
| | 2050 | unpacked in such a way that the user ids in the distribution package |
| | 2051 | are used as-is. Some tar programs do this. |
| | 2052 | |
| | 2053 | (2) If the directory the tests are being run in is writable by group or |
| | 2054 | by others, and there is no sticky bit set for the directory. (With |
| | 2055 | UNIX/POSIX semantics, write access to a directory means the right to |
| | 2056 | add or remove files in that directory. The 'sticky bit' is a feature |
| | 2057 | used in some UNIXes to give extra protection to files: if the bit is |
| | 2058 | set for a directory, no one but the owner (or root) can remove that |
| | 2059 | file even if the permissions would otherwise allow file removal by |
| | 2060 | others.) |
| | 2061 | |
| | 2062 | This failure may or may not be a real problem: it depends on the |
| | 2063 | permissions policy used on this particular system. This failure can |
| | 2064 | also happen if the system either doesn't support the sticky bit (this |
| | 2065 | is the case with many non-UNIX platforms: in principle File::Temp |
| | 2066 | should know about these platforms and skip the tests), or if the system |
| | 2067 | supports the sticky bit but for some reason or reasons it is not being |
| | 2068 | used. This is, for example, the case with HP-UX: as of HP-UX release |
| | 2069 | 11.00, the sticky bit is very much supported, but HP-UX doesn't use it |
| | 2070 | on its /tmp directory as shipped. Also, as with the permissions, some |
| | 2071 | local policy might dictate that the stickiness is not used. |
