Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default perl builds to not include . in @INC (default_inc_excludes_dot) #15786

Closed
p5pRT opened this issue Dec 31, 2016 · 54 comments
Closed

Default perl builds to not include . in @INC (default_inc_excludes_dot) #15786

p5pRT opened this issue Dec 31, 2016 · 54 comments

Comments

@p5pRT
Copy link

p5pRT commented Dec 31, 2016

Migrated from rt.perl.org#130467 (status was 'resolved')

Searchable as RT130467$

@p5pRT
Copy link
Author

p5pRT commented Dec 31, 2016

From @toddr

Created by @toddr

In light of recent events, including CVE-2016-1238, I propose changing
the default perl build to not include . in @​INC.

There are multiple approaches to making this happen. The approach we
took at cPanel was to inject an environment variable
PERL_USE_UNSAFE_INC=1 into CPAN clients as well as EU​::MM, M​::B.

This solved 95% of our issues. In discussions with #toolchain, they
have asked that we first assess the scope of failures on CPAN before
taking my suggested approach.

As I understand things, we must make a decision on this ticket,
ideally prior to 5.25.9.

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl 5.24.1:

Configured by cPanel at Fri Dec 16 19:08:02 CST 2016.

Summary of my perl5 (revision 5 version 24 subversion 1) configuration:

  Platform:
    osname=linux, osvers=3.10.0-123.20.1.el7.x86_64, archname=x86_64-linux-64int
    uname='linux rpmbuild-64-centos-7.dev.cpanel.net
3.10.0-123.20.1.el7.x86_64 #1 smp thu jan 29 18:05:33 utc 2015 x86_64
x86_64 x86_64 gnulinux '
    config_args='-des -Dusedevel -Darchname=x86_64-linux-64int
-Dcc=/usr/bin/gcc -Dcpp=/usr/bin/cpp -Dusemymalloc=n -DDEBUGGING=none
-Doptimize=-Os -Accflags=-m64 -Dccflags=-DPERL_DISABLE_PMC -fPIC -DPIC
-I/usr/local/cpanel/3rdparty/perl/524/include
-L/usr/local/cpanel/3rdparty/perl/524/lib64
-I/usr/local/cpanel/3rdparty/include
-L/usr/local/cpanel/3rdparty/lib64 -Duseshrplib -Duselargefiles=yes
-Duseposix=true -Dhint=recommended -Duseperlio=yes
-Dcppflags=-I/usr/local/cpanel/3rdparty/perl/524/include
-L/usr/local/cpanel/3rdparty/perl/524/lib64
-I/usr/local/cpanel/3rdparty/include
-L/usr/local/cpanel/3rdparty/lib64 -Dldflags=-Wl,-rpath
-Wl,/usr/local/cpanel/3rdparty/perl/524/lib64
-L/usr/local/cpanel/3rdparty/perl/524/lib64
-L/usr/local/cpanel/3rdparty/lib64
-Dprefix=/usr/local/cpanel/3rdparty/perl/524
-Dsiteprefix=/opt/cpanel/perl5/524 -Dsitebin=/opt/cpanel/perl5/524/bin
-Dsitelib=/opt/cpanel/perl5/524/site_lib -Dusevendorprefix=true
-Dvendorbin=/usr/local/cpanel/3rdparty/perl/524/bin
-Dvendorprefix=/usr/local/cpanel/3rdparty/perl/524/lib64/perl5
-Dvendorlib=/usr/local/cpanel/3rdparty/perl/524/lib64/perl5/cpanel_lib
-Dprivlib=/usr/local/cpanel/3rdparty/perl/524/lib64/perl5/5.24.1
-Dman1dir=none -Dman3dir=none
-Dscriptdir=/usr/local/cpanel/3rdparty/perl/524/bin
-Dscriptdirexp=/usr/local/cpanel/3rdparty/perl/524/bin
-Dsiteman1dir=none -Dsiteman3dir=none -Dinstallman1dir=none
-Dversiononly=no -Dinstallusrbinperl=no -Dcf_by=cPanel
-Dmyhostname=localhost -Dperladmin=root@localhost
-Dcf_email=support@cpanel.net
-Di_dbm=/usr/local/cpanel/3rdparty/include
-Di_gdbm=/usr/local/cpanel/3rdparty/include
-Di_ndbm=/usr/local/cpanel/3rdparty/include -DDB_File=true -Ud_dosuid
-Uuserelocatableinc -Umad -Uusethreads -Uusemultiplicity -Uusesocks
-Uuselongdouble -Aldflags=-L/usr/local/cpanel/3rdparty/perl/524/lib64
-L/usr/local/cpanel/3rdparty/lib64 -L/usr/lib64 -L/lib64 -lgdbm
-Dlocincpth=/usr/local/cpanel/3rdparty/perl/524/include
/usr/local/cpanel/3rdparty/include /usr/local/include  -Duse64bitint
-Uuse64bitall -Dlibpth=/usr/local/cpanel/3rdparty/perl/524/lib64
/usr/local/cpanel/3rdparty/lib64 /usr/local/lib64 /usr/local/lib
/lib64 /usr/lib64 '
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='/usr/bin/gcc', ccflags ='-DPERL_DISABLE_PMC -fPIC -DPIC
-I/usr/local/cpanel/3rdparty/perl/524/include
-L/usr/local/cpanel/3rdparty/perl/524/lib64
-I/usr/local/cpanel/3rdparty/include
-L/usr/local/cpanel/3rdparty/lib64 -m64 -fwrapv -fno-strict-aliasing
-pipe -fstack-protector-strong -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2',
    optimize='-Os',
    cppflags='-I/usr/local/cpanel/3rdparty/perl/524/include
-L/usr/local/cpanel/3rdparty/perl/524/lib64
-I/usr/local/cpanel/3rdparty/include
-L/usr/local/cpanel/3rdparty/lib64 -DPERL_DISABLE_PMC -fPIC -DPIC
-I/usr/local/cpanel/3rdparty/perl/524/include
-L/usr/local/cpanel/3rdparty/perl/524/lib64
-I/usr/local/cpanel/3rdparty/include
-L/usr/local/cpanel/3rdparty/lib64 -m64 -fwrapv -fno-strict-aliasing
-pipe -fstack-protector-strong -I/usr/local/include'
    ccversion='', gccversion='4.8.2 20140120 (Red Hat 4.8.2-16)',
gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8,
byteorder=12345678, doublekind=3
    d_longlong=define, longlongsize=8, d_longdbl=define,
longdblsize=16, longdblkind=3
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='/usr/bin/gcc', ldflags ='-Wl,-rpath
-Wl,/usr/local/cpanel/3rdparty/perl/524/lib64
-L/usr/local/cpanel/3rdparty/perl/524/lib64
-L/usr/local/cpanel/3rdparty/lib64
-L/usr/local/cpanel/3rdparty/perl/524/lib64
-L/usr/local/cpanel/3rdparty/lib64 -L/usr/lib64 -L/lib64 -lgdbm
-fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/cpanel/3rdparty/perl/524/lib64
/usr/local/cpanel/3rdparty/lib64 /usr/local/lib64 /usr/local/lib
/lib64 /usr/lib64 /usr/local/lib /usr/lib /lib/../lib64
/usr/lib/../lib64 /lib
    libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.17.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.17'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E
-Wl,-rpath,/usr/local/cpanel/3rdparty/perl/524/lib64/perl5/5.24.1/x86_64-linux-64int/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -Os
-L/usr/local/cpanel/3rdparty/perl/524/lib64
-L/usr/local/cpanel/3rdparty/lib64 -L/usr/lib64 -L/lib64
-L/usr/local/lib -fstack-protector-strong'

Locally applied patches:
    RC3
    cPanel patches
    cPanel INC path changes
    Remove . from @INC


@INC for perl 5.24.1:
    /usr/local/cpanel
    /usr/local/cpanel/3rdparty/perl/524/lib64/perl5/cpanel_lib/x86_64-linux-64int
    /usr/local/cpanel/3rdparty/perl/524/lib64/perl5/cpanel_lib
    /usr/local/cpanel/3rdparty/perl/524/lib64/perl5/5.24.1/x86_64-linux-64int
    /usr/local/cpanel/3rdparty/perl/524/lib64/perl5/5.24.1
    /opt/cpanel/perl5/524/site_lib/x86_64-linux-64int
    /opt/cpanel/perl5/524/site_lib


Environment for perl 5.24.1:
    HOME=/root
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/cpanel/3rdparty/perl/524/bin:/usr/local/cpanel/bin:/usr/local/cpanel/3rdparty/bin:/usr/local/cpanel/3rdparty/perl/524/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/cpanel/perl5/524/bin
    PERL_BADLANG (unset)
    SHELL=/bin/zsh

@p5pRT
Copy link
Author

p5pRT commented Dec 31, 2016

From @jkeenan

On Sat, 31 Dec 2016 17​:36​:49 GMT, TODDR wrote​:

This is a bug report for perl from toddr@​cpan.org,
generated with the help of perlbug 1.40 running under perl 5.24.1.

-----------------------------------------------------------------
[Please describe your issue here]

In light of recent events, including CVE-2016-1238, I propose changing
the default perl build to not include . in @​INC.

There are multiple approaches to making this happen. The approach we
took at cPanel was to inject an environment variable
PERL_USE_UNSAFE_INC=1 into CPAN clients as well as EU​::MM, M​::B.

Can you explain why you chose to do this in these locations? (I realize you probably have already done so in other threads or on IRC, but since we're consolidating the discussion here, I'd like your reasoning to be clear to people just coming upon this discussion.)

This solved 95% of our issues.

Can you describe what was in the 95% and what was in the other 5%?

In discussions with #toolchain, they
have asked that we first assess the scope of failures on CPAN before
taking my suggested approach.

Is that already being tracked in a BBC ticket?

As I understand things, we must make a decision on this ticket,
ideally prior to 5.25.9.

Thanks for taking the initiative on this and for moving the discussion forward.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Dec 31, 2016

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Jan 1, 2017

From @toddr

On Sat, 31 Dec 2016 15​:36​:53 -0800, jkeenan wrote​:

On Sat, 31 Dec 2016 17​:36​:49 GMT, TODDR wrote​:

There are multiple approaches to making this happen. The approach we
took at cPanel was to inject an environment variable
PERL_USE_UNSAFE_INC=1 into CPAN clients as well as EU​::MM, M​::B.

Can you explain why you chose to do this in these locations? (I
realize you probably have already done so in other threads or on IRC,
but since we're consolidating the discussion here, I'd like your
reasoning to be clear to people just coming upon this discussion.)

So ultimately, the goal is to get your build environments to have . in
@​INC because many CPAN modules cannot build without it.
There are many reasons for this.

1. Makefile.PL requires . in @​INC because it expects to be able to
use inc​::Module​::Install

2. While Test​::Harness uses blib, it does not include . and among
other tricks, people have done​: use t​::lib​::TestTool breaks without
. in @​INC. I think those can actually be amended to
use .​::t​::lib​::TestTool or maybe require "./t/lib/TestTool.pm"

3. There are modules that have multiple Makefile.PL files so simply
amending whichever to do perl -I. Makefile.PL does not work.
Example​: NetAddr​::IP has 3 Makefile.PL scripts in its tree.

