Skip Menu |

This queue is for tickets about the CPAN CPAN distribution.

Report information
The Basics
Id: 116136
Status: open
Priority: 0/
Queue: CPAN
People
Owner: Nobody in particular
Requestors: zefram [...] fysh.org
Cc: ribasushi [...] leporine.io
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Thu Jul 14 02:06:17 2016 zefram [...] fysh.org - Ticket created
Subject: code rudely added to shell rc file
Date: Thu, 14 Jul 2016 07:06:05 +0100
To: bug-CPAN [...] rt.cpan.org
From: Zefram <zefram [...] fysh.org>
I have discovered in my ~/.zshrc file two identical stanzas of which I was not previously aware, both reading PATH="/home/zefram/perl5/bin${PATH+:}${PATH}"; export PATH; PERL5LIB="/home/zefram/perl5/lib/perl5${PERL5LIB+:}${PERL5LIB}"; export PERL5LIB; PERL_LOCAL_LIB_ROOT="/home/zefram/perl5${PERL_LOCAL_LIB_ROOT+:}${PERL_LOCAL_LIB_ROOT}"; export PERL_LOCAL_LIB_ROOT; PERL_MB_OPT="--install_base \"/home/zefram/perl5\""; export PERL_MB_OPT; PERL_MM_OPT="INSTALL_BASE=/home/zefram/perl5"; export PERL_MM_OPT; Some research suggests that this kind of code is generated by some version of local::lib, and that in some circumstances an auto-configuring CPAN.pm will get this from local::lib and *by default* append it to a shell rc file. This would then affect me by virtue of automated cpan runs, which necessarily get all-default behaviour. (I didn't intend to run CPAN.pm without a CPAN::Config in place, but I think this happened by accident somewhere.) The practical upshot of this edit to my rc file is that all cpan installations from subsequently-opened shells fail, because they're all installing to this bogus ~/perl5 directory, which is not only the wrong place but necessarily fails when it's shared between all the binary-incompatible perls that I have installed. Editing the user's shell rc file is a very rude and hideously broken default behaviour. Keep your grubby mitts off such files, unless positively invited by the user. -zefram
  Thu Jul 14 12:41:22 2016 dagolden [...] cpan.org - Correspondence added
Hi, Zefram. The code in question is here: https://metacpan.org/source/ANDK/CPAN-2.14/lib/CPAN/FirstTime.pm#L1362 If you look, you can see that it takes some steps to ensure that it prompts the user and does not automatically munge the shell without user approval. If you can demonstrate that it happens anyway without prompting under whatever cpan configuration environment you have, then it's certainly a bug. Otherwise, my hypothesis is that you might have been bouncing on the 'return' key and didn't see the note about shell munging specifically. :-) Regards, David
  Thu Jul 14 12:41:22 2016 The RT System itself - Status changed from 'new' to 'open'
  Thu Jul 14 12:53:18 2016 zefram [...] fysh.org - Correspondence added
Subject: Re: [rt.cpan.org #116136] code rudely added to shell rc file
Date: Thu, 14 Jul 2016 17:53:06 +0100
To: David Golden via RT <bug-CPAN [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
David Golden via RT wrote: Show quoted text
>If you look, you can see that it takes some steps to ensure that it >prompts the user and does not automatically munge the shell without >user approval.
That's not the same as user invitation. Show quoted text
>Otherwise, my hypothesis is that you might have been bouncing on the >'return' key and didn't see the note about shell munging specifically. :-)
As I said, I run cpan unmanned. I have an infinite stream of newlines fed into stdin to accept all defaults. My complaint is that your default is rude. You shouldn't be editing a user's rc files without some *positive* invitation from the user. -zefram
  Thu Jul 14 13:30:48 2016 zefram [...] fysh.org - Correspondence added
Subject: Re: [rt.cpan.org #116136] code rudely added to shell rc file
Date: Thu, 14 Jul 2016 18:30:31 +0100
To: David Golden via RT <bug-CPAN [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
I wrote: Show quoted text
>As I said, I run cpan unmanned. I have an infinite stream of newlines >fed into stdin to accept all defaults.
I've looked into this some more, and I can reproduce a form of the rc file editing (not identical to what I saw before, but close) by running cpan(1) for my system perl as non-root. It happens with either the newline input or with PERL_MM_USE_DEFAULT=1 in the environment. Either of these conditions is requesting defaults; I normally use the low-tech former because some modules aren't sophisticated enough to act on the latter. (The editing is also happening to the wrong file, which threw me a bit earlier in the investigation. The code that selects the victim file intends to select .zshenv for zsh users, but it's getting .zshrc. This is because of a precedence problem with the map expressions building up the table of rc file names.) I reiterate: editing the user's shell rc files is not an acceptable default behaviour. It is not an acceptable outcome from an unmanned run. Any `helpful' behaviour that's this intrusive needs to be invoked on an opt-in basis; it is not sufficient that the user didn't opt out. I didn't opt out of being punched in the face either; it's impossible to guess what else such rude code might decide to do on an opt-out basis. -zefram
  Thu Jul 14 14:02:42 2016 ribasushi [...] leporine.io - Correspondence added
On Thu Jul 14 19:30:48 2016, zefram@fysh.org wrote: Show quoted text
> > I reiterate: editing the user's shell rc files is not an acceptable > default behaviour. It is not an acceptable outcome from an unmanned run.
I agree with Zefram. A set PERL_MM_USE_DEFAULT=1 only gives a mandate to "accept defaults relating to stuff placed into PERL5LIB". Changing stuff around $HOME/ is neither expected nor welcome outcome of an installation executed under such environment. Tangentially: cpanm sets this by default https://github.com/miyagawa/cpanminus/blob/1.7042/lib/App/cpanminus/script.pm#L1249-L1250 https://github.com/miyagawa/cpanminus/blob/1.7042/lib/App/cpanminus/script.pm#L1276 https://github.com/miyagawa/cpanminus/blob/1.7042/lib/App/cpanminus/script.pm#L1295 I urge the authors to change the default of this and similar options to "no".
  Thu Jul 14 14:03:16 2016 ribasushi [...] leporine.io - Cc RIBASUSHI added
  Thu Jul 14 15:45:35 2016 ANDK [...] cpan.org - Correspondence added
If I understand correctly, what Zefram and Riba suggest boils down to this pseudo patch: - "\nWould you like me to append that to $rc now?", "yes" + "\nWould you like me to append that to $rc now?", "no" Is this right, David? Or would other parts of the system need also adjustment? And are there any arguments to not do it? I mean I tend to agree with them. It's certainly quite indicative for what users think about it. That this comes up 6 years since the code is out, tells me, they don't give a shit. Will they miss the assistance? Most probably not. What do you think?
  Wed Jul 27 07:31:29 2016 dagolden [...] cpan.org - Correspondence added
My opinion is that the purpose of defaults is to guide users -- particularly new users -- into useful outcomes. Changing the default increases the odds that new users will not wind up with a working CPAN client, which leads to unhappy new users and a poor impression of Perl. In the years since this was introduced, this has been the only complaint -- and from a highly experienced user who should know better than to blindly accept defaults without knowing *exactly* what they do. Piping newlines is tantamount to saying "I don't care what you do", so I don't find post hoc caring to be a convincing argument against the defaults. From the title alone to references like "punched in the face", this bug report seems to be one driven by shock and anger, rather than a rational consideration of what makes for the best first-time user experience for Perl itself, which is what the first-time code and defaults are designed to do. As far as I'm concerned, this can be closed "works as designed". An experienced user who wants to automate CPAN client configuration without the "new user" defaults is more than sufficiently skilled to construct or install a cpan MyConfig file tailor-made to their requirements.
  Wed Jul 27 07:32:10 2016 dagolden [...] cpan.org - Cc DAGOLDEN added
  Wed Jul 27 08:18:45 2016 ribasushi [...] leporine.io - Correspondence added
On Wed Jul 27 13:31:29 2016, DAGOLDEN wrote: Show quoted text
> In the years since this was introduced, this has been the only > complaint -- and from a highly experienced user who should know better > than to blindly accept defaults without knowing *exactly* what they > do. Piping newlines is tantamount to saying "I don't care what you > do", so I don't find post hoc caring to be a convincing argument > against the defaults.
But this is not what is being discussed (yes, this was the start of the conversation but it since moved on). David, I think you have also fallen victim to emotion. See it from this point of view instead: - A user who doesn't give a shit about perl wants to install some new app - They read its docs, see they need a perl not available on their machine - They get some feedback from the "community", and settle on perlbrew - Then they fire up the `cpanm App...` command as suggested by the luminaries - They do that, without ever having a .cpan dir - It turns out CPAN.pm itself is somewhere deep in the deptree (oh yes there are cases of this) - cpanm sets PERL_MM_USE_DEFAULT=1 and installs CPAN - user finds unknown crap in their rc-file, that is indistinguishable from some sort of exploit Now what is their opinion of perl...?
  Wed Jul 27 08:50:19 2016 zefram [...] fysh.org - Correspondence added
CC: ribasushi [...] cpan.org
Subject: Re: [rt.cpan.org #116136] code rudely added to shell rc file
Date: Wed, 27 Jul 2016 13:50:04 +0100
To: David Golden via RT <bug-CPAN [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
David Golden via RT wrote: Show quoted text
>Piping newlines is tantamount to saying "I don't care what you do",
No, as I explained that (or the equivalent PERL_MM_USE_DEFAULT=1) cannot be interpreted as a total lack of concern. If that were the interpretation, it would also be acceptable for the default behaviour to be to delete all the user's files. It's not acceptable: defaults need to be reasonable and germane. Accepting defaults en masse means "I am not considering this bit of software in detail". The very essence of automation is that the user doesn't need to hold the software's hand. Show quoted text
>this bug report seems to be one driven by shock and anger,
There is anger, yes. Anger that CPAN installation code has abused its very privileged position, in which it is frequently executed on other people's machines with little or no oversight, to damage users' environments. Show quoted text
>As far as I'm concerned, this can be closed "works as designed".
If that's considered a good design, then I don't want to ever run any code from this source ever again. What other horrors might be lurking in the guise of a default? -zefram
  Wed Jul 27 08:53:41 2016 dagolden [...] cpan.org - Correspondence added
On Wed Jul 27 08:18:45 2016, RIBASUSHI wrote: Show quoted text
> PERL_MM_USE_DEFAULT=1
That's trivially fixed by localizing that (around the same point that has comments about "must prompt even under autoconfig") rather than changing the default. Or doing the various contortions we've done before to avoid CPAN clients invoking CPAN clients -- e.g. bail out if PERL5_CPANM_IS_RUNNING or PERL5_CPANPLUS_IS_RUNNING. I don't think ignoring obvious solutions when the result doesn't achieve your ulterior goal is an effective argument strategy. It doesn't fool your audience and wastes our time. If you want to argue for an ulterior goal, you ought to address up-front why you think obvious solutions are insufficient to address the technical problems at hand. The default itself works as designed based on the design goals we discussed at the time. Bugs, of course, should be fixed. But if at the end of the day, this isn't really a technical argument and is just "my way" vs "your way", then stop pretending it isn't that and Andreas can decide whatever he wants.
  Wed Jul 27 09:02:19 2016 ribasushi [...] leporine.io - Correspondence added
Subject: Re: [rt.cpan.org #116136] code rudely added to shell rc file
Date: Wed, 27 Jul 2016 15:01:59 +0200
To: bug-CPAN [...] rt.cpan.org
From: Peter Rabbitson <ribasushi [...] cpan.org>
On 07/27/2016 02:53 PM, David Golden via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=116136 > > > On Wed Jul 27 08:18:45 2016, RIBASUSHI wrote:
>> PERL_MM_USE_DEFAULT=1
> That's trivially fixed by localizing that (around the same point that has comments about "must prompt even under autoconfig") rather than changing the default. Or doing the various contortions we've done before to avoid CPAN clients invoking CPAN clients -- e.g. bail out if PERL5_CPANM_IS_RUNNING or PERL5_CPANPLUS_IS_RUNNING.
This might very well be a way forward - I do not know the codebase sufficiently to make this call. Show quoted text
> I don't think ignoring obvious solutions when the result doesn't achieve your ulterior goal is an effective argument strategy. It doesn't fool your audience and wastes our time. If you want to argue for an ulterior goal, you ought to address up-front why you think obvious solutions are insufficient to address the technical problems at hand.
I have no ulterior goal here. I saw a report when it scrolled on #p5p, and chimed in as the ticket was getting warnocked. Show quoted text
> But if at the end of the day, this isn't really a technical argument and is just "my way" vs "your way", then stop pretending it isn't that and Andreas can decide whatever he wants.
I... do not understand where this pushback is coming from (and what is it meant to address), so I will just bow out of this discussion. Good luck.
  Wed Jul 27 09:04:53 2016 dagolden [...] cpan.org - Correspondence added
Zefram, you're repeating yourself and being offensive and I expect better of you. I don't see much point arguing utility functions in general, but certainly not when you're being like that. On Wed Jul 27 08:50:19 2016, zefram@fysh.org wrote: Show quoted text
> David Golden via RT wrote:
> >Piping newlines is tantamount to saying "I don't care what you do",
> > No, as I explained that (or the equivalent PERL_MM_USE_DEFAULT=1) > cannot be interpreted as a total lack of concern. If that were the > interpretation, it would also be acceptable for the default behaviour > to be to delete all the user's files. It's not acceptable: defaults > need to be reasonable and germane. Accepting defaults en masse means > "I am not considering this bit of software in detail". The very essence > of automation is that the user doesn't need to hold the software's hand. >
> >this bug report seems to be one driven by shock and anger,
> > There is anger, yes. Anger that CPAN installation code has abused > its very privileged position, in which it is frequently executed on > other people's machines with little or no oversight, to damage users' > environments. >
> >As far as I'm concerned, this can be closed "works as designed".
> > If that's considered a good design, then I don't want to ever run any > code from this source ever again. What other horrors might be lurking > in the guise of a default? > > -zefram
  Wed Jul 27 09:05:06 2016 dagolden [...] cpan.org - Cc DAGOLDEN deleted
  Wed Jul 27 09:08:53 2016 zefram [...] fysh.org - Correspondence added
CC: ribasushi [...] cpan.org
Subject: Re: [rt.cpan.org #116136] code rudely added to shell rc file
Date: Wed, 27 Jul 2016 14:08:34 +0100
To: David Golden via RT <bug-CPAN [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
David Golden via RT wrote: Show quoted text
>That's trivially fixed by localizing that
I think you're aiming for the effect of dishonouring PERL_MM_USE_DEFAULT for that question, requiring some stdin input, and you're intending that that would qualify as enforcing real human input. Under the most charitable interpretation, if it does force human input, that makes automated installations impossible, thus defeating a major goal of CPAN. Unattended installations should be possible. But in practice reading from stdin doesn't enforce human input; all it would do is put the CPAN distro into the class of distros that annoyingly don't honour PERL_MM_USE_DEFAULT which is the motivation for piping newlines. In that case the default is as default as it was before and still just as rude. If you really want to enforce that an installation going through the path involving this question cannot be done without specific human attention to this issue, then the way to do it is to terminate the installation process with a message instead of asking the question. Require a Makefile.PL parameter, specific to this issue, to be supplied in order to get past this point. (The parameter might answer the edit-your-rcfiles question, or might merely cause it to be asked interactively.) I don't think this would be a great default, but it would be better than editing rcfiles by default. -zefram
  Wed Jul 27 09:19:14 2016 zefram [...] fysh.org - Correspondence added
CC: ribasushi [...] cpan.org
Subject: Re: [rt.cpan.org #116136] code rudely added to shell rc file
Date: Wed, 27 Jul 2016 14:18:53 +0100
To: David Golden via RT <bug-CPAN [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
David Golden via RT wrote: Show quoted text
>Zefram, you're repeating yourself
I repeated what you seemed to have not grasped the first time. Show quoted text
>and being offensive
I'm finding it difficult to convey my view of the behaviour in question without running that risk. It is very offensive code behaviour, and does arouse strong emotion. -zefram
  Tue Sep 06 05:54:01 2016 KENTNL [...] cpan.org - Correspondence added

Just something to add here for a case I just spent half an hour diagnosing.

 

A user came to me where arbitrary code like `perl -Mstrict -e1` died with permissions denied issues for the "portage" user ( the user who runs package management tasks )

After a bit of digging, we eventually discovered that UID=portage was trying to read /home/$USER/perl because it was profoundly in @INC

And of course, "path in @INC without permissions" -> "Perl dies"

I'm not sure how it blead*[1], but the auto-injected ENV vars that were injected into the users bash profile without their knowledge, then bled into a context that affected their whole system, and discovered PERL5LIB=/home/USER/... was somehow set as ROOT and OTHERUSERS, breaking every perl call under OTHERUSERS

Granted most of this problem is in understanding how ENV blead through different users.

But it is also greatly exacerbated by code injecting its own magic into ~/.bashrc without peoples explicit decision.

But the point is security is never magic bullets, all layers.

And here, 2 layers collided causing something that was fortunately only an annoyance, but could have been much worse.

Violating one layer of security in seemingly naive and helpful ways to make things "Faster" hence lends itself to deeper problems.

( Because nobody would make the above mistakes on purpose, any argument that results in "well, just don't do that" would of course miss the point :) )

 

1: As soon as we'd discovered the bashrc bleading was to blame, they nuked it and fell off IRC, none of us had a clue *why* it was bleading, only that it was