| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
OK sthen@
|
|
|
|
| |
OK sthen@
|
|
|
|
| |
OK sthen@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
| |
ok bluhm@
|
|
|
|
| |
Timing is good deraadt@, OK sthen@
|
|
|
|
| |
Timing is good deraadt@, OK sthen@
|
|
|
|
| |
Timing is good deraadt@, OK sthen@
|
|
|
|
| |
From Edgar Pettijohn <edgar () pettijohn-web ! com>
|
|
|
|
| |
OK brynet@, bluhm@
|
|
|
|
|
|
|
|
| |
This patch sets the section in perl manpages to "3p" instead of "3"
which should be less confusing as you do find them in section 3p
on OpenBSD.
Initial idea and OK espie@, makes sense to schwarze@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which tried to figure out whether mandoc supported UTF-8 output
(which it has been doing since 2011) and which passed the -T locale
option (which has been the default since 2014 and always will)
but which required the -V option to work (which was deleted half
a decade ago and will not come back).
Nowadays, it is safe to assume that mandoc just works with UTF-8
on both the input and output sides - in literally each and every
operating system providing a mandoc port or package, even those
that are seriously lagging behind.
This patch will also be pushed upstream.
OK tb@
|
| |
|
|
|
|
|
|
|
| |
Minor bugfixes and documentation improvments. See perldelta for details.
https://metacpan.org/pod/release/SHAY/perl-5.28.2/pod/perldelta.pod
OK bluhm@
|
|
|
|
|
|
|
|
|
|
|
| |
variable and fall back to what stty(1) reports, and it does so with
nroff(1), but it didn't with mandoc(1) because it didn't know how
to pass the desired width to mandoc. Teach it to use "-O width=".
OK afresh1@.
I noticed the unimplemented feature when Andrew Daugherity asked
on tech@ what the point of a certain patch in FreeBSD is (which it
turns out we don't need).
|
|
|
|
|
|
|
|
|
|
|
| |
output in UTF-8 encoding on OpenBSD. The consumer is always mandoc(1)
on OpenBSD, which can always handle UTF-8 input (no matter what LC_CTYPE
is) and which always produces useful output: UTF-8 for LC_CTYPE=*.UTF-8
or ASCII otherwise, in particular for LC_CTYPE=C.
Patch written after afresh1@ reported that "perldoc -oman" output
looked bad in both output modes.
OK afresh1@.
|
|
|
|
|
|
| |
From Andrew Daugherity <andrew.daugherity () gmail ! com>
Corrections to fix and OK millert@, suggestions and OK schwarze@
|
|
|
|
| |
looking good sthen@, Great! bluhm@
|
|
|
|
| |
looking good sthen@, Great! bluhm@
|
|
|
|
| |
looking good sthen@, Great! bluhm@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses CVE-2018-12015
From Silamael <silamael () coronamundi ! de>
Original bug reports:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900834
https://rt.cpan.org/Public/Bug/Display.html?id=125523
Original commit with the fix:
https://github.com/jib/archive-tar-new/commit/ae65651eab053fc6dc4590dbb863a268215c1fc5
OK bluhm@, they should already be committed! deraadt@
|
|
|
|
| |
OK bluhm@
|
|
|
|
| |
ok bluhm@
|
|
|
|
|
|
|
| |
During subsequent Perl updates, all the documentation changes etc.
got carried along, but the actual code change was deleted
in Rev. 1.3 and never restored. Restore it now.
Bug found by bentley@; OK afresh1@ bentley@.
|
|
|
|
| |
ok guenther@ deraadt@ giovanni@
|
|
|
|
| |
OK afresh1@ sthen@
|
|
|
|
| |
OK bluhm@, Reads ok sthen@
|
|
|
|
| |
OK bluhm@, Reads ok sthen@
|
|
|
|
|
|
| |
Reccomended by upstream - jkeenan AT pobox.com
OK sthen@
|
| |
|
| |
|
|
|
|
|
|
| |
Allows user to clean up after a noperm build
requested and makes sense to tb@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
| |
OK bluhm@
|
|
|
|
|
|
| |
Which provides hires `utime`
requested by espie@ OK millert@
|
|
|
|
|
|
| |
From Francesco Toscan < f.toscan AT hotmail DOT it >
ok guenther@
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
command line option to disable it. The new default improves the
formatting of Perl manuals using UTF-8 characters (for example
perlunicook(1)) with man(1) and mandoc(1) no matter which locale
the user has set.
Issue discovered by and fix OK by afresh1@.
Trying to push this change upstream would make no sense. It's the
right thing to do only because we decided to not support any other
locales except ASCII and UTF-8. A system trying to provide arbitrary
locales simply cannot handle manuals containing UTF-8 characters
at build time, so the change would produce wrong results.
|
|
|
|
| |
okay espie@ "we should be wary" deraadt@
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Many thanks to Nathanael Rensen <nathanael at polymorpheus dot com>
for tracking it down and supplying the patch.
Has been reported upstream and the fix incorporated into a larger change
https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/192
|
|
|
|
| |
ok deraadt@ sthen@ espie@ miod@
|
|
|
|
| |
ok deraadt@ sthen@ espie@ miod@
|
| |
|
|
|
|
|
|
| |
http://cpansearch.perl.org/src/SHAY/libnet-1.27/Changes
ok millert@
|
|
|
|
| |
ok millert@
|