4. There are unit tests that call perl scripts that expect .
to be in @​INC.

There may be others I'm not thinking of right now but those will do.

In essence you need a tool that can inject . into @​INC for all of its child
process. I can think of no better way to do this than with an
environment variable.

While all of the above problems could in theory be fixed on CPAN,
the question is how we do this in a timely fashion. Even if you limit
yourself to modules that pass on 5.24, I think you still end up with a
very large set of modules. grep.cpan.me is down ATM but something
like m/use inc​::Module​::Install/ would be interesting to get numbers
on. I did it months ago but I can't tell you the numbers right now.

This solved 95% of our issues.

Can you describe what was in the 95% and what was in the other 5%?
Hopefully my first answer answered your 95% question.

I did a quick scan of our CPAN RPM repo and I could actually only
find 3 out of 1000 that needed an extra patch. So I correct my
number to 99.7% solves the problem :D. The patch files are
attached.

In discussions with #toolchain, they
have asked that we first assess the scope of failures on CPAN before
taking my suggested approach.

Is that already being tracked in a BBC ticket?

No this is the only recorded location I am aware of. Other than that,
it's mostly been IRC and in person conversations. I have leveraged
this ticket to talk in IRC today. I'll also be emailing cpan-workers to
try to get a discussion going. If you have other ideas how we can
get consensus on this, I would be very glad to have help.

As I understand things, we must make a decision on this ticket,
ideally prior to 5.25.9.

Thanks for taking the initiative on this and for moving the discussion
forward.

And thank you for all your work!

Todd

@p5pRT
Copy link
Author

p5pRT commented Jan 1, 2017

From @toddr

Crypt-Twofish.patch
From 9e864236afe097437e74ca9bf47384d362d93ade Mon Sep 17 00:00:00 2001
From: Todd Rinaldo <toddr@cpanel.net>
Date: Fri, 8 Jan 2016 01:24:39 -0600
Subject: [PATCH] Add PERL_USE_UNSAFE_INC support

---
 modules/Crypt-Twofish/Crypt-Twofish/Makefile.PL | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/modules/Crypt-Twofish/Crypt-Twofish/Makefile.PL b/modules/Crypt-Twofish/Crypt-Twofish/Makefile.PL
index 0fc3b99..f6b954c 100644
--- a/modules/Crypt-Twofish/Crypt-Twofish/Makefile.PL
+++ b/modules/Crypt-Twofish/Crypt-Twofish/Makefile.PL
@@ -49,7 +49,7 @@ open(F, ">platform.h") || die "platform.h: $!\n";
 print F $text;
 close F;
 
-sub MY::postamble { "tables.h: tab/tables.pl\n\t\$(PERL) tab/tables.pl\n" }
+sub MY::postamble { "tables.h: tab/tables.pl\n\tPERL_USE_UNSAFE_INC=1 \$(PERL) tab/tables.pl\n" }
 
 WriteMakefile(
     NAME          => 'Crypt::Twofish',
-- 
2.7.0

@p5pRT
Copy link
Author

p5pRT commented Jan 1, 2017

From @toddr

File-NFSLock.patch
From dddeafacc38952f5b565152f4ffe30747fbeb106 Mon Sep 17 00:00:00 2001
From: Nicolas Rochelemagne <rochelemagne@cpanel.net>
Date: Fri, 8 Jan 2016 12:07:32 -0600
Subject: [PATCH] Add PERL_USE_UNSAFE_INC support

---
 modules/File-NFSLock/File-NFSLock/Makefile.PL | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/modules/File-NFSLock/File-NFSLock/Makefile.PL b/modules/File-NFSLock/File-NFSLock/Makefile.PL
index abc3381..5d68926 100644
--- a/modules/File-NFSLock/File-NFSLock/Makefile.PL
+++ b/modules/File-NFSLock/File-NFSLock/Makefile.PL
@@ -28,9 +28,10 @@ package MY;
 sub processPL {
   my $self = shift;
   my $block = $self->SUPER::processPL(@_);
-  # "Version:" in spec needs to match
+ # "Version:" in spec needs to match
   # "$VERSION" from VERSION_FROM
-  $block =~ s%(spec.PL\s*)$%$1 \$\(VERSION_FROM\)%m;
+  $block =~ s[(\$\(PERLRUNINST\)\s+File-NFSLock.spec.PL\b)][PERL_USE_UNSAFE_INC=1 $1]m;
+  $block =~ s%(spec.PL\s*)$%1 \$\(VERSION_FROM\)%m;
   $block;
 }
 
-- 
2.7.0

@p5pRT
Copy link
Author

p5pRT commented Jan 1, 2017

From @toddr

Mail-SpamAssassin.patch
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Todd Rinaldo <toddr@cpanel.net>
Date: Fri, 8 Jan 2016 01:46:15 -0600
Subject: [PATCH 08/13] Add PERL_USE_UNSAFE_INC support

---
 modules/Mail-SpamAssassin/Mail-SpamAssassin/Makefile.PL | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/modules/Mail-SpamAssassin/Mail-SpamAssassin/Makefile.PL b/modules/Mail-SpamAssassin/Mail-SpamAssassin/Makefile.PL
index 33ca2af01..2142dfff0 100644
--- a/modules/Mail-SpamAssassin/Mail-SpamAssassin/Makefile.PL
+++ b/modules/Mail-SpamAssassin/Mail-SpamAssassin/Makefile.PL
@@ -1050,7 +1050,7 @@ QSPAMC_SRC      = spamc/qmail-spamc.c spamc/utils.c
 LIBSPAMC_SRC    = spamc/libspamc.c spamc/utils.c
 
 $(SPAMC_MAKEFILE): $(SPAMC_MAKEFILE).in $(SPAMC_MAKEFILE).win spamc/spamc.h.in
-	$(CONFIGURE) --prefix="$(I_PREFIX)" --sysconfdir="$(I_CONFDIR)" --datadir="$(I_DATADIR)" --enable-ssl="$(ENABLE_SSL)"
+	PERL_USE_UNSAFE_INC=1 $(CONFIGURE) --prefix="$(I_PREFIX)" --sysconfdir="$(I_CONFDIR)" --datadir="$(I_DATADIR)" --enable-ssl="$(ENABLE_SSL)"
 
 spamc_has_moved:
 	$(NOECHO) echo "***"

@p5pRT
Copy link
Author

p5pRT commented Jan 1, 2017

From @Leont

On Sun, Jan 1, 2017 at 12​:36 AM, James E Keenan via RT <
perlbug-followup@​perl.org> wrote​:

On Sat, 31 Dec 2016 17​:36​:49 GMT, TODDR wrote​:

This is a bug report for perl from toddr@​cpan.org,
generated with the help of perlbug 1.40 running under perl 5.24.1.

-----------------------------------------------------------------
[Please describe your issue here]

In light of recent events, including CVE-2016-1238, I propose changing
the default perl build to not include . in @​INC.

There are multiple approaches to making this happen. The approach we
took at cPanel was to inject an environment variable
PERL_USE_UNSAFE_INC=1 into CPAN clients as well as EU​::MM, M​::B.

Can you explain why you chose to do this in these locations? (I realize
you probably have already done so in other threads or on IRC, but since
we're consolidating the discussion here, I'd like your reasoning to be
clear to people just coming upon this discussion.)

There are essentially 2 kinds of breakages in the toolchain​:
* configure time (mainly Module​::Install, and a few others but not many).
* testing time (mainly libs directly under t/ instead of using an explicit
t/lib).

Injecting the environmental variable in the CPAN clients fixes both issues,
but only for people who are using CPAN clients. Which is thankfully the
vast majority of people but there are people and situations that require
manual installs.

Injecting in the install tool can only fix testing issues, but can actually
fix them for all users, including manual ones.

To me the first approach is more valuable than the second one, but there's

Manually installing non-updated Module​::Install dists will be the painful
quadrant no matter what. Module​::Install is a gift that keeps on giving.

Leon

@p5pRT
Copy link
Author

p5pRT commented Jan 1, 2017

From @toddr

On Sun, 01 Jan 2017 11​:34​:36 -0800, LeonT wrote​:

On Sun, Jan 1, 2017 at 12​:36 AM, James E Keenan via RT <
perlbug-followup@​perl.org> wrote​:

Can you explain why you chose to do this in these locations? (I realize
you probably have already done so in other threads or on IRC, but since
we're consolidating the discussion here, I'd like your reasoning to be
clear to people just coming upon this discussion.)

There are essentially 2 kinds of breakages in the toolchain​:
* configure time (mainly Module​::Install, and a few others but not many).
* testing time (mainly libs directly under t/ instead of using an explicit
t/lib).

Injecting the environmental variable in the CPAN clients fixes both issues,
but only for people who are using CPAN clients. Which is thankfully the
vast majority of people but there are people and situations that require
manual installs.

Sure in addition to this, we might be provide advice to distro maintainers
in a document which advises setting the environment variable among
other things. Had such a authoritative document existed 3-4 years ago,
that would have definitely helped me.

It probably wouldn't be hard to steal from Debian to get a skeleton
document to start off with.

Injecting in the install tool can only fix testing issues, but can actually
fix them for all users, including manual ones.

If you do the install tool + Test​::Harness, you get most of with the
exception of Module​::Install which you can technically fix with
something like require "./inc/Module/Install.pm"

Manually installing non-updated Module​::Install dists will be the painful
quadrant no matter what. Module​::Install is a gift that keeps on giving.

Yeah, I propose a holy crusade to eradicate M​:I similar to what they're
trying to do with Polio :)

Todd

@p5pRT
Copy link
Author

p5pRT commented Jan 1, 2017

From @jkeenan

On 01/01/2017 03​:07 PM, Todd Rinaldo via RT wrote​:

[snip]

Yeah, I propose a holy crusade to eradicate M​:I similar to what they're
trying to do with Polio :)

Todd

Can we get funding from the Bill and Melinda Gates Foundation?

@p5pRT
Copy link
Author

p5pRT commented Jan 15, 2017

From @xsawyerx

On 01/01/2017 08​:33 PM, Leon Timmermans wrote​:

On Sun, Jan 1, 2017 at 12​:36 AM, James E Keenan via RT
<perlbug-followup@​perl.org <mailto​:perlbug-followup@​perl.org>> wrote​:

On Sat\, 31 Dec 2016 17&#8203;:36&#8203;:49 GMT\, TODDR wrote&#8203;:
> This is a bug report for perl from toddr@&#8203;cpan\.org
\<mailto&#8203;:toddr@&#8203;cpan\.org>\,
> generated with the help of perlbug 1\.40 running under perl 5\.24\.1\.
>
>
> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
> \[Please describe your issue here\]
>
>
> In light of recent events\, including CVE\-2016\-1238\, I propose
changing
> the default perl build to not include \. in @&#8203;INC\.
>
> There are multiple approaches to making this happen\. The approach we
> took at cPanel was to inject an environment variable
> PERL\_USE\_UNSAFE\_INC=1 into CPAN clients as well as EU&#8203;::MM\, M&#8203;::B\.
>

