WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/gnu/usr.bin/perl/patchlevel.h?h=jd%2Fhistogram 2020-06-04T01:34:59Z 2020-06-04T01:34:59Z afresh1 afresh1@openbsd.org 2020-06-04T01:34:59Z urn:sha1:4510546b7f0f46acfc00d93413b13b3c9fe8351b All functional changes were committed already, this updates the version number, Module::Corelist, and documentation. 2020-04-09T01:32:10Z afresh1 afresh1@openbsd.org 2020-04-09T01:32:10Z urn:sha1:98dafc01a631e8efdda861c8d6ff5833eae69524 https://metacpan.org/pod/release/SHAY/perl-5.30.2/pod/perldelta.pod Incompatible Changes There are no changes intentionally incompatible with 5.30.0. Updated Modules and Pragmata * Compress::Raw::Bzip2 has been upgraded from version 2.084 to 2.089. * Module::CoreList has been upgraded from version 5.20191110 to 5.20200314. Selected Bug Fixes * printf() or sprintf() with the %n format no longer cause a panic on debugging builds, or report an incorrectly cached length value when producing SVfUTF8 flagged strings. * A memory leak in regular expression patterns has been fixed. * A read beyond buffer in grok_infnan has been fixed. * An assertion failure in the regular expression engine has been fixed. * (?{...}) eval groups in regular expressions no longer unintentionally trigger "EVAL without pos change exceeded limit in regex". Proceed when you feel comfortable. deraadt@ 2019-12-30T02:13:39Z afresh1 afresh1@openbsd.org 2019-12-30T02:13:39Z urn:sha1:b46d8ef224b95de1dddcd1f01c1ab482f0ab3778 Timing is good deraadt@, OK sthen@ 2019-05-24T21:33:50Z afresh1 afresh1@openbsd.org 2019-05-24T21:33:50Z urn:sha1:e603c72f713dd59b67030a9b97ec661800da159e Minor bugfixes and documentation improvments. See perldelta for details. https://metacpan.org/pod/release/SHAY/perl-5.28.2/pod/perldelta.pod OK bluhm@ 2019-02-13T21:15:00Z afresh1 afresh1@openbsd.org 2019-02-13T21:15:00Z urn:sha1:9f11ffb7133c203312a01e4b986886bc88c7d74b looking good sthen@, Great! bluhm@ 2017-10-29T22:37:14Z afresh1 afresh1@openbsd.org 2017-10-29T22:37:14Z urn:sha1:c0dd97bfcad3dab6c31ec12b9de1274fd2d2f993 ok bluhm@ 2017-08-14T13:48:45Z afresh1 afresh1@openbsd.org 2017-08-14T13:48:45Z urn:sha1:de18eedb1d177e2a8ac32356c93ab698027bc41f OK bluhm@, Reads ok sthen@ 2017-02-05T00:31:51Z afresh1 afresh1@openbsd.org 2017-02-05T00:31:51Z urn:sha1:b8851fcc53cbe24fd20b090f26dd149e353f6174 2016-07-25T10:53:00Z afresh1 afresh1@openbsd.org 2016-07-25T10:53:00Z urn:sha1:0b7734b3d77bb9b21afec6f4621cae6c805dbd45 The problem relates to Perl 5 ("perl") loading modules from the includes directory array ("@INC") in which the last element is the current directory ("."). That means that, when "perl" wants to load a module (during first compilation or during lazy loading of a module in run-time), perl will look for the module in the current directory at the end, since '.' is the last include directory in its array of include directories to seek. The issue is with requiring libraries that are in "." but are not otherwise installed. The major problem with this behavior is that it unexpectedly puts a user at risk whenever they execute any Perl scripts from a directory that is writable by other accounts on the system. For instance, if a user is logged in as root and changes directory into /tmp or an account's home directory, it is possible to now run any shell commands that are written in C, Python or Ruby without fear. The same isn't true for any shell commands that are written in Perl, since a significant proportion of Perl scripts will execute code in the current working directory whenever they are run. For example, if a user on a shared system creates the file /tmp/Pod/Perldoc/Toterm.pm, and then I log in as root, change directory to /tmp, and run "perldoc perlrun", it will execute the code they have placed in the file. ok deraadt@ 2016-07-08T14:26:04Z millert millert@openbsd.org 2016-07-08T14:26:04Z urn:sha1:ee730484fcc4d0bb60f681a9a47565679740ef11