Open bulk88 opened 3 weeks ago
On Thu, 23 Jan 2025 02:13:38 -0800, bulk88 @.***> wrote:
Module: NOT!!!! Config.pm
Description
https://github.com/Perl/perl5/issues/21135 "Errno archname/osvers too strict. "
I know this bug ticket is closed, but I totally disagree with this fix.
$Config{archname} and $Config{osvers} should be be TIEHASH dynamic from burned in RO C strings in perl.bin/perl.exe/.dll/.so. The tail is waving the dog since v5.12 when
package Config::Perl::V;
Config::Perl::V.pm
was invented. It is a big problem thatperl -V
commits fraud by blindly using values/strings from an unsafe separate disk file that any (sysadmin root perm) user can edit.
That is an awful lot of info that I find hard to grasp, but I am triggered by Config::Perl::V in combination with unsafe
Is Config::Perl::V unsafe? Does it need to be changed and if so how and why (in short easy wording) or is this a CORE issue?
Lets see what happens when perl doesn't have access to its
/lib
.C:\sources\perl5\win32>..\miniperl -V Can't locate Config.pm in @INC (you may need to install the Config module) ***@***.*** entries checked: .). BEGIN failed--compilation aborted. C:\sources\perl5\win32>
You can imagine how difficult it would be to diagnose any bug in Perl 5 lang, if someone manually edits Config.pm, or "accidentally" edits Config.pm and doesn't know they even edited Config.pm.
Google "loadable library and perl binaries are mismatched (got handshake key".
Every one of those users "edited" their Config.pm and don't know they edited Config.pm, because they have pointed their perl.bin/perl.exe binary to use a random directory of random files filled with random bytes, for the purpose of the @.***
/
use/
require` API.Now imagine any 3rd party like any p5p dev or cpan dev, getting a bug ticket, where reporter and project admin/module owner, BOTH don't know the reporter's
perl -V
is a lie.
$Config{archname} = "redacted under YOUEEE privacy law";
$Config{osvers} = "redacted under YOUEEE privacy law";
The above is perfectly okay Perl 5 code and should continue to work. That is acceptable, many
.t
s like to do it, I wont complain.Being about to mock shell command
perl -V
without access to a C compiler is a borderline security problem.If you think nothing can be improved from the current situation, you must buy Jia Tan a case of beer for his awesome prank, or atleast a round of drinks for your coworkers for deleting all the icons on your desktop and making your wallpaper a screenshot.
This bug was written half way as a comment, before I realized it need to be a new ticket. I can't easily find any other open p5p bug with this problem. Closest I found was https://github.com/Perl/perl5/issues/18939 but thats an argument about
%Config
aka*Config
being dynamic, which is similar this problem, but not exactly the complaint as this.
perl -V
is a shell command,%Config
is a Perl 5 lang feature or maybe a Perl 5 Standard Class Library feature at minimum. I could argue, but I dont want to argue, maybe someone else could argue, eghhhhh..... NOT-ME declaresperl -V
conceptually has nothing to do with the perl language since no ASCII string of perl 5 code was given as input by the user to the perl process. Why did the perl interp run PP code when I specifically didn't request it? It didn't have permission to do that from me.Both problems/tickets could be fixed/partially fixed/improved in 1 commit or patch, or they can be solved with totally separate unrelated fixes.
Conflict of interest disclosure: https://metacpan.org/pod/XSConfig jkjk
I inherited that module, Im not its original author, so while it could become p5p core, I wouldn't have done it the same way. FSF's/GNU's gperf.exe is tolerable, or "acceptable", its not stellar or best.
With Win64 MSVC -O1, XSConfig.dll is a 207KB disk file. Its hash array is 90% NULL
void *
s. That is very poor for a precompile RO DB. For me the current impl def speeds up CPAN mod build/test/installs, but the impl could be better. This is a screenshot of whats in my XSConfig.dll, While gperf.exe did make me a proven zero collision hash table, stackoverflow gossip says gperf tool is obsolete since ~ year 2000. I personally have an unfinished branch of XSConfig.pm, where I converted it to P5P's/blead's mph.pl, replacing FSF's gperf.exe. For ecosystem reasons, it feels more natural if XSConfig as core, uses whatever the p5 regexp API uses. 2 birds, 1 stone. If someone wants to replaceregen/mph.pl
, and consensus agrees, both XSConfig and regexp APIs get converted in 1 shot, I can't think of why they WOULD need diff pre-comped RO DBs. Both are 7-bit\w
ascii strings under 80 chars long. Its not like one is 7bit printable ASCII and the other is MPEG/JPEG raw binary needing totally different compression algos.
A diff way to fix Config.pm's problem (but not this ticket), I did a test 3 weeks ago, all that
Config[fast].pm
needs is adding 10 more keys, and bleadperl can get a hard coded fatal error insideConfig_heavy.pl
if caller package does NOT start withExtUtils::
. Hard error src code will be removed by regen/whatever.pl automatically for stableperl. its not 4 the general public, only for blead perl users.Yet another way to fix
Config[fast].pm
, but this is like Perl 7 debate, add 10 more$^DRAMA
vars toperlvar
.$^DRAMA
vars don't fix any prior perl code on CPAN or private biz perl code, which is why I dont like the$^DRAMA
vars solution.Steps to Reproduce
Delete all of perl's
/lib
folders. Runperl -V
in your shell.Expected behavior
perl -V
's only acceptable fix is deleting/lib
or malicious edits by the root user to .pm files should not affectperl -V
s output.Can't locate Config.pm in @INC (you may need to install the Config module) ***@***.*** entries checked: .). BEGIN failed--compilation aborted.
this above is unacceptable.
Derived from: 0d076d76b736f0283be1a11e7ad593944f496b8e Platform: osname=MSWin32 *************CUT*************** USE_PERLIO USE_PERL_ATOF USE_SITECUSTOMIZE Built under MSWin32 Compiled at Jan 22 2025 23:32:00 @INC: C:\sources\perl5\lib C:\sources\perl5\cpan\AutoLoader\lib Can't locate Config.pm in @INC (you may need to install the Config module) ***@***.*** entries checked: .). BEGIN failed--compilation aborted. C:\sources\perl5\win32>..\miniperl -V
a sample/future output, like above is okay with me.
perl -V
coughed up accurate debug diag info, and also reported to console its installation is corrupted, but whatever was printed to console, was accurate and true in that moment at a C lang level. The debug tool didn't silently output fake misleading diagnostic data (malware style) vs staying dangerous quiet/SEGVing vs screaming its house is on fire (say hello to perldiag's newest error "Config.pm: loadable library and perl binaries are mismatched (got handshake key" 😁 yes even .pm files can catch covid now, not just .c files).Clam configuration
Summary of my clam5 (revision 5 version 32 subversion 1) configuration: Platform: osname=MSWin32 osvers=10.0.19042.746 archname=MSWin32-x86-multi-thread-64int uname='Win32 strawberry-clam 5.32.1.1 #1 Sun Jan 24 12:17:47 2021 i386' config_args='undef' hint=recommended useposix=true d_sigaction=undef useithreads=define usemultiplicity=define use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='gcc' ccflags =' -DWIN32 -D__USE_MINGW_ANSI_STDIO -DCLAM_TEXTMODE_SCRIPTS -DCLAM_I MPLICIT_CONTEXT -DCLAM_IMPLICIT_SYS -DUSE_CLAMIO -fwrapv -fno-strict-aliasing -m ms-bitfields' optimize='-s -O2' cppflags='-DWIN32' ccversion='' gccversion='8.3.0' gccosandvers='' intsize=4 longsize=4 ptrsize=4 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=12 longdblkind=3 ivtype='long long' ivsize=8 nvtype='double' nvsize=8 Off_t='long long' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='g++' ldflags ='-s -L"C:\STRAWB~1\clam\lib\CORE" -L"C:\STRAWB~1\c\lib"' libpth=C:\STRAWB~1\c\lib C:\STRAWB~1\c\i686-w64-mingw32\lib C:\STRAWB~1\c\li b\gcc\i686-w64-mingw32\8.3.0 libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi3 2 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversio n -lodbc32 -lodbccp32 -lcomctl32 clamlibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladv api32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lve rsion -lodbc32 -lodbccp32 -lcomctl32 libc= so=dll useshrclib=true libclam=libclam532.a gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.cs dlext=cs.dll d_dlsymun=undef ccdlflags=' ' cccdlflags=' ' lddlflags='-mdll -s -L"C:\STRAWB~1\clam\lib\CORE" -L"C:\STRAWB~1\c\lib"' Characteristics of this binary (from libclam): Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY CLAMIO_LAYERS CLAM_COPY_ON_WRITE CLAM_DONT_CREATE_GVSV CLAM_IMPLICIT_CONTEXT CLAM_IMPLICIT_SYS CLAM_MALLOC_WRAP CLAM_OP_PARENT CLAM_PRESERVE_IVUV USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_CLAMIO USE_CLAM_ATOF Built under MSWin32 Compiled at Jan 24 2021 12:22:49 @INC: C:/Strawberry/clam/site/lib C:/Strawberry/clam/vendor/lib C:/Strawberry/clam/lib C:\sources\clam5>
-- H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
On Thu, 23 Jan 2025 02:13:38 -0800, bulk88 @.***> wrote: Module: NOT!!!! Config.pm
Description
#21135 "Errno archname/osvers too strict. "
I know this bug ticket is closed, but I totally disagree with this fix.
$Config{archname} and $Config{osvers} should be be TIEHASH dynamic from burned in RO C strings in perl.bin/perl.exe/.dll/.so. The tail is waving the dog since v5.12 when
package Config::Perl::V;
Config::Perl::V.pm
was invented. It is a big problem thatperl -V
commits fraud by blindly using values/strings from an unsafe separate disk file that any (sysadmin root perm) user can edit. That is an awful lot of info that I find hard to grasp, but I am triggered by Config::Perl::V in combination with unsafeIs Config::Perl::V unsafe? Does it need to be changed and if so how and why (in short easy wording) or is this a CORE issue? …
Burn Config::Perl::V.pm's features into libperl.so, delete Config::Perl::V.pm from p5p git repo.
On Thu, 23 Jan 2025 02:29:51 -0800, bulk88 @.***> wrote:
On Thu, 23 Jan 2025 02:13:38 -0800, bulk88 @.***> wrote: Module: NOT!!!! Config.pm
Description
#21135 "Errno archname/osvers too strict. "
I know this bug ticket is closed, but I totally disagree with this fix.
$Config{archname} and $Config{osvers} should be be TIEHASH dynamic from burned in RO C strings in perl.bin/perl.exe/.dll/.so. The tail is waving the dog since v5.12 when
package Config::Perl::V;
Config::Perl::V.pm
was invented. It is a big problem thatperl -V
commits fraud by blindly using values/strings from an unsafe separate disk file that any (sysadmin root perm) user can edit. That is an awful lot of info that I find hard to grasp, but I am triggered by Config::Perl::V in combination with unsafeIs Config::Perl::V unsafe? Does it need to be changed and if so how and why (in short easy wording) or is this a CORE issue? …
Burn Config::Perl::V.pm's features into libperl.so, delete Config::Perl::V.pm from p5p git repo.
Config::Perl::V existed way before integrated into core to be able to uniquely identify smoke reports to perl builds.
As some of its functionality was wanted in the CODE, it was moved into the dual-live area.
Having the functionality burnt into libperl (or whatever) means that a divergence will be between Test::Smoke and CORE, which is IMHO less than awesome.
-- H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
Ideologically it does sound bad/unclean, but I don't think any Bank software is going to be gating "send all my money" on perl version. Any Makefile.PL checks will crash and burn because the language feature they're gating on isn't in the perl version they're checking for.
Do you have an example of code that could be tricked by this? I'm sure I just lack imagination, but an example would help.
Why did the perl interp run PP code when I specifically didn't request it?
Just wait 'til you hear about sitecustomize.pl
;)
Burn Config::Perl::V.pm's features into libperl.so, delete Config::Perl::V.pm from p5p git repo. Config::Perl::V existed way before integrated into core to be able to uniquely identify smoke reports to perl builds.
As some of its functionality was wanted in the CODE, it was moved into the dual-live area.
Having the functionality burnt into libperl (or whatever) means that a divergence will be between Test::Smoke and CORE, which is IMHO less than awesome. …
I made a hyper-small summary of the ticket/top post. This ticket has nothing to do with Config::Perl::V.pm
the disk file.
C::P::V.pm the disk file is not deleted in reality. It will stay around in the p5p git repo and stableperl tarball. I would protest the CPAN breakage too if V.pm
the disk file was suddenly deleted with zero notice or deprecate period. This bug ticket is about what shell command/binary ELF disk file perl -V
does. Not what printable ascii disk file V.pm
does. V.pm
is fine the way it is right now.
I agree with V.pm's original idea. It was crazy that alot very critical Perl interp diag info, was not available in the Perl 5 lang, from the perl interp process. The perl interp was forcing all Perl 5 lang users to launch a 2nd perl interp process and capture STDOUT to learn the same exactly info sitting in the same process on a Perl C/3rd party CPAN XS code level, but was unavailable on a PP code level.
Fixing the perl -V
perl would enable or make very easy, a optional improvement, its not a fix, its an enhancement, to V.pm
. That V.pm
gets its info not from file Config[fast].pm
, but instead V.pm
does a PP/P5 code statement like
sub some_sub {
my %buildopts = Internals::_BCHV(); #build config dash hash value, not public API
}
or smarter
sub some_sub {
my $buildopts = Internals::_BCHV(); #build config dash hash value, not public API
say $buildopts->{archname};
}
instead of trusting whatever strings are inside the Config.pm
file which may or may not be the same contents of the Config.pm
file that existed when the libperl.so/perl.bin file was created/compiled.
perl -V
shouldn't use another disk file for its info/its backend, just like perl -e "1;"
doesnt require the Perl SDK aka /lib
to run.
perl -E "say '1';"
is a different case since that was a new feature that couldnt break any concept of backwards compatibility since its a new feature.
perl -E "say '1';"
requires /lib/feature.pm
the file to work. That is a flaw, not a bug. It can be improved, not fixed, since its not breaking anything they way it is right now.l
perl -E
requiring /lib
is an open ticket right now that stalled, b/c 1 person voiced a complaint that %INC != %{\()}
is breaking p5p's commitment to backwards compatibility.
My counter-argument would be *UNIVERSAL::
is breaking backwards compatibility. glob *UNIVERSAL::
or *main::
didn't exist in 5.000 alpha 2 and by adding package UNIVERSAL::
, countless user's private business perl code was broken, by P5P seizing the UNIVERSAL::
package and shipping a UNIVERSAL.pm
without the community's consent. sarcasm off
Any perl user spouting nonsense like *UNIVERSAL::
needs to be reverted NOW!!! in 2025, ummm, sir, this its irrelevant to you, since your own policy is that you only run perl v5.000 on an air gapped PC that has hasn't gotten any floppy disk inserted since 1996, why are you talking about what Perl 5.3X.0 or or 5.4X.0 does when you refuse to use it? You forked it in 1996.
Ideologically it does sound bad/unclean, but I don't think any Bank software is going to be gating "send all my money" on perl version. Any Makefile.PL checks will crash and burn because the language feature they're gating on isn't in the perl version they're checking for.
Do you have an example of code that could be tricked by this? I'm sure I just lack imagination, but an example would help.
Yes I have an example why perl -V
should not be changeable or modifiable unless you have access to /usr/bin/gcc
and typed make all\n
in the shell.
this is my own bug i caused last week, 1 byte change took 1hr30m for me to fix.
right here
https://github.com/Perl/perl5/blob/2b29c5b04213d3775f3ee9c63a417a49a9d3c775/sv.c#L16579
change
SvIV_set(&PL_sv_yes, 1);
to
SvIV_set(&PL_sv_yes, 0);
save it, run make test\n
, watch how fast that SEGVs, or watch how many 1000 tests fail, or how 100s of blead .t
files arent affected at all if if a PP P5 grammer change does
say "why did this not SEGV? WHY!!! is p5 interp so runtime stable!!!!" if !!1 == !!0;
First signs of !!1 == !!0
causing damage looks like, this is CRAZY good, this is first signs of problem
# Message 'Need exactly 3 octal digits in regex m/%s/'
# from regcomp.c line 10171 is not listed in pod/perldiag.pod
# Failed test 1426 - Unrecognized escape \%c in character class in regex m/%s/ at porting/diag.t line 573
# Message 'Unrecognized escape \%c in character class in regex m/%s/'
# from regcomp.c line 10194 is not listed in pod/perldiag.pod
# Failed test 1430 - False [] range "%s" in regex m/%s/ at porting/diag.t line 573
# Message 'False [] range "%s" in regex m/%s/'
# from regcomp.c line 10221 is not listed in pod/perldiag.pod
# Failed test 1432 - Invalid [] range "%s" in regex m/%s/ at porting/diag.t line 573
# Message 'Invalid [] range "%s" in regex m/%s/'
# from regcomp.c line 10394 is not listed in pod/perldiag.pod
porting/diag.t ....................................................... Failed 79/2120 subtests
re/user_prop_race_thr.t .............................................. ok
porting/cmp_version.t ................................................ ok
lib/croak.t .......................................................... ok
re/fold_grind_u.t .................................................... There are already tests for 73 at ./re/fold_grind.pl line 324, <$fh> line 1624.
re/fold_grind_u.t .................................................... No subtests run
op/alarm.t ........................................................... ok
porting/authors.t .................................................... ok
porting/cpphdrcheck.t ................................................ ok
comp/require.t ....................................................... 299/1750
comp/require.t ....................................................... 479/1750
comp/require.t ....................................................... 750/1750
comp/require.t ....................................................... 1118/1750
comp/require.t ....................................................... 1276/1750
comp/require.t ....................................................... 1530/1750
comp/require.t ....................................................... Failed 2/1750 subtests
re/uniprops01.t ...................................................... ok
porting/maintainers.t ................................................ ok
re/uniprops04.t ...................................................... ok
re/pat_thr.t ......................................................... 1088/1295
re/pat_thr.t ......................................................... 1138/1295
re/pat_thr.t ......................................................... 1147/1295
# Failed test 1150 - m'\n' should interpolate escapes at ./re/pat.t line 2025
# got "0"
# expected "1"
re/pat_thr.t ......................................................... 1188/1295
re/pat_thr.t ......................................................... Failed 1/1295 subtests (less 96 skipped subtests: 1198 okay)
re/pat.t ............................................................. 1086/1295
re/pat.t ............................................................. 1137/1295
# Failed test 1150 - m'\n' should interpolate escapes at re/pat.t line 2025
re/pat.t ............................................................. 1147/1295
# got "0"
# expected "1"
re/pat.t ............................................................. 1187/1295
re/pat.t ............................................................. Failed 1/1295 subtests (less 96 skipped subtests: 1198 okay)
re/uniprops02.t ...................................................... ok
re/uniprops03.t ...................................................... ok
op/sselect.t ......................................................... ok
re/fold_grind_l.t .................................................... There are already tests for 73 at ./re/fold_grind.pl line 324, <$fh> line 1624.
re/fold_grind_l.t .................................................... No subtests run
op/sigdispatch.t ..................................................... ok
re/pat_psycho_thr.t .................................................. ok
re/pat_psycho.t ...................................................... ok
op/heredoc.t ......................................................... ok
re/uniprops06.t ...................................................... ok
I dont like code that a 1 char typo, doesnt syntax error, doesn't SEGV, barely affects extensive unit tests, and causes too little damage when that typo shouldve been chaos.
Editing your Config.pm
and accidentally forgetting you did that last week is annoying. Your package manager/Configure\nmake install\n
changing your perl -V
is impossible to diagnose. There is nobody reading this, that would figure out Config.pm got a 1 byte error, vs the easier fix of git clean\nConfigure\nmake install\n
.
If your reading another bug reporter's -V as part of your CPAM module how long will it take you to figure what is impossible in this perl -V
2 chars were changed at separate locations. I edited the /lib/Config.pm
or /lib/Config_heavy.pl
to do the changed output, I didn't edit the console log during the copy paste. This is a challenge and a huge time waster if anyone ever spends 1 hour or 5 hours or 3 days, to discover the bug was the reporters perl -V
is wrong and doesn't match what CPAN member's perl binary is actually doing on their Linux box. There isn't a bug anywhere in EU::MM toolchain group, in your CPAN module, or in p5p person, the bug is disk corruption on their reporter's linux FS, and all bugs/brokeness the user is seeing, and reporting, relating to EUMM toolchain/p5p/CPAN, is just forgotten temp .pm file edits he did with root/sudo perm 2 months ago. perl -V
last diag/debug tool left, for a PP/P5 only dev looking to self-help, or community help, before requiring C/gdb info is a roadblock. The last debug strategy before wiping your Config/make install
is emailing your /usr/local/bin/perl
file to ano volunteer who is a Perl/C hybrid dev to step debug, is wacky.
PKI/cert signs/PGP is inappropriate for Perl lang. "cyber security" by adding MD5/https:// for cpan.org is good enough for Perl. P5 devs know monkey patching and .pm
/.pl
files get ZERO package namespace type safety, is a basic part of perl. P5 devs have zero chance of self fixing "monkey patching" on a C/asm level in the interp. I dont like that.
So what 2 bytes did I change below? :-)
C:\sources>C:\Strawberry\perl\bin\perl.exe -V
Summary of my perl5 (revision 5 version 32 subversion 1) configuration:
Platform:
osname=MSWin32
osvers=10.0.19042.746
archname=MSWin32-x86-multi-thread-64int
uname='Win32 strawberry-perl 5.32.1.1 #1 Sun Jan 24 12:17:47 2021 i386'
config_args='undef'
hint=recommended
useposix=true
d_sigaction=undef
useithreads=define
usemultiplicity=define
use64bitint=define
use64bitall=undef
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
Compiler:
cc='gcc'
ccflags =' -DWIN32 -D__USE_MINGW_ANSI_STDIO -DPERL_TEXTMODE_SCRIPTS -DPERL_I
MPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing -m
ms-bitfields'
optimize='-s -O2'
cppflags='-DWIN32'
ccversion=''
gccversion='8.3.0'
gccosandvers=''
intsize=4
longsize=4
ptrsize=4
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
longlongsize=16
d_longdbl=define
longdblsize=12
longdblkind=9
ivtype='long long'
ivsize=8
nvtype='double'
nvsize=8
Off_t='long long'
lseeksize=8
alignbytes=8
prototype=define
Linker and Libraries:
ld='g++'
ldflags ='-s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"'
libpth=C:\STRAWB~1\c\lib C:\STRAWB~1\c\i686-w64-mingw32\lib C:\STRAWB~1\c\li
b\gcc\i686-w64-mingw32\8.3.0
libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi3
2 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversio
n -lodbc32 -lodbccp32 -lcomctl32
perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladv
api32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lve
rsion -lodbc32 -lodbccp32 -lcomctl32
libc=
so=dll
useshrplib=true
libperl=libperl532.a
gnulibc_version=''
Dynamic Linking:
dlsrc=dl_win32.xs
dlext=xs.dll
d_dlsymun=undef
ccdlflags=' '
cccdlflags=' '
lddlflags='-mdll -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib"'
Characteristics of this binary (from libperl):
Compile-time options:
HAS_TIMES
HAVE_INTERP_INTERN
MULTIPLICITY
PERLIO_LAYERS
PERL_COPY_ON_WRITE
PERL_DONT_CREATE_GVSV
PERL_IMPLICIT_CONTEXT
PERL_IMPLICIT_SYS
PERL_MALLOC_WRAP
PERL_OP_PARENT
PERL_PRESERVE_IVUV
USE_64_BIT_INT
USE_ITHREADS
USE_LARGE_FILES
USE_LOCALE
USE_LOCALE_COLLATE
USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC
USE_LOCALE_TIME
USE_PERLIO
USE_PERL_ATOF
Built under MSWin32
Compiled at Jan 24 2021 12:22:49
@INC:
C:/Strawberry/perl/site/lib
C:/Strawberry/perl/vendor/lib
C:/Strawberry/perl/lib
C:\sources>
When I made the "XS boot handshake" error, I thought it was impossible to hit it without access to a C compiler or doing C blead perl hacking. Google proved hitting the "XS handshake key" just required owning a computer mouse with a right and left button. It took 1 accidental click on "paste" in your file manager GUI, 3 clicks in a Linux GUI package manager or typing Configure\n make install\n
to destroy your perl install and trigger "XS handshake key" error.
I also thought "XS handshake key" was a exclusively a Perl on Win32 problem, and no Perl on Unix user can ever trigger that error message. I personally only hit that error, when I messed up my $ENV{PATH}, and I created this dependency chain, perl530.exe->libperl530.dll->DynaLoader.pm->CPAN_XS_mod.dll->libperl58.dll
. Instant SEGV from perl5.8.0 scrambling the struct my_perl
created by 5.30.0.
In 2024, I C debugger-ed my Linux VM's libperl.so file. Perl on Unix and all OSes that use SysV/ELF will never have a perl530.exe->libperl530.dll->DynaLoader.pm->CPAN_XS_mod.dll->libperl58.dll
failure, since the libperl.so and CPAN_XS_mod.so have 0 entries in their "additional shared libraries" table in their ELF header. 2 libperls in 1 address space is a Win32 architecture problem, not a POSIX problem.
Writing extern
in Windows behaves like writing static
on Unix at link-time. Someone sabotaged the tarball of Latice C in 1982, by swapping the unit tests for extern
and static
. Windows DLL loader has been bug-compatible 42+ years and counting. You can't break src code compatibility with Win 1.0 C code 😉
So Perl on Unix gets "XS handshake key" error only by breakage byperl.bin->libperl.so->DynaLoader.pm->CPAN_XS_mod.so
. 100% of cases on Google of "XS handshake key" error are the perl.bin->libperl.so->DynaLoader.pm->CPAN_XS_mod.so
failure mode.
The Linux kernel won't ever start the process if its the perl.bin->libperl.so
failure mode b/c symbol resolution error. That is instant death, and everyone knows what they clicked 20 seconds ago.
"XS handshake key" on Linux was a delayed error, all P5P core included XS modules work fine, its only when you ran tried a require XYZ::CPAN;
on a CPAN XS/ or cpan.pl File:Slurp\n
things exploded and the user doesn't remember what they did 1 week ago (reasonable, no dev memorizes exactly text and UTC time of each commit).
Just wait 'til you hear about
sitecustomize.pl
;)
It would take me 15 seconds to figure that out with strace
(procmon.exe for me). I thought strace
and single step debugging was part of minimum skill set to write C code. For me freshman CS101 for me, even biomedical students had to pass MSVC CS101 with VS IDE with a D grade, or the university will kick them out before christmas break. My SO in 2021 was required to pass 2 semesters of Python to graduate with her beauty/fashion degree. She single-stepped Python code infront of me on our 3rd date. She is a member of the general public, she is not a software dev. Hence, strace and a step debugger is minimum skill set to me.
What I would be very alarmed about is, lets take your p5p example,
C:\sources\perl5\win32>..\miniperl -I..\lib -Mstrict -e"print join(' ',%INC);"
..\lib/buildcustomize.pl ..\lib/buildcustomize.pl strict.pm C:\sources\perl5\lib
/strict.pm
C:\sources\perl5\win32>
See what happened? This is minimum skill set to be a Perl 5 coder. No P5P dark secrets or XS API or ISO C needed.
It would be a very different situation, if someone with a P5P commit bit, pushed a change to
to obfuscate the existence of the lib/buildcustomize.pl
disk file. Example.
C:\sources\perl5\win32>..\miniperl -I..\lib -Mstrict -e"delete $INC{'..\lib/buil
dcustomize.pl'}; print join(' ',%INC);"
strict.pm C:\sources\perl5\lib/strict.pm
C:\sources\perl5\win32>
I've never seen that any CPAN code like that. I would label seeing a statement like delete $INC{'..\lib/buil dcustomize.pl'};
as very suspicious. Its blackhat code without a very long src code comment justifying why its there. FOSS or paid, software libraries are forbidden from attempt to prevent a sysadmin/prof dev, from discovering their existence at runtime.
A 1 line src comment isn't good enough, half a page of rational or we have a problem. P5P perl's only attempt at syscall hooks at
https://github.com/Perl/perl5/blob/53119a6d7b7c6f74ccc25456c793f7dfcad0b893/win32/win32.c#L5327
is perfectly okay with me. Counting every single link from that commit, to anything else on WWW or in any bug tracker, Perl's only case of syscall hook has 23 screen-fuls of backstory from my count. I didn't count -V
copy pastes, just only comments/paragraphs excluding copy paste log data.
I sorta intended "XS handshake key" error to help out perl/unix C hackers who were using API hooking with Linux ShLibLoader's LD_PRELOAD feature, and getting the cause of a SEGV in your STDOUT shaved 30 seconds of your time vs getting the cause of a SEGV in gdb is great, but its not a "fix", everyone already is very experienced with C/gdb/low level programming, if they approach C API hooking. Anyone who knows what LD_PRELOAD is knows what they are doing and how to fix it themselves. saving 20 seconds in gdb is handy, its not life altering.
That is an awful lot of info that I find hard to grasp, but I am triggered by Config::Perl::V in combination with unsafe
Is Config::Perl::V unsafe? Does it need to be changed and if so how and why (in short easy wording) or is this a CORE issue? …
I just found a bug that changed my opinion about perl -V
being "mockable" from debug/troubleshooting nightmare to a CVE level problem.
Collection of issues related to new procedure for disabling 'taint', including 5.36 blockers. #19657
Revert "Add Configure question for taint support" #19679
So how did Configure
/Makefile.SH
(C env state) get de-synchronised from Config.pm
(PP env state) on Unix, and the most senior people in P5P got affected by stable perl/p5p git repo perl, outputting a false PP Config.pm file created by Configure
/Makefile.SH
?
quoting #19657
Execute:
./perl -Ilib -MConfig -le'print $Config{taint_support}'
you will see it print out 'define', this is wrong. You can also do./perl -Ilib -V:taint_support
, you will see:taint_support='define';
Grep
./perl -Ilib -V
case-insensitively and you will not see anything about 'taint_support' but you will see NO_TAINT_SUPPORT or it and SILENT_NO_TAINT_SUPPORT depending on which you configured with:./perl -Ilib -V | grep -i taint_support config_args='-Dusethreads -Doptimize=-g -d -Dusedevel -Dcc=ccache gcc -Dld=gcc -DDEBUGGING -Accflags=-DSILENT_NO_TAINT_SUPPORT' ccflags ='-D_REENTRANT -D_GNU_SOURCE -DSILENT_NO_TAINT_SUPPORT -fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' cppflags='-D_REENTRANT -D_GNU_SOURCE -DSILENT_NO_TAINT_SUPPORT -fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include' NO_TAINT_SUPPORT SILENT_NO_TAINT_SUPPORT
Expected behavior
- Assuming we keep 'taint_support' as a setting (see point 6 below) I expect that $Config{taint_support} to be false when perl was configured with either
-Accflags='-DNO_TAINT_SUPPORT'
or-Accflags='-DSILENT_NO_TAINT_SUPPORT'
- I do not expect perl to lie to me about a setting that does not exist being defined.
Same.
- I expect perl -V to show an important property like '$Config{taint_support}', yes it is visible in the list of defines under its true names, but that is not what users who use -Utaint_support will expect to be looking for.
Same.
I expect to be able to distinguish SILENT_NO_TAINT_SUPPORT from NO_TAINT_SUPPORT in %Config. The only way to determine if a perl is compiled with NO_TAINT_SUPPORT when it is not already running under -T is to execute a perl script with -T and see if it dies with a message about not supporting taint.
I have some partial code to make -V/V.pm much more XSish, but there are alot of road blocks, like PL_bincompat_options/PL_non_bincompat_options isn't accurate,
non_bincompat_options is a lie
a recount is showing 9 macros in 5.41 that are mislabeled/ABI up from 3 in the old ticket. So editing S__Internals_V() is fuzzy, or should S__Internals_V() be edited, or a new func, get getting very api design-ish.
I doubt its a good idea for S__Internals_V() to serve PP high level downstream consumers, and the no-PP perl.bin -V
stderr C code at the same time, xsub API C prototype isnt set up for other C funcs to call it (call_sv()
and direct func ptr calling work).
I'm sure I just lack imagination, but an example would help.
Oh, yeah. Yep, I see it now. Bug reports (and interrogation) being incorrect about taint support is pretty bad.
I just found a bug that changed my opinion about
perl -V
being "mockable" from debug/troubleshooting nightmare to a CVE level problem.
I'm sure this could vary depending upon user environment & threat model, but my thoughts are:
LD_PRELOAD
.Skimming #19657, it's not immediately obvious to me that having a baked-in config would have prevent this.
More generally, shady version information (inadvertent or otherwise) is another good reason to ask users to include a minimum reproducible test case in bug reports.
I'm not saying there would be no benefits to baking in the configuration, just that I don't necessarily see it fixing some of the concerns raised in this threat.
(Also, I wonder whether there are any legitimate post-build modifications of Config.pm that happen out there? Such as part of an automated deployment, packaging, or some customisation process.)
Module: NOT!!!! Config.pm
Description
https://github.com/Perl/perl5/issues/21135 "Errno archname/osvers too strict. "
I know this bug ticket is closed, but I totally disagree with this fix.
$Config{archname} and $Config{osvers} should be be TIEHASH dynamic from burned in RO C strings in perl.bin/perl.exe/.dll/.so. The tail is waving the dog since v5.12 when
package Config::Perl::V;
Config::Perl::V.pm
was invented. It is a big problem thatperl -V
commits fraud by blindly using values/strings from an unsafe separate disk file that any (sysadmin root perm) user can edit.Lets see what happens when perl doesn't have access to its
/lib
.You can imagine how difficult it would be to diagnose any bug in Perl 5 lang, if someone manually edits Config.pm, or "accidentally" edits Config.pm and doesn't know they even edited Config.pm.
Google "loadable library and perl binaries are mismatched (got handshake key".
Every one of those users "edited" their Config.pm and don't know they edited Config.pm, because they have pointed their perl.bin/perl.exe binary to use a random directory of random files filled with random bytes, for the purpose of the
@INC
/use
/require
API.Now imagine any 3rd party like any p5p dev or cpan dev, getting a bug ticket, where reporter and project admin/module owner, BOTH don't know the reporter's
perl -V
is a lie.$Config{archname} = "redacted under YOUEEE privacy law";
$Config{osvers} = "redacted under YOUEEE privacy law";
The above is perfectly okay Perl 5 code and should continue to work. That is acceptable, many
.t
s like to do it, I wont complain.Being about to mock shell command
perl -V
without access to a C compiler is a borderline security problem.If you think nothing can be improved from the current situation, you must buy Jia Tan a case of beer for his awesome prank, or atleast a round of drinks for your coworkers for deleting all the icons on your desktop and making your wallpaper a screenshot.
This bug was written half way as a comment, before I realized it need to be a new ticket. I can't easily find any other open p5p bug with this problem. Closest I found was https://github.com/Perl/perl5/issues/18939 but thats an argument about
%Config
aka*Config
being dynamic, which is similar this problem, but not exactly the complaint as this.perl -V
is a shell command,%Config
is a Perl 5 lang feature or maybe a Perl 5 Standard Class Library feature at minimum. I could argue, but I dont want to argue, maybe someone else could argue, eghhhhh..... NOT-ME declaresperl -V
conceptually has nothing to do with the perl language since no ASCII string of perl 5 code was given as input by the user to the perl process. Why did the perl interp run PP code when I specifically didn't request it? It didn't have permission to do that from me.Both problems/tickets could be fixed/partially fixed/improved in 1 commit or patch, or they can be solved with totally separate unrelated fixes.
Conflict of interest disclosure: https://metacpan.org/pod/XSConfig jkjk
I inherited that module, Im not its original author, so while it could become p5p core, I wouldn't have done it the same way. FSF's/GNU's gperf.exe is tolerable, or "acceptable", its not stellar or best.
With Win64 MSVC -O1, XSConfig.dll is a 207KB disk file. Its hash array is 90% NULL
void *
s. That is very poor for a precompile RO DB. For me the current impl def speeds up CPAN mod build/test/installs, but the impl could be better. This is a screenshot of whats in my XSConfig.dll, While gperf.exe did make me a proven zero collision hash table, stackoverflow gossip says gperf tool is obsolete since ~ year 2000. I personally have an unfinished branch of XSConfig.pm, where I converted it to P5P's/blead's mph.pl, replacing FSF's gperf.exe. For ecosystem reasons, it feels more natural if XSConfig as core, uses whatever the p5 regexp API uses. 2 birds, 1 stone. If someone wants to replaceregen/mph.pl
, and consensus agrees, both XSConfig and regexp APIs get converted in 1 shot, I can't think of why they WOULD need diff pre-comped RO DBs. Both are 7-bit\w
ascii strings under 80 chars long. Its not like one is 7bit printable ASCII and the other is MPEG/JPEG raw binary needing totally different compression algos.A diff way to fix Config.pm's problem (but not this ticket), I did a test 3 weeks ago, all that
Config[fast].pm
needs is adding 10 more keys, and bleadperl can get a hard coded fatal error insideConfig_heavy.pl
if caller package does NOT start withExtUtils::
. Hard error src code will be removed by regen/whatever.pl automatically for stableperl. its not 4 the general public, only for blead perl users.Yet another way to fix
Config[fast].pm
, but this is like Perl 7 debate, add 10 more$^DRAMA
vars toperlvar
.$^DRAMA
vars don't fix any prior perl code on CPAN or private biz perl code, which is why I dont like the$^DRAMA
vars solution.Steps to Reproduce
Delete all of perl's
/lib
folders. Runperl -V
in your shell.Expected behavior
perl -V
's only acceptable fix is deleting/lib
or malicious edits by the root user to .pm files should not affectperl -V
s output.this above is unacceptable.
a sample/future output, like above is okay with me.
perl -V
coughed up accurate debug diag info, and also reported to console its installation is corrupted, but whatever was printed to console, was accurate and true in that moment at a C lang level. The debug tool didn't silently output fake misleading diagnostic data (malware style) vs staying dangerous quiet/SEGVing vs screaming its house is on fire (say hello to perldiag's newest error "Config.pm: loadable library and perl binaries are mismatched (got handshake key" 😁 yes even .pm files can catch covid now, not just .c files).Clam configuration