Can you explain why you chose to do this in these locations?  \(I
realize you probably have already done so in other threads or on
IRC\, but since we're consolidating the discussion here\, I'd like
your reasoning to be clear to people just coming upon this
discussion\.\)

There are essentially 2 kinds of breakages in the toolchain​:
* configure time (mainly Module​::Install, and a few others but not many).
* testing time (mainly libs directly under t/ instead of using an explicit
t/lib).

Injecting the environmental variable in the CPAN clients fixes both
issues,
but only for people who are using CPAN clients. Which is thankfully the
vast majority of people but there are people and situations that require
manual installs.

Injecting in the install tool can only fix testing issues, but can
actually
fix them for all users, including manual ones.

To me the first approach is more valuable than the second one, but
there's

Manually installing non-updated Module​::Install dists will be the painful
quadrant no matter what. Module​::Install is a gift that keeps on giving.

I'd like to ping this again. :)

@p5pRT
Copy link
Author

p5pRT commented Jan 16, 2017

From @Leont

On Sun, Jan 15, 2017 at 11​:52 AM, Sawyer X <xsawyerx@​gmail.com> wrote​:

On 01/01/2017 08​:33 PM, Leon Timmermans wrote​:

On Sun, Jan 1, 2017 at 12​:36 AM, James E Keenan via RT
<perlbug-followup@​perl.org <mailto​:perlbug-followup@​perl.org>> wrote​:

On Sat\, 31 Dec 2016 17&#8203;:36&#8203;:49 GMT\, TODDR wrote&#8203;:
> This is a bug report for perl from toddr@&#8203;cpan\.org
\<mailto&#8203;:toddr@&#8203;cpan\.org>\,
> generated with the help of perlbug 1\.40 running under perl 5\.24\.1\.
>
>
> \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
> \[Please describe your issue here\]
>
>
> In light of recent events\, including CVE\-2016\-1238\, I propose
changing
> the default perl build to not include \. in @&#8203;INC\.
>
> There are multiple approaches to making this happen\. The approach

we

> took at cPanel was to inject an environment variable
> PERL\_USE\_UNSAFE\_INC=1 into CPAN clients as well as EU&#8203;::MM\, M&#8203;::B\.
>

Can you explain why you chose to do this in these locations?  \(I
realize you probably have already done so in other threads or on
IRC\, but since we're consolidating the discussion here\, I'd like
your reasoning to be clear to people just coming upon this
discussion\.\)

There are essentially 2 kinds of breakages in the toolchain​:
* configure time (mainly Module​::Install, and a few others but not many).
* testing time (mainly libs directly under t/ instead of using an
explicit
t/lib).

Injecting the environmental variable in the CPAN clients fixes both
issues,
but only for people who are using CPAN clients. Which is thankfully the
vast majority of people but there are people and situations that require
manual installs.

Injecting in the install tool can only fix testing issues, but can
actually
fix them for all users, including manual ones.

To me the first approach is more valuable than the second one, but
there's

Manually installing non-updated Module​::Install dists will be the painful
quadrant no matter what. Module​::Install is a gift that keeps on giving.

I'd like to ping this again. :)

I'm working on a patch to Test​::Harness that should solve the test-time
issue (and shouldn't require any further modification to
ExtUtils​::MakeMaker or Module​::Build). The CPAN client patches are the more
important ones though IMO.

Leon

@p5pRT
Copy link
Author

p5pRT commented Jan 16, 2017

From @Leont

On Sun, Jan 1, 2017 at 9​:07 PM, Todd Rinaldo via RT <
perlbug-followup@​perl.org> wrote​:

Manually installing non-updated Module​::Install dists will be the painful
quadrant no matter what. Module​::Install is a gift that keeps on giving.

Yeah, I propose a holy crusade to eradicate M​:I similar to what they're
trying to do with Polio :)

Todd

Yeah, though having a clear description of for to fix it without switching
away from Module​::Install is also valuable. I think
«use Config; BEGIN { push @​INC, '.' if $Config{default_inc_excludes_dot};
}» would be the clearest workaround.

Leon

@p5pRT
Copy link
Author

p5pRT commented Jan 16, 2017

From @toddr

On Sun, 15 Jan 2017 02​:52​:51 -0800, xsawyerx@​gmail.com wrote​:

I'd like to ping this again. :)

I have pinged the CPAN-workers mailing list about this. If I get no reply, I'm just going to go ahead with the environment variable fix and submit the fixes to the relevant modules.

http​://www.nntp.perl.org/group/perl.cpan.workers/2017/01/msg1523.html

Todd

@p5pRT
Copy link
Author

p5pRT commented Jan 21, 2017

From @toddr

Module​::Build patch submitted here​: Perl-Toolchain-Gang/Module-Build#69

@p5pRT
Copy link
Author

p5pRT commented Jan 21, 2017

From @toddr

ExtUtils​::MakeMaker patch submitted here​: Perl-Toolchain-Gang/ExtUtils-MakeMaker#283

@p5pRT
Copy link
Author

p5pRT commented Jan 23, 2017

From @jkeenan

On Mon, 16 Jan 2017 15​:34​:24 GMT, LeonT wrote​:

On Sun, Jan 1, 2017 at 9​:07 PM, Todd Rinaldo via RT <
perlbug-followup@​perl.org> wrote​:

Manually installing non-updated Module​::Install dists will be the
painful
quadrant no matter what. Module​::Install is a gift that keeps on
giving.

Yeah, I propose a holy crusade to eradicate M​:I similar to what
they're
trying to do with Polio :)

Todd

Yeah, though having a clear description of for to fix it without
switching
away from Module​::Install is also valuable. I think
«use Config; BEGIN { push @​INC, '.' if
$Config{default_inc_excludes_dot};
}» would be the clearest workaround.

Leon

Should we need to do bulk creation of rt.cpan.org bug tickets for this purpose, the following program will get us part of the way there​:

https://github.com/jkeenan/cpan-mini-visit-simple/blob/master/examples/module-install-130467.pl

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Jan 24, 2017

From @toddr

One of the common feedback on patches is that PERL_USE_UNSAFE_INC should not be injected if the environment variable exists in any form when the injection point is hit. This gives people control of disabling the work around and seeing the fail in its full glory.

I could envision updating dzil to set PERL_USE_UNSAFE_INC=0 so that development fails and is quickly fixed as a result.

@p5pRT
Copy link
Author

p5pRT commented Jan 24, 2017

From @toddr

Module​::Build​::Tiny patch - Perl-Toolchain-Gang/module-build-tiny#22

@p5pRT
Copy link
Author

p5pRT commented Jan 24, 2017

From @toddr

I declared myself dumb for scripts/cpan and reported to the issues queue to see if I could get some advice.

andk/cpanpm#108

@p5pRT
Copy link
Author

p5pRT commented Jan 31, 2017

From @toddr

cpanm patch was submitted here​: miyagawa/cpanminus#521

@p5pRT
Copy link
Author

p5pRT commented Feb 6, 2017

From @toddr

So I have cancelled the pull requests for Module​::Build, Module​::Build​::Tiny, and ExtUtils​::MakeMaker. It appears that the majority of issues can be addressed by​:

1. Merge this release into core​: https://metacpan.org/release/LEONT/Test-Harness-3.37_01
2. Make it so Module​::Install is always installed to the local perl so that use inc​::Module​::Install is always available outside of the local directory.
3. Track and fix what remains broken. At this time I've reported about 20 modules that are broken. There are definitely more but I think it's still a manageable number.

If we can solve number 2, then I can't think of anything blocking the suggested action in this ticket of changing the default build option to not include . in @​INC.

One concern raised so far is that while shipping M​::I with perl would solve the problem, it might indicate that p5p endorses the use of Module​::Install. Karen has pointed out to me that we already explicitly discourage new use of this module so that should not be a significant issue?

@p5pRT
Copy link
Author

p5pRT commented Feb 8, 2017

From @xsawyerx

On 02/06/2017 08​:40 PM, Todd Rinaldo via RT wrote​:

So I have cancelled the pull requests for Module​::Build, Module​::Build​::Tiny, and ExtUtils​::MakeMaker. It appears that the majority of issues can be addressed by​:

1. Merge this release into core​: https://metacpan.org/release/LEONT/Test-Harness-3.37_01
2. Make it so Module​::Install is always installed to the local perl so that use inc​::Module​::Install is always available outside of the local directory.
3. Track and fix what remains broken. At this time I've reported about 20 modules that are broken. There are definitely more but I think it's still a manageable number.

If we can solve number 2, then I can't think of anything blocking the suggested action in this ticket of changing the default build option to not include . in @​INC.

One concern raised so far is that while shipping M​::I with perl would solve the problem, it might indicate that p5p endorses the use of Module​::Install. Karen has pointed out to me that we already explicitly discourage new use of this module so that should not be a significant issue?

Including Module​::Install *does* implicitly encourage it. The only way
would be to document very very clearly that it should not be used. At
the same time, this also implies an adoption of this by p5p, even if to
slowly deprecate it.

This raises another question on my part​: Is the intention for this to be
for good, or for a period? If for a period, how long of a period?

@p5pRT
Copy link
Author

p5pRT commented Feb 8, 2017

From @toddr

On Wed, 08 Feb 2017 03​:02​:39 -0800, xsawyerx@​gmail.com wrote​:

Including Module​::Install *does* implicitly encourage it. The only way
would be to document very very clearly that it should not be used. At
the same time, this also implies an adoption of this by p5p, even if
to slowly deprecate it.

This raises another question on my part​: Is the intention for this to
be for good, or for a period? If for a period, how long of a period?

So the very ROUGH numbers I have are that ~3900 out of 35,000 modules on CPAN use Module​::Install. That's ~11% of CPAN. I'm not optimistic even Karen could get patched or adopt that many modules. This would probably be with us for some time. I got this by putting all of minicpan into a git repo and I know there are a few dupes. https://github.com/toddr/minicpan_grep

After talking with toolchain, the below idea has been floated. It would allow us to ship ONLY this one file and not M​::I with Perl. We could add docs, warnings, etc. to make it clear this is a shim ONLY for working around Module​::Install's incompatibility with . not being in @​INC.

https://gist.github.com/toddr/a0d877645575df5615cff30fcaf379ad

File​: lib/inc/Module/Install.pm
package Fake​::inc​::Module​::Install;

BEGIN {
  my $mi = "inc/Module/Install.pm";
  push @​INC, '.' if $INC[-1] ne '.';
  if( -e "./$mi") {
  require "./$mi";
  }
  else {
  die("Could not find inc/Module/Install.pm during module installation.");
  }
}

1;

@p5pRT
Copy link
Author

p5pRT commented Feb 8, 2017

From @jkeenan

On Wed, 08 Feb 2017 18​:28​:33 GMT, TODDR wrote​:

On Wed, 08 Feb 2017 03​:02​:39 -0800, xsawyerx@​gmail.com wrote​:

Including Module​::Install *does* implicitly encourage it. The only
way
would be to document very very clearly that it should not be used. At
the same time, this also implies an adoption of this by p5p, even if
to slowly deprecate it.

This raises another question on my part​: Is the intention for this to
be for good, or for a period? If for a period, how long of a period?

So the very ROUGH numbers I have are that ~3900 out of 35,000 modules
on CPAN use Module​::Install. That's ~11% of CPAN. I'm not optimistic
even Karen could get patched or adopt that many modules. This would
probably be with us for some time. I got this by putting all of
minicpan into a git repo and I know there are a few dupes.
https://github.com/toddr/minicpan_grep

After talking with toolchain, the below idea has been floated. It
would allow us to ship ONLY this one file and not M​::I with Perl. We
could add docs, warnings, etc. to make it clear this is a shim ONLY
for working around Module​::Install's incompatibility with . not being
in @​INC.

https://gist.github.com/toddr/a0d877645575df5615cff30fcaf379ad

File​: lib/inc/Module/Install.pm
package Fake​::inc​::Module​::Install;

BEGIN {
my $mi = "inc/Module/Install.pm";
push @​INC, '.' if $INC[-1] ne '.';
if( -e "./$mi") {
require "./$mi";
}
else {
die("Could not find inc/Module/Install.pm during module
installation.");
}
}

1;

Where would this file reside in the Perl 5 core distribution?

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Feb 8, 2017

From @ikegami

On Sat, Dec 31, 2016 at 12​:36 PM, Todd Rinaldo <perlbug-followup@​perl.org>
wrote​:

In light of recent events, including CVE-2016-1238, I propose changing
the default perl build to not include . in @​INC.

There are multiple approaches to making this happen. The approach we
took at cPanel was to inject an environment variable
PERL_USE_UNSAFE_INC=1 into CPAN clients as well as EU​::MM, M​::B.

This solved 95% of our issues. In discussions with #toolchain, they
have asked that we first assess the scope of failures on CPAN before
taking my suggested approach.

As I understand things, we must make a decision on this ticket,
ideally prior to 5.25.9.

It's my understanding the plan is to remove "." from @​INC (and that work
has already done to that effect), but that does nothing to address relative
paths added to @​INC. Those suffer from the same problem. Has anyone
considered making relative paths in @​INC relative to the script's dir
rather than the CWD, making C<< use lib "lib"; >> equivalent to something
like C<< use FindBin qw( ); use lib "$FindBin​::RealBin/lib"; >>?

@p5pRT
Copy link
Author

p5pRT commented Feb 8, 2017

From @toddr

On Wed, 08 Feb 2017 10​:40​:34 -0800, jkeenan wrote​:

On Wed, 08 Feb 2017 18​:28​:33 GMT, TODDR wrote​:

On Wed, 08 Feb 2017 03​:02​:39 -0800, xsawyerx@​gmail.com wrote​:

Including Module​::Install *does* implicitly encourage it. The only
way
would be to document very very clearly that it should not be used. At
the same time, this also implies an adoption of this by p5p, even if
to slowly deprecate it.

This raises another question on my part​: Is the intention for this to
be for good, or for a period? If for a period, how long of a period?

So the very ROUGH numbers I have are that ~3900 out of 35,000 modules
on CPAN use Module​::Install. That's ~11% of CPAN. I'm not optimistic
even Karen could get patched or adopt that many modules. This would
probably be with us for some time. I got this by putting all of
minicpan into a git repo and I know there are a few dupes.
https://github.com/toddr/minicpan_grep

After talking with toolchain, the below idea has been floated. It
would allow us to ship ONLY this one file and not M​::I with Perl. We
could add docs, warnings, etc. to make it clear this is a shim ONLY
for working around Module​::Install's incompatibility with . not being
in @​INC.

https://gist.github.com/toddr/a0d877645575df5615cff30fcaf379ad

File​: lib/inc/Module/Install.pm
package Fake​::inc​::Module​::Install;

BEGIN {
my $mi = "inc/Module/Install.pm";
push @​INC, '.' if $INC[-1] ne '.';
if( -e "./$mi") {
require "./$mi";
}
else {
die("Could not find inc/Module/Install.pm during module
installation.");
}
}

1;

Where would this file reside in the Perl 5 core distribution?

At the moment, I'm actually thinking lib/inc/Module/Install.pm. The assumption is that this would install to PRIVLIB and be overriden by site_lib.

The other item is we may only want to install this if . is missing from @​INC but that starts to get complicated.

@p5pRT
Copy link
Author

p5pRT commented Feb 9, 2017

From @toddr

MechaCPAN reported atrodo/App-MechaCPAN#3

@p5pRT
Copy link
Author

p5pRT commented Feb 12, 2017

From @xsawyerx

On 02/08/2017 08​:28 PM, Todd Rinaldo via RT wrote​:

On Wed, 08 Feb 2017 03​:02​:39 -0800, xsawyerx@​gmail.com wrote​:

Including Module​::Install *does* implicitly encourage it. The only way
would be to document very very clearly that it should not be used. At
the same time, this also implies an adoption of this by p5p, even if
to slowly deprecate it.

This raises another question on my part​: Is the intention for this to
be for good, or for a period? If for a period, how long of a period?
So the very ROUGH numbers I have are that ~3900 out of 35,000 modules on CPAN use Module​::Install. That's ~11% of CPAN. I'm not optimistic even Karen could get patched or adopt that many modules. This would probably be with us for some time. I got this by putting all of minicpan into a git repo and I know there are a few dupes. https://github.com/toddr/minicpan_grep

After talking with toolchain, the below idea has been floated. It would allow us to ship ONLY this one file and not M​::I with Perl. We could add docs, warnings, etc. to make it clear this is a shim ONLY for working around Module​::Install's incompatibility with . not being in @​INC.

https://gist.github.com/toddr/a0d877645575df5615cff30fcaf379ad

Considering this has been discussed exhaustively with toolchain, despite
the icky feeling that comes with it[1], I support this solution. I have
confidence and trust in toolchain's suggestion.

I would like to know if anyone objects to this. If not, we should
include it soon for 5.25.10.

[1] Shared by all included in the debate around it, as far as I've seen. :)

@p5pRT
Copy link
Author

p5pRT commented Feb 12, 2017

From @kentfredric

On 13 February 2017 at 00​:34, Sawyer X <xsawyerx@​gmail.com> wrote​:

Considering this has been discussed exhaustively with toolchain

It really hasn't by any stretch of imagination been discussed
"exhaustively", a few days discussion where this approach was "the
least repugnant", and alternative approaches that were less volatile
were dismissed.

This seems more apropos of "Hastily", not "Exhaustively".

And I'd imagine "Haste" is in application here because you want to
reach a conclusion before we hit feature freeze.

"Heatedly" discussed may also be correct.

But suggesting that this subject has been given a thorough dissection
and that we've reached the best conclusion after much thought is still
a very premature statement IMO.

Say what you want, do what you want, just don't try deceiving yourself
that this is "Good and well studied discussion", that's pure politics.

--
Kent

KENTNL - https://metacpan.org/author/KENTNL

@p5pRT
Copy link
Author

p5pRT commented Feb 12, 2017

From @xsawyerx

On 02/13/2017 12​:12 AM, Kent Fredric wrote​:

On 13 February 2017 at 00​:34, Sawyer X <xsawyerx@​gmail.com> wrote​:

Considering this has been discussed exhaustively with toolchain

It really hasn't by any stretch of imagination been discussed
"exhaustively", a few days discussion where this approach was "the
least repugnant", and alternative approaches that were less volatile
were dismissed.

This seems more apropos of "Hastily", not "Exhaustively".

And I'd imagine "Haste" is in application here because you want to
reach a conclusion before we hit feature freeze.

"Heatedly" discussed may also be correct.

But suggesting that this subject has been given a thorough dissection
and that we've reached the best conclusion after much thought is still
a very premature statement IMO.

Say what you want, do what you want, just don't try deceiving yourself
that this is "Good and well studied discussion", that's pure politics.

Kent, you are rash in your analysis.

You do not know about every conversation that takes place outside your
immediate view, but you continuously assume that unless you were a
witness to something, it did not happen and unless you accept something,
it is not good. I will not continue in these endless debates with you.
(And no further response of yours on this will be met by one of mine.)

@p5pRT
Copy link
Author

p5pRT commented Feb 12, 2017

From @kentfredric

On 13 February 2017 at 10​:21, Sawyer X <xsawyerx@​gmail.com> wrote​:

Kent, you are rash in your analysis.

You do not know about every conversation that takes place outside your
immediate view, but you continuously assume that unless you were a
witness to something, it did not happen and unless you accept something,
it is not good.

Then don't blame toolchain for making this decision dude. If it was
discussed in private behind closed doors, then it wasn't "Discussed
extensively with toolchain", unless there's a second toolchain called
"#toolchain-withoutkentnl".

Maybe you did discuss it extensively with some members who might be
considered toolchain.

But your assertion is it "has been discussed extensively with toolchain".

And that, based on the above arguments, suggests that you're making a
misleading statement.

--
Kent

KENTNL - https://metacpan.org/author/KENTNL

@p5pRT
Copy link
Author

p5pRT commented Feb 13, 2017

From @haarg

I have to second Kent here. "Toolchain" as an entity is #toolchain,
Perl-Toolchain-Gang, and the various mailing lists. The discussion
there around this certainly hasn't been extensive. And I personally
said that I wasn't comfortable with the inclusion of
inc​::Module​::Install.

There has been an increasing number of things that were discussed in
private but only brought to the list as "this is the conclusion." I
don't think that's really appropriate. Discussing things offline or
in other private places is obviously fine, but the results should be
brought to the list as arguments, not conclusions.

As for the direct issue of an inc​::Module​::Install shim, for CPAN the
most common use cases it won't be needed. CPAN clients will already
be setting the PERL_USE_UNSAFE_INC variable, and packagers will mostly
have to as well. The case it is really covering is running
Makefile.PL manually. Considering only CPAN dists, I'm not sure that
is an important enough use case to justify including it. It may be
worth it though given darkpan, such as code generated with
Catalyst​::Devel.

On Sun, Feb 12, 2017 at 5​:30 PM, Kent Fredric <kentfredric@​gmail.com> wrote​:

On 13 February 2017 at 10​:21, Sawyer X <xsawyerx@​gmail.com> wrote​:

Kent, you are rash in your analysis.

You do not know about every conversation that takes place outside your
immediate view, but you continuously assume that unless you were a
witness to something, it did not happen and unless you accept something,
it is not good.

Then don't blame toolchain for making this decision dude. If it was
discussed in private behind closed doors, then it wasn't "Discussed
extensively with toolchain", unless there's a second toolchain called
"#toolchain-withoutkentnl".

Maybe you did discuss it extensively with some members who might be
considered toolchain.

But your assertion is it "has been discussed extensively with toolchain".

And that, based on the above arguments, suggests that you're making a
misleading statement.

--
Kent

KENTNL - https://metacpan.org/author/KENTNL

@p5pRT
Copy link
Author

p5pRT commented Feb 13, 2017

From @xsawyerx

On 02/13/2017 12​:57 PM, Graham Knop wrote​:

I have to second Kent here. "Toolchain" as an entity is #toolchain,
Perl-Toolchain-Gang, and the various mailing lists. The discussion
there around this certainly hasn't been extensive. And I personally
said that I wasn't comfortable with the inclusion of
inc​::Module​::Install.

"Extensive" is admittedly far from the best description here, but the
essence of my comment (which was completely missed in order to make
claims of "it's all politics", which I strongly object to) is that we
have indeed raised *with* toolchain (both as individuals, as well as in
tickets, as well as in mailing lists, as well as on IRC - both to
individuals and in the main channel) this topic several times. Various
fixes had been suggested. No one is *happy* with the situation and the
any of the possible solutions, but the tone was "it seems toolchain has
reached a suggestion, and I support it".

Importantly enough, Kent's position is not "We need a bit more time on
this". His position, as stated in another email, is to make this change
at a "glacial" speed (quoting Kent), which means that no amount of
discussion that results in less than at least 2 additional releases for
this would be considered "enough time". This is besides my point
entirely and I have no intention of continuing such a conversation.

My point remains that I am willing to accept toolchain's position,
having reviewed several suggestions (so far at least three different
options I can count). I have previous made it abundantly clear on the
channel and directly to Leon T. that I do not have a specific solution I
want in mind, only for toolchain to reach to one which makes sense.

I *do not* want to muddle in the exact words used. Please accept my
undying apology for using the word "exhaustive". Now let's move on from
that word and please reflect on the main point of my position​: If this
is what toolchain found acceptable, I support that.

That is all.

There has been an increasing number of things that were discussed in
private but only brought to the list as "this is the conclusion." I
don't think that's really appropriate. Discussing things offline or
in other private places is obviously fine, but the results should be
brought to the list as arguments, not conclusions.

p5p has made it clear that it defers to toolchain for making a decision
on how best to treat CPAN on this issue. Toolchain has taken under it
the role of... the toolchain, and unless the desired solution receives
an objection from p5p, it will be accepted.

@p5pRT
Copy link
Author

p5pRT commented Feb 13, 2017

From @kentfredric

On 14 February 2017 at 00​:33, Sawyer X <xsawyerx@​gmail.com> wrote​:

Importantly enough, Kent's position is not "We need a bit more time on
this". His position, as stated in another email, is to make this change
at a "glacial" speed (quoting Kent), which means that no amount of
discussion that results in less than at least 2 additional releases for
this would be considered "enough time". This is besides my point
entirely and I have no intention of continuing such a conversation.

To clarify​: I don't have a fixed position, and that suggestion was
just that​: A suggestion.

Its simply an example of the sort of thing that *could* be done if we
simply changed what our priorities are.

It was in my mind, an ideal, a feasible strategy for the least amount
of breakage and giving affected people the most amount of time to
adapt.

The inc​:: approach here stands on a line between "lots of breakage"
and "slightly less than lots of breakage"

There may be strategies somewhere on that line between the inc​::
approach and the more glacial warn/die split phasing.

Just the perception given is that the inc​:: approach is "settled" now,
and that we're jumping at the approach without adequate pause.

And the pressure to create such a settlement is placed upon us by the
looming feature freeze, and I'm afraid we're going to hit
yet-another-last-minute-rush where contentious features land without
proper prepartation late in the cycle.

I'd we'd tackled this problem earlier in the development cycle, we'd
not be having this sensation of approaching panic.

We can't change that now, no time machine.

But using the "we have to because time" is something that is almost
guaranteed to force our hand in the direction of the worse choices.

I know you see me as "negative", and read me like I'm just nay-saying
everything, but there's so much more to it than that.

My point is usually to establish that there *are* other points on the
line, and maybe there are satisfactory points between existing points
that satisfies everyones concerns.

But that you see me myself as trying to establish a "this is how it
will be" is making you make counter-active assertions to the same
effect, much to my frustration, and probably to yours.

For the record, I have no direct opposition to inc​::Module​::Install
hiding in @​INC as per todds suggestions. The only problem I have is it
that its *not enough*, and leaves quite a few problem cases unsolved.

Those problem cases *could* in theory be fixed by submitting patches to CPAN.

The problem is there's no way to smoke and fix code outside CPAN, and
CPAN thus represents the very tip of this problem, not the problem
itself.

Hence, it is important to me that we at least properly explore options
in that direction, and we rather haven't to my understanding, hence
the frustration with it being described using that word ( it had a
quick-acting and visceral effect )

But for an example of something that I *might* reluctantly not oppose
( but please, don't hold me to it )

Some sort of mechanic that simply gives a better error message when
".pm file found in . but we're not gonna load it" happens, so at least
when things do barf unexpectedly, its not a complete confusion.

Or perhaps we can ascertain there are classes of "Less volatile" entry
points ( for instance, when the top level __FILE__ is =~ /.PL/ ) where
different behaviour may take place.

--
Kent

KENTNL - https://metacpan.org/author/KENTNL

@p5pRT
Copy link
Author

p5pRT commented Feb 14, 2017

From @Leont

On Mon, Feb 13, 2017 at 12​:33 PM, Sawyer X <xsawyerx@​gmail.com> wrote​:

My point remains that I am willing to accept toolchain's position,
having reviewed several suggestions (so far at least three different
options I can count). I have previous made it abundantly clear on the
channel and directly to Leon T. that I do not have a specific solution I
want in mind, only for toolchain to reach to one which makes sense.

I *do not* want to muddle in the exact words used. Please accept my
undying apology for using the word "exhaustive". Now let's move on from
that word and please reflect on the main point of my position​: If this
is what toolchain found acceptable, I support that.

That is all.

Toolchain is an even looser collection of people than p5p; unlike p5p it's
more of an archipelago of projects than a continent. Any kind of exhaustive
discussion is difficult to achieve before the toolchain summit (formerly
known as the QA Hackathon), and inconveniently that is scheduled later than
ever this year (mid-May). The toolchain organizational infrastructure is
not adapted to having to reach any conclusion with a deadline.

I may have missed some of the discussion on IRC, but I haven't seen a
discussion on a number of questions, including but not limited to​:
* Would we want to include this forever? If not, until when?
* Should this thing warn?
* What are the consequences of this inc​::Module​::Install being different
from the CPAN one? What if they converged?
* What to do about other modules that now break?
* What does this mean for our policy on including/ejecting modules?

Some of these questions are toolchain, some p5p, some both. All of them
need answers though.

Leon

@p5pRT
Copy link
Author

p5pRT commented Feb 14, 2017

From @toddr

On Tue, 14 Feb 2017 11​:37​:47 -0800, LeonT wrote​:

Toolchain is an even looser collection of people than p5p; unlike p5p it's
more of an archipelago of projects than a continent. Any kind of exhaustive
discussion is difficult to achieve before the toolchain summit (formerly
known as the QA Hackathon), and inconveniently that is scheduled later than
ever this year (mid-May). The toolchain organizational infrastructure is
not adapted to having to reach any conclusion with a deadline.

Yes I'm learning this the hard way. Is there any interest in changing
this? Given the priorities put on the toolchain to maintain stability
among other things. It's surprising to me there is no good forum
to have a discussion more frequently than once a year.

I may have missed some of the discussion on IRC, but I haven't seen a
discussion on a number of questions, including but not limited to​:
* Would we want to include this forever? If not, until when?

Given we're talking about ~3,700 dists on CPAN that would need to
be patched and re-released, I have no expectation this is ever going
to be fully solved. I could see some day deciding that the remaining
500 modules are unused or sufficiently broken that breaking their
installer isn't the end of the world at which point we could take it
out.

* Should this thing warn?

That should be easy to do. See line 6 in the updated gist
https://gist.github.com/toddr/a0d877645575df5615cff30fcaf379ad

* What are the consequences of this inc​::Module​::Install being different
from the CPAN one? What if they converged?

This module is more a shim with re-produces what the installed
Module​::Install module already does. With the exception of the
HIGHLY unlikely event that someone starts actively developing
on M​::I, I don't think there's any particular risk of divergence.

* What to do about other modules that now break?

I think the breakage is low enough that we just submit patches
and push for fixes. I have not gotten a final number but I think
it's going to only be a couple of hundred once you remove
M​::I from the list.

I am happy to get a solid number if that is the only outstanding hold
out for actioning this ticket.

* What does this mean for our policy on including/ejecting modules?

Given it's a shim, I don't think that's a major issue. We boot it out
when we think enough of CPAN is fixed right? Prior to that it's not
a big issue, is it?

Some of these questions are toolchain, some p5p, some both. All of them
need answers though.

p5p is easy. It can be discussed here.

I don't know how to get any sort of consensus from toolchain. However,
if I understand your governance model, only Karen should really have a
say in this given it is her module we're working around, right?

/me ducks.

Todd

@p5pRT
Copy link
Author

p5pRT commented Feb 14, 2017

From @kentfredric

On 15 February 2017 at 09​:10, Todd Rinaldo via RT
<perlbug-followup@​perl.org> wrote​:

Is there any interest in changing
this? Given the priorities put on the toolchain to maintain stability
among other things. It's surprising to me there is no good forum
to have a discussion more frequently than once a year.

We could consider the idea of a fortnightly, monthly, or bimonthly
formal meeting online somewhere.

As long as sufficient advance warning of said meeting is advertised to
enough channels, and with sufficient calls for agenda items, and
sufficient advance notice of agenda items, in conjunction with
archived copies of formal meeting logs and log summaries ("outcomes"),
it could be useful.

As I imagine that as long as we had them regularly scheduled and at a
well defined time, people who had vested interest in participation
could factor it into their scheduling if they're not able to keep on
top of all the things we do in an informal manner.

This would also double as a kind of transparency provider for people
outside the echo-chamber, as the logs and summaries would be something
3rd parties/vendors/LWN/etc could cite, whereas the overall nature of
toolchain at present is mostly "secret" if you're not part of the
constant IRC conversation. ( Of which a lot of is not relevant to
outsiders, and is merely dealing with specific and localised problems,
not wider ones )

I think such a strategy (or similar) would be a good adjunct to the
yearly summits, and at considerably lower cost and time investment.

--
Kent

KENTNL - https://metacpan.org/author/KENTNL

@p5pRT
Copy link
Author

p5pRT commented Feb 15, 2017

From @haarg

On Tue, Feb 14, 2017 at 4​:06 PM, Kent Fredric <kentfredric@​gmail.com> wrote​:

On 15 February 2017 at 09​:10, Todd Rinaldo via RT
<perlbug-followup@​perl.org> wrote​:

Is there any interest in changing
this? Given the priorities put on the toolchain to maintain stability
among other things. It's surprising to me there is no good forum
to have a discussion more frequently than once a year.

We could consider the idea of a fortnightly, monthly, or bimonthly
formal meeting online somewhere.

As long as sufficient advance warning of said meeting is advertised to
enough channels, and with sufficient calls for agenda items, and
sufficient advance notice of agenda items, in conjunction with
archived copies of formal meeting logs and log summaries ("outcomes"),
it could be useful.

As I imagine that as long as we had them regularly scheduled and at a
well defined time, people who had vested interest in participation
could factor it into their scheduling if they're not able to keep on
top of all the things we do in an informal manner.

This would also double as a kind of transparency provider for people
outside the echo-chamber, as the logs and summaries would be something
3rd parties/vendors/LWN/etc could cite, whereas the overall nature of
toolchain at present is mostly "secret" if you're not part of the
constant IRC conversation. ( Of which a lot of is not relevant to
outsiders, and is merely dealing with specific and localised problems,
not wider ones )

I'm not sure if frequent scheduled meetings are really appropriate for
this. It isn't often that something with such cross cutting concerns
comes up. Most things driving changes in toolchain are isolated to
the individual components, so I feel like meetings would not be well
attended. And that would end up being even more isolating than the
status quo of IRC being the closest we have to a focal point.

We definitely should do better in terms of visibility and
accessibility of toolchain concerns. We have a ton of mailing lists,
IRC, and various issue trackers, but there isn't a good common venue
for concerns like might be discussed at the Toolchain Summit. The
cpan.workers mailing list would probably be the most appropriate place
for discussion, but it has few subscribers. If I had to pick a place
for that kind of discussion right now, it might be the GitHub
toolchain-site issue tracker
(https://github.com/Perl-Toolchain-Gang/toolchain-site/issues).  It
hasn't been used that way, but maybe it could be.

I think the scheduling of the Toolchain Summit is working against us
as well. Being so close to the blead freeze and stable release makes
it hard for P5P to react to toolchain changes, and for toolchain to
react to changes in blead.

@p5pRT
Copy link
Author

p5pRT commented Feb 15, 2017

From @xsawyerx

On 02/15/2017 11​:00 AM, Graham Knop wrote​:

On Tue, Feb 14, 2017 at 4​:06 PM, Kent Fredric <kentfredric@​gmail.com> wrote​:

On 15 February 2017 at 09​:10, Todd Rinaldo via RT
<perlbug-followup@​perl.org> wrote​:

Is there any interest in changing
this? Given the priorities put on the toolchain to maintain stability
among other things. It's surprising to me there is no good forum
to have a discussion more frequently than once a year.
We could consider the idea of a fortnightly, monthly, or bimonthly
formal meeting online somewhere.

As long as sufficient advance warning of said meeting is advertised to
enough channels, and with sufficient calls for agenda items, and
sufficient advance notice of agenda items, in conjunction with
archived copies of formal meeting logs and log summaries ("outcomes"),
it could be useful.

As I imagine that as long as we had them regularly scheduled and at a
well defined time, people who had vested interest in participation
could factor it into their scheduling if they're not able to keep on
top of all the things we do in an informal manner.

This would also double as a kind of transparency provider for people
outside the echo-chamber, as the logs and summaries would be something
3rd parties/vendors/LWN/etc could cite, whereas the overall nature of
toolchain at present is mostly "secret" if you're not part of the
constant IRC conversation. ( Of which a lot of is not relevant to
outsiders, and is merely dealing with specific and localised problems,
not wider ones )
I'm not sure if frequent scheduled meetings are really appropriate for
this. It isn't often that something with such cross cutting concerns
comes up. Most things driving changes in toolchain are isolated to
the individual components, so I feel like meetings would not be well
attended. And that would end up being even more isolating than the
status quo of IRC being the closest we have to a focal point.

We definitely should do better in terms of visibility and
accessibility of toolchain concerns. We have a ton of mailing lists,
IRC, and various issue trackers, but there isn't a good common venue
for concerns like might be discussed at the Toolchain Summit. The
cpan.workers mailing list would probably be the most appropriate place
for discussion, but it has few subscribers. If I had to pick a place
for that kind of discussion right now, it might be the GitHub
toolchain-site issue tracker
(https://github.com/Perl-Toolchain-Gang/toolchain-site/issues).  It
hasn't been used that way, but maybe it could be.

I think the scheduling of the Toolchain Summit is working against us
as well. Being so close to the blead freeze and stable release makes
it hard for P5P to react to toolchain changes, and for toolchain to
react to changes in blead.

I think Kent and Graham are raising important issues here. Moving the
Toolchain Summit earlier on (definitely before any kind of freeze would
be valuable), having more transparency and communication is useful, and
official meetings can help as well. I think meetings don't have to be an
automated schedule thing but can be based solely on "Is there something
important to discuss". But having them is a very good idea.

I would like to raise one more issue that Todd and myself have observed
and discussed​: Toolchain lacks a person who is the one to contact when
something comes up. If an issue is raised, who's on point? Who leads the
effort? The reporter? The "lucky" person on IRC who read it first? The
first to reply? The person with the commit bit? The person with the
PAUSE rights? Who decides this? I would be happy if there was one (or
even more than one) direct person to contact and lead (or delegate
leading) an action plan to resolve a given issue. Todd's experience
seemed (both from the outside, and from the lists, and from the tickets,
and from IRC) to be running around a bit trying to figure out who says
"Yes" or "No" on something.

I would be happy if this is one thing toolchain changes as well, to make
it easier for us all to coordinate efforts.

@p5pRT
Copy link
Author

p5pRT commented Feb 15, 2017

From @kentfredric

On 15 February 2017 at 22​:32, Sawyer X <xsawyerx@​gmail.com> wrote​:

I think meetings don't have to be an
automated schedule thing but can be based solely on "Is there something
important to discuss". But having them is a very good idea.

My reasons for this idea stem more or less from your next comment and
how it plays out with the reality of being slightly more anarchic in
toolchain.

Basically, /because/ there is no central authority, some sort of
broadcast system to give interested parties fair warning that
"important discussion detailing X will happen, everyone who cares is
encouraged to be there"

Instead of relying on them being omnipresent and detecting it by
accident. ( Such notices could be spread to quite a few networks on
existing .MLs and pull in outsiders who aren't usually idling in
#toolchain )

But I won't force the idea, it just seems like something I'd expect to
happen already due to the size we are.

I would like to raise one more issue that Todd and myself have observed
and discussed​: Toolchain lacks a person who is the one to contact when
something comes up. If an issue is raised, who's on point? Who leads the
effort? The reporter? The "lucky" person on IRC who read it first? The
first to reply? The person with the commit bit? The person with the
PAUSE rights? Who decides this? I would be happy if there was one (or
even more than one) direct person to contact and lead (or delegate
leading) an action plan to resolve a given issue. Todd's experience
seemed (both from the outside, and from the lists, and from the tickets,
and from IRC) to be running around a bit trying to figure out who says
"Yes" or "No" on something.

I would be happy if this is one thing toolchain changes as well, to make
it easier for us all to coordinate efforts.

I guess it depends on the nature of the issue, if the issue only
affects one element of the system and has no side effects, then the
people to talk to are a narrower set.

The broader the impact, the more people who have to be involved
because it requires more tuit interactions.

Given the nature of toolchain, I don't think a "Central Authority"
model would really work for it, and maybe a roadmap for how to direct
various queries and expect their resolution would be better, with an
"If you have trouble navigating the roadmap, or the players in the
roadmap fail to play nicely with each other" fallback group of
contact.

Historically, I think toolchain has mostly been a "person with commit
bits makes a judgment call, except when there is yelling, and when
there is yelling, wait for the yelling to go away, and then make a
judgment call that results in the least yelling" ... more or less. Or
perhaps the person with most understanding of the problem leads the
discussion. ( The reporter is typically not good at divining the
solution, only defining the initial problem and then ascertaining if
the chosen solution satisfies it )

It seems disorganized, but I prefer to see it as "Self-Organised" :)

Sort of like when a small group of friends decide they want to go to a
pub/restaurant, but they start out with different opinions on which
pub/restaurant they want to go to. There's not necessarily a single
decider in charge, and the decision is just an emergent property, that
sometimes requires a bit of argumentation in order to equalize all the
different interests amicably. Its just when nobody can agree and a
stalemate appears that problems emerge.

Ultimately in order for collective success, all the individuals have
to make personal sacrifices of some type. Just on toolchain, that
sacrifice is "my san bits" most of the time :)

We should probably re-hash this stuff as a new P5P thread though.

--
Kent

KENTNL - https://metacpan.org/author/KENTNL

@p5pRT
Copy link
Author

p5pRT commented Feb 16, 2017

From @Leont

On Tue, Feb 14, 2017 at 9​:10 PM, Todd Rinaldo via RT
<perlbug-followup@​perl.org> wrote​:

Yes I'm learning this the hard way.

I'm sure that process has been exhausting to you :-/.

Is there any interest in changing
this? Given the priorities put on the toolchain to maintain stability
among other things. It's surprising to me there is no good forum
to have a discussion more frequently than once a year.

I can't think of any case where the stars aligned quite like they did
here. I don't think optimizing for once per decade events is fruitful.

Given we're talking about ~3,700 dists on CPAN that would need to
be patched and re-released, I have no expectation this is ever going
to be fully solved. I could see some day deciding that the remaining
500 modules are unused or sufficiently broken that breaking their
installer isn't the end of the world at which point we could take it
out.

It affects a lot of distributions, but fairly few users (installing
manually is already a painful experience in all but the simplest
cases).

* What are the consequences of this inc​::Module​::Install being different
from the CPAN one? What if they converged?

This module is more a shim with re-produces what the installed
Module​::Install module already does. With the exception of the
HIGHLY unlikely event that someone starts actively developing
on M​::I, I don't think there's any particular risk of divergence.

What if this shim was a CPAN distribution? Ironically but conveniently
the error message already literally says «you may need to install the
inc​::Module​::Install module», what if listening to what perl is
already telling you would solve the problem? It's the same error that
manual users would also get for anything using configure-requires
(e.g. anything using Module​::Build​::Tiny); installing it once would
permanently solve this issue for this userbase.

An important advantage is that this would actually allow for the shim
to be updated if necessary; core and CPAN's inc​::Module​::Install being
divergent would mean we can't update it, which is a major risk factor.

The main practical complication in this is that inc​::Module​::Install
already exists as part of Module​::Install. It actually does something
similar, but has rather different aims (targeting the author). I
suspect this ultimately won't be a major complication though.

And even if we would put it into core after releasing it to CPAN, this
would provide a credible exit-strategy once it's time to eject it.

Leon

@p5pRT
Copy link
Author

p5pRT commented Feb 16, 2017

From @xsawyerx

On 02/15/2017 01​:19 PM, Kent Fredric wrote​:

On 15 February 2017 at 22​:32, Sawyer X <xsawyerx@​gmail.com> wrote​:

I think meetings don't have to be an
automated schedule thing but can be based solely on "Is there something
important to discuss". But having them is a very good idea.
My reasons for this idea stem more or less from your next comment and
how it plays out with the reality of being slightly more anarchic in
toolchain.

Basically, /because/ there is no central authority, some sort of
broadcast system to give interested parties fair warning that
"important discussion detailing X will happen, everyone who cares is
encouraged to be there"

Instead of relying on them being omnipresent and detecting it by
accident. ( Such notices could be spread to quite a few networks on
existing .MLs and pull in outsiders who aren't usually idling in
#toolchain )

But I won't force the idea, it just seems like something I'd expect to
happen already due to the size we are.

My perspective on this is Whatever Works. You're in a better position
than I to determine what works. :)

I would like to raise one more issue that Todd and myself have observed
and discussed​: Toolchain lacks a person who is the one to contact when
something comes up. If an issue is raised, who's on point? Who leads the
effort? The reporter? The "lucky" person on IRC who read it first? The
first to reply? The person with the commit bit? The person with the
PAUSE rights? Who decides this? I would be happy if there was one (or
even more than one) direct person to contact and lead (or delegate
leading) an action plan to resolve a given issue. Todd's experience
seemed (both from the outside, and from the lists, and from the tickets,
and from IRC) to be running around a bit trying to figure out who says
"Yes" or "No" on something.

I would be happy if this is one thing toolchain changes as well, to make
it easier for us all to coordinate efforts.
[...]

We should probably re-hash this stuff as a new P5P thread though.

I agree.

@p5pRT
Copy link
Author

p5pRT commented Feb 17, 2017

From @toddr

On Wed, 15 Feb 2017 16​:09​:31 -0800, LeonT wrote​:

Given we're talking about ~3,700 dists on CPAN that would need to
be patched and re-released, I have no expectation this is ever going
to be fully solved. I could see some day deciding that the remaining
500 modules are unused or sufficiently broken that breaking their
installer isn't the end of the world at which point we could take it
out.

It affects a lot of distributions, but fairly few users (installing
manually is already a painful experience in all but the simplest
cases).

If I can get consensus, I'm totally cool with actioning this case (flipping default installs to not include . in @​INC by default) on top of a merge of the CPAN.pm and Test​::Harness changes already released to CPAN.

Leon, it sounds like this is what you're suggesting?

We could then submit patches to the ~3700 modules just as a courtesy.

As for the shim on CPAN, I don't see that it would make sense, since anyone who needs this simply needs to bootstrap Module​::Install to work around it.

Todd

@p5pRT
Copy link
Author

p5pRT commented Mar 6, 2017

From @jkeenan

On Fri, 17 Feb 2017 01​:24​:17 GMT, TODDR wrote​:

On Wed, 15 Feb 2017 16​:09​:31 -0800, LeonT wrote​:

Given we're talking about ~3,700 dists on CPAN that would need to
be patched and re-released, I have no expectation this is ever
going
to be fully solved. I could see some day deciding that the
remaining
500 modules are unused or sufficiently broken that breaking their
installer isn't the end of the world at which point we could take
it
out.

It affects a lot of distributions, but fairly few users (installing
manually is already a painful experience in all but the simplest
cases).

If I can get consensus, I'm totally cool with actioning this case
(flipping default installs to not include . in @​INC by default) on top
of a merge of the CPAN.pm and Test​::Harness changes already released
to CPAN.

Leon, it sounds like this is what you're suggesting?

We could then submit patches to the ~3700 modules just as a courtesy.

As for the shim on CPAN, I don't see that it would make sense, since
anyone who needs this simply needs to bootstrap Module​::Install to
work around it.

Todd

We're at the point where, to go forward with this for perl-5.26.0, we need to merge what we've got into blead so that we can do a monthly dev release that can serve as the basis for CPANtesters to do a complete traversal of CPAN.

Who is going to do that? When?

Thank you very much.
--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Mar 20, 2017

From @jkeenan

On Mon, 06 Mar 2017 14​:22​:16 GMT, jkeenan wrote​:

On Fri, 17 Feb 2017 01​:24​:17 GMT, TODDR wrote​:

On Wed, 15 Feb 2017 16​:09​:31 -0800, LeonT wrote​:

Given we're talking about ~3,700 dists on CPAN that would need to
be patched and re-released, I have no expectation this is ever
going
to be fully solved. I could see some day deciding that the
remaining
500 modules are unused or sufficiently broken that breaking their
installer isn't the end of the world at which point we could take
it
out.

It affects a lot of distributions, but fairly few users (installing
manually is already a painful experience in all but the simplest
cases).

If I can get consensus, I'm totally cool with actioning this case
(flipping default installs to not include . in @​INC by default) on
top
of a merge of the CPAN.pm and Test​::Harness changes already released
to CPAN.

Leon, it sounds like this is what you're suggesting?

We could then submit patches to the ~3700 modules just as a courtesy.

As for the shim on CPAN, I don't see that it would make sense, since
anyone who needs this simply needs to bootstrap Module​::Install to
work around it.

Todd

We're at the point where, to go forward with this for perl-5.26.0, we
need to merge what we've got into blead so that we can do a monthly
dev release that can serve as the basis for CPANtesters to do a
complete traversal of CPAN.

Who is going to do that? When?

Thank you very much.

I'm attaching a file derived from reviewing 'git log' in blead since Feb 20, i.e., since the release of perl-5.25.10. I examined the commit messages to see if they pertained to the subject of this ticket.

Are there any other steps we need to take for this ticket before marking it 'Resolved' or, perhaps 'Pending Release'?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Mar 20, 2017

From @jkeenan

commit a03e9f8
Author​: Dominic Hargreaves <dom@​earth.li>
AuthorDate​: 2017-02-21
Commit​: Dominic Hargreaves <dom@​earth.li>
CommitDate​: 2017-02-25

  Documentation fixes for '.' possibly no longer being in @​INC

commit 3137772
Author​: Aaron Crane <arc@​cpan.org>
AuthorDate​: 2017-02-25
Commit​: Aaron Crane <arc@​cpan.org>
CommitDate​: 2017-02-26

  Add "default_inc_excludes_dot" to "perl -V" output
 
  As proposed by Andreas Koenig++ in this message​:
 
  http​://www.nntp.perl.org/group/perl.perl5.porters/2017/02/msg243256.html

commit 458ea8f
Author​: Steve Hay <steve.m.hay@​googlemail.com>
AuthorDate​: 2017-03-12
Commit​: Steve Hay <steve.m.hay@​googlemail.com>
CommitDate​: 2017-03-12

  Make DEFAULT_INC_EXCLUDES_DOT the default on Windows
 
  and provide a makefile option of the same name to control it. It is set to
  'define' by default, but can be commented out or set to 'undef' in the
  usual manner to switch it off and return to the legacy default behaviour
  of including '.' at the end of @​INC.

commit 4634f48
Author​: Sawyer X <xsawyerx@​cpan.org>
AuthorDate​: 2017-03-14
Commit​: Sawyer X <xsawyerx@​cpan.org>
CommitDate​: 2017-03-14

  Turn on removal of dot in @​INC by default​:
 
  That's it. Dot no longer in @​INC.

commit 12e8377
Author​: Tony Cook <tony@​develop-help.com>
AuthorDate​: 2017-03-14
Commit​: Tony Cook <tony@​develop-help.com>
CommitDate​: 2017-03-14

  initialize default_inc_excludes_dot to '' like every variable
 
  Handling of the default is done further down.

ommit 2a0461a
Author​: Tony Cook <tony@​develop-help.com>
AuthorDate​: 2017-03-07
Commit​: Tony Cook <tony@​develop-help.com>
CommitDate​: 2017-03-14

  warn if do "somefile" fails when . not default in @​INC and somefile exists
 
  the message and warning category may need adjustment

commit c615971
Author​: Craig A. Berry <craigberry@​mac.com>
AuthorDate​: 2017-03-14
Commit​: Craig A. Berry <craigberry@​mac.com>
CommitDate​: 2017-03-14

  configure.com​: default_inc_excludes_dot catch-up
 
  This makes it configurable rather than hard-wired, and switches
  the default to "define" following 458ea8f, which did so
  on Windows, and 4634f48, which did so for platforms using
  Configure.

commit 025582b
Author​: Sawyer X <xsawyerx@​cpan.org>
AuthorDate​: 2017-03-18
Commit​: Sawyer X <xsawyerx@​cpan.org>
CommitDate​: 2017-03-18

  Fix copyright test​:
 
  Other tests are run from t/ and so they add ".." to @​INC, but
  this test runs from the main dir, so it needs to add ".".

commit b27c755
Author​: Aaron Crane <arc@​cpan.org>
AuthorDate​: 2017-03-19
Commit​: Aaron Crane <arc@​cpan.org>
CommitDate​: 2017-03-19

  Porting/sync-with-cpan​: handle absence of "." from @​INC

commit ffb91b6
Author​: Sawyer X <xsawyerx@​cpan.org>
AuthorDate​: 2017-03-19
Commit​: Sawyer X <xsawyerx@​cpan.org>
CommitDate​: 2017-03-19

  Update Test​::Harness 3.36 -> 3.38

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2017

From @iabyn

On Sun, Mar 19, 2017 at 05​:19​:52PM -0700, James E Keenan via RT wrote​:

On Mon, 06 Mar 2017 14​:22​:16 GMT, jkeenan wrote​:

On Fri, 17 Feb 2017 01​:24​:17 GMT, TODDR wrote​:

On Wed, 15 Feb 2017 16​:09​:31 -0800, LeonT wrote​:

Given we're talking about ~3,700 dists on CPAN that would need to
be patched and re-released, I have no expectation this is ever
going
to be fully solved. I could see some day deciding that the
remaining
500 modules are unused or sufficiently broken that breaking their
installer isn't the end of the world at which point we could take
it
out.

It affects a lot of distributions, but fairly few users (installing
manually is already a painful experience in all but the simplest
cases).

If I can get consensus, I'm totally cool with actioning this case
(flipping default installs to not include . in @​INC by default) on
top
of a merge of the CPAN.pm and Test​::Harness changes already released
to CPAN.

Leon, it sounds like this is what you're suggesting?

We could then submit patches to the ~3700 modules just as a courtesy.

As for the shim on CPAN, I don't see that it would make sense, since
anyone who needs this simply needs to bootstrap Module​::Install to
work around it.

Todd

We're at the point where, to go forward with this for perl-5.26.0, we
need to merge what we've got into blead so that we can do a monthly
dev release that can serve as the basis for CPANtesters to do a
complete traversal of CPAN.

Who is going to do that? When?

Thank you very much.

I'm attaching a file derived from reviewing 'git log' in blead since Feb 20, i.e., since the release of perl-5.25.10. I examined the commit messages to see if they pertained to the subject of this ticket.

Are there any other steps we need to take for this ticket before marking
it 'Resolved' or, perhaps 'Pending Release'?

As far as I can tell, there's nothing further needing doing to blead to
support dotless-inc by default in 5.26.0 (apart from the perldelta entry,
which being handled in a separate thread).

So I'll close this ticket tomorrow unless anyone objects.

This is the last open 5.26.0 blocker ticket. Whoo hoo!

--
I don't want to achieve immortality through my work...
I want to achieve it through not dying.
  -- Woody Allen

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2017

From @xsawyerx

On 04/18/2017 06​:24 PM, Dave Mitchell wrote​:

On Sun, Mar 19, 2017 at 05​:19​:52PM -0700, James E Keenan via RT wrote​:

On Mon, 06 Mar 2017 14​:22​:16 GMT, jkeenan wrote​:

On Fri, 17 Feb 2017 01​:24​:17 GMT, TODDR wrote​:

On Wed, 15 Feb 2017 16​:09​:31 -0800, LeonT wrote​:

Given we're talking about ~3,700 dists on CPAN that would need to
be patched and re-released, I have no expectation this is ever
going
to be fully solved. I could see some day deciding that the
remaining
500 modules are unused or sufficiently broken that breaking their
installer isn't the end of the world at which point we could take
it
out.
It affects a lot of distributions, but fairly few users (installing
manually is already a painful experience in all but the simplest
cases).
If I can get consensus, I'm totally cool with actioning this case
(flipping default installs to not include . in @​INC by default) on
top
of a merge of the CPAN.pm and Test​::Harness changes already released
to CPAN.

Leon, it sounds like this is what you're suggesting?

We could then submit patches to the ~3700 modules just as a courtesy.

As for the shim on CPAN, I don't see that it would make sense, since
anyone who needs this simply needs to bootstrap Module​::Install to
work around it.

Todd
We're at the point where, to go forward with this for perl-5.26.0, we
need to merge what we've got into blead so that we can do a monthly
dev release that can serve as the basis for CPANtesters to do a
complete traversal of CPAN.

Who is going to do that? When?

Thank you very much.
I'm attaching a file derived from reviewing 'git log' in blead since Feb 20, i.e., since the release of perl-5.25.10. I examined the commit messages to see if they pertained to the subject of this ticket.

Are there any other steps we need to take for this ticket before marking
it 'Resolved' or, perhaps 'Pending Release'?
As far as I can tell, there's nothing further needing doing to blead to
support dotless-inc by default in 5.26.0 (apart from the perldelta entry,
which being handled in a separate thread).

So I'll close this ticket tomorrow unless anyone objects.

This is the last open 5.26.0 blocker ticket. Whoo hoo!

\o/

@p5pRT p5pRT closed this as completed Apr 19, 2017
@p5pRT
Copy link
Author

p5pRT commented Apr 19, 2017

@iabyn - Status changed from 'open' to 'resolved'

@p5pRT
Copy link
Author

p5pRT commented Jun 1, 2017

From qd1qupwe.hs2@20minutemail.com

On Tue, 18 Apr 2017 12​:56​:28 -0700, xsawyerx@​gmail.com wrote​:

On 04/18/2017 06​:24 PM, Dave Mitchell wrote​:

On Sun, Mar 19, 2017 at 05​:19​:52PM -0700, James E Keenan via RT
wrote​:

On Mon, 06 Mar 2017 14​:22​:16 GMT, jkeenan wrote​:

On Fri, 17 Feb 2017 01​:24​:17 GMT, TODDR wrote​:

On Wed, 15 Feb 2017 16​:09​:31 -0800, LeonT wrote​:

Given we're talking about ~3,700 dists on CPAN that would need
to
be patched and re-released, I have no expectation this is ever
going
to be fully solved. I could see some day deciding that the
remaining
500 modules are unused or sufficiently broken that breaking
their
installer isn't the end of the world at which point we could
take
it
out.
It affects a lot of distributions, but fairly few users
(installing
manually is already a painful experience in all but the simplest
cases).
If I can get consensus, I'm totally cool with actioning this case
(flipping default installs to not include . in @​INC by default) on
top
of a merge of the CPAN.pm and Test​::Harness changes already
released
to CPAN.

Leon, it sounds like this is what you're suggesting?

We could then submit patches to the ~3700 modules just as a
courtesy.

As for the shim on CPAN, I don't see that it would make sense,
since
anyone who needs this simply needs to bootstrap Module​::Install to
work around it.

Todd
We're at the point where, to go forward with this for perl-5.26.0,
we
need to merge what we've got into blead so that we can do a monthly
dev release that can serve as the basis for CPANtesters to do a
complete traversal of CPAN.

Who is going to do that? When?

Thank you very much.
I'm attaching a file derived from reviewing 'git log' in blead since
Feb 20, i.e., since the release of perl-5.25.10. I examined the
commit messages to see if they pertained to the subject of this
ticket.

Are there any other steps we need to take for this ticket before
marking
it 'Resolved' or, perhaps 'Pending Release'?
As far as I can tell, there's nothing further needing doing to blead
to
support dotless-inc by default in 5.26.0 (apart from the perldelta
entry,
which being handled in a separate thread).

So I'll close this ticket tomorrow unless anyone objects.

This is the last open 5.26.0 blocker ticket. Whoo hoo!

\o/

Hello.
It's good that by default perl use default_inc_excludes_dot flag, but I can't find ways to switch perl to `unsafe mode` after installation.
Is there any plans to add perl switches to run perl in unsafe mode ? Setting 'default_inc_excludes_dot' => 0 in Config.pm don't switch perl execution too. I think both of them is good ways that can help to users turn perl to `localhost mode` (with perlrun switch no need in PERL_USE_UNSAFE_INC temporary crutch).
Thank You.

@p5pRT
Copy link
Author

p5pRT commented Jun 1, 2017

From [Unknown Contact. See original ticket]

On Tue, 18 Apr 2017 12​:56​:28 -0700, xsawyerx@​gmail.com wrote​:

On 04/18/2017 06​:24 PM, Dave Mitchell wrote​:

On Sun, Mar 19, 2017 at 05​:19​:52PM -0700, James E Keenan via RT
wrote​:

On Mon, 06 Mar 2017 14​:22​:16 GMT, jkeenan wrote​:

On Fri, 17 Feb 2017 01​:24​:17 GMT, TODDR wrote​:

On Wed, 15 Feb 2017 16​:09​:31 -0800, LeonT wrote​:

Given we're talking about ~3,700 dists on CPAN that would need
to
be patched and re-released, I have no expectation this is ever
going
to be fully solved. I could see some day deciding that the
remaining
500 modules are unused or sufficiently broken that breaking
their
installer isn't the end of the world at which point we could
take
it
out.
It affects a lot of distributions, but fairly few users
(installing
manually is already a painful experience in all but the simplest
cases).
If I can get consensus, I'm totally cool with actioning this case
(flipping default installs to not include . in @​INC by default) on
top
of a merge of the CPAN.pm and Test​::Harness changes already
released
to CPAN.

Leon, it sounds like this is what you're suggesting?

We could then submit patches to the ~3700 modules just as a
courtesy.

As for the shim on CPAN, I don't see that it would make sense,
since
anyone who needs this simply needs to bootstrap Module​::Install to
work around it.

Todd
We're at the point where, to go forward with this for perl-5.26.0,
we
need to merge what we've got into blead so that we can do a monthly
dev release that can serve as the basis for CPANtesters to do a
complete traversal of CPAN.

Who is going to do that? When?

Thank you very much.
I'm attaching a file derived from reviewing 'git log' in blead since
Feb 20, i.e., since the release of perl-5.25.10. I examined the
commit messages to see if they pertained to the subject of this
ticket.

Are there any other steps we need to take for this ticket before
marking
it 'Resolved' or, perhaps 'Pending Release'?
As far as I can tell, there's nothing further needing doing to blead
to
support dotless-inc by default in 5.26.0 (apart from the perldelta
entry,
which being handled in a separate thread).

So I'll close this ticket tomorrow unless anyone objects.

This is the last open 5.26.0 blocker ticket. Whoo hoo!

\o/

Hello.
It's good that by default perl use default_inc_excludes_dot flag, but I can't find ways to switch perl to `unsafe mode` after installation.
Is there any plans to add perl switches to run perl in unsafe mode ? Setting 'default_inc_excludes_dot' => 0 in Config.pm don't switch perl execution too. I think both of them is good ways that can help to users turn perl to `localhost mode` (with perlrun switch no need in PERL_USE_UNSAFE_INC temporary crutch).
Thank You.

@p5pRT
Copy link
Author

p5pRT commented Jun 1, 2017

From @jkeenan

On 06/01/2017 12​:07 PM, John Doe via RT wrote​:

On Tue, 18 Apr 2017 12​:56​:28 -0700, xsawyerx@​gmail.com wrote​:

On 04/18/2017 06​:24 PM, Dave Mitchell wrote​:

On Sun, Mar 19, 2017 at 05​:19​:52PM -0700, James E Keenan via RT
wrote​:

On Mon, 06 Mar 2017 14​:22​:16 GMT, jkeenan wrote​:

On Fri, 17 Feb 2017 01​:24​:17 GMT, TODDR wrote​:

On Wed, 15 Feb 2017 16​:09​:31 -0800, LeonT wrote​:

Given we're talking about ~3,700 dists on CPAN that would need
to
be patched and re-released, I have no expectation this is ever
going
to be fully solved. I could see some day deciding that the
remaining
500 modules are unused or sufficiently broken that breaking
their
installer isn't the end of the world at which point we could
take
it
out.
It affects a lot of distributions, but fairly few users
(installing
manually is already a painful experience in all but the simplest
cases).
If I can get consensus, I'm totally cool with actioning this case
(flipping default installs to not include . in @​INC by default) on
top
of a merge of the CPAN.pm and Test​::Harness changes already
released
to CPAN.

Leon, it sounds like this is what you're suggesting?

We could then submit patches to the ~3700 modules just as a
courtesy.

As for the shim on CPAN, I don't see that it would make sense,
since
anyone who needs this simply needs to bootstrap Module​::Install to
work around it.

Todd
We're at the point where, to go forward with this for perl-5.26.0,
we
need to merge what we've got into blead so that we can do a monthly
dev release that can serve as the basis for CPANtesters to do a
complete traversal of CPAN.

Who is going to do that? When?

Thank you very much.
I'm attaching a file derived from reviewing 'git log' in blead since
Feb 20, i.e., since the release of perl-5.25.10. I examined the
commit messages to see if they pertained to the subject of this
ticket.

Are there any other steps we need to take for this ticket before
marking
it 'Resolved' or, perhaps 'Pending Release'?
As far as I can tell, there's nothing further needing doing to blead
to
support dotless-inc by default in 5.26.0 (apart from the perldelta
entry,
which being handled in a separate thread).

So I'll close this ticket tomorrow unless anyone objects.

This is the last open 5.26.0 blocker ticket. Whoo hoo!

\o/

Hello.
It's good that by default perl use default_inc_excludes_dot flag, but I can't find ways to switch perl to `unsafe mode` after installation.

Just add '.' to @​INC. Contrast the output of​:

$ perl -E 'say $_ for @​INC;'

... with that of​:

$ perl -I. -E 'say $_ for @​INC;'

Is there any plans to add perl switches to run perl in unsafe mode ?

I know of no such plans and believe that such plans would be
inconsistent with the move to not having the current working directory
in @​INC.

Setting 'default_inc_excludes_dot' => 0 in Config.pm don't switch perl
execution too.

Config.pm is to a large extent just a record of what was decided during
compilation and build. I believe it is intended to be, in effect,
read-only. Hence, manually changing settings therein would not be the
way to go.

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented Jun 5, 2017

From @iabyn

On Thu, Jun 01, 2017 at 09​:07​:10AM -0700, John Doe via RT wrote​:

It's good that by default perl use default_inc_excludes_dot flag, but I
can't find ways to switch perl to `unsafe mode` after installation.
Is there any plans to add perl switches to run perl in unsafe mode ?
Setting 'default_inc_excludes_dot' => 0 in Config.pm don't switch perl
execution too. I think both of them is good ways that can help to users
turn perl to `localhost mode` (with perlrun switch no need in
PERL_USE_UNSAFE_INC temporary crutch).

There are no such plans.

If a particular script needs dot in in @​INC, then that script should be
modified to do "BEGIN { push @​INC, '.' }" or similar.

--
A problem shared is a problem doubled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant