Naughty CPAN Modules

Ovid on 2006-09-13T13:35:16

You know, I don't feel comfortable that this test.pl file automatically tries to email the author of the module when installed via cpan or cpanplus. I suppose it's not a big deal for most folks, but it really bugs me when automated things do stuff I'm not expecting.


Negative score at CPANTS?

ferreira on 2006-09-13T13:50:07

What about a CPANTS rule "phone_home" which implies a penalty (negative score) for those modules? Well the problem is how to determine it is phoning home - should be hard to automate such detection. Well, right now, I think that a note at CPAN ratings would be better than nothing.

Talk to the author

ferreira on 2006-09-13T13:57:45

Hey, I saw people like this module (see Mail-Sendmail reviews at CPAN ratings). Maybe discussing with the author to change the code to ask permission or SKIP test unless a certain environment variable was defined could be a fast solution.

phone_home on a mail module?

dagolden on 2006-09-13T14:14:23

Normally, I'm totally opposed to a "phone_home" attempt hidden in a module, but this is for sendmail and it's in a test file.

Moreover, the author has this disclaimer:

# unattended Mail::Sendmail test, sends a message to the author
# but you probably want to change $mail{To} below
# to send the message to yourself.

So this one doesn't bother me so much, as it seems well-intended as part of a test instead of being something for tracking purposes.

There's probably a clever ways to test without actually needing to send a message (e.g. mocking the system call to sendmail) or some better prompting ("Do you want to send a test message? Message address (default is author)?"). Maybe sending a patch for the test file would be accepted by the author.

Re:phone_home on a mail module?

Ovid on 2006-09-13T14:20:59

The disclaimer doesn't matter much when you're running cpanplus and you see it scroll past and there's nothing you can do about it. Also, I'm sure there are plenty of folks who can think of reasons why they don't want email automatically sent, whether they saw a warning message flash by or not.

And yes,someone (possibly me since I'm grumbling) should offer a patch. At the very least, something which prompts the person "do you really want to send an email?"

Re:phone_home on a mail module?

Abigail on 2006-09-13T21:32:03

It might me just me, but if such mails bother you, perhaps you shouldn't blindly run software you downloaded from the web. Automatically even.

Re:phone_home on a mail module?

link on 2006-09-13T14:23:28

There is a warning when Makefile.PL is run but not very much time to cancel out if you really do not like the idea. A prompt would be nice.
Not really too naughty , well compared to the CPAN module that (used to?) downloads some perl code from the authors website and eval it.

Best way to do it?

Matts on 2006-09-13T14:36:34

I've often wanted to know when people install one of my modules. Do you have a suggestion of a good way to do it? I was thinking of something like:
local $SIG{ALARM} = sub { die "alarm" };
alarm(5);
print "[This question will timeout in 5 seconds and default to 'No']\n";
my $val = eval { prompt("Send message to module author that you installed $module?", "Y") };
$val = "N" if $@;
if ($val =~ /^Y/i) {
     send_udp_packet_to_sergeant_dot_org();
}
Would that be reasonable?

Re:Best way to do it?

tsee on 2006-09-13T15:23:30

It might be reasonable if alarm() was portable!

On the other hand, tracking users is probably as futile as web hit counters.

Re:Best way to do it?

Matts on 2006-09-13T15:46:16

I thought the non-portability of alarm() was a solved problem? At least for simple cases like reading STDIN.

Re:Best way to do it?

tsee on 2006-09-13T16:34:37

Well, as far as I know, alarm() doesn't work on win32. But I may well be wrong since I haven't tried it for some time.

Re:Best way to do it?

Matts on 2006-09-13T16:59:08

Works on cygwin. Not on Strawberry. Ah well, back to the drawing board.

Re:Best way to do it?

Ovid on 2006-09-13T15:28:58

I'd feel a lot more comfortable with that, but there's a better way. If you're using ExtUtil::MakeMaker (and I believe Module::Build offers the same functionality), then you can force a default if not running interactively. From the docs:

If prompt() detects that it is not running interactively and there is nothing on STDIN or if the PERL_MM_USE_DEFAULT environment variable is set to true, the $default will be used without prompting. This prevents automated processes from blocking on user input.

Re:Best way to do it?

Matts on 2006-09-13T15:48:10

Interesting. But I'd almost *rather* the user could choose even under the CPAN shell to not send the info (but still have the default be 'Y'). Hence the alarm() so that it only blocks for 5 seconds.

Re:Best way to do it?

Alias on 2006-09-14T03:37:49

A year or so ago I thrashed out a solution with #perl that sucked as little as possible, and was the least annoying thing we could come up with.

http://ali.as/devel/phonehome.html

Whenever anyone asks about CPAN statistics or phone home implmentations, I point them at that.

Although I have to say adding the idea of UDP is interesting and probably would add some value to it.

Re:Best way to do it?

grinder on 2006-09-14T15:47:39

Adam, I like the idea. I think it is well thought out and deserves to be pushed. My only suggestion, as a tip o' the hat to the FOAD crowd is that it the setting should default to 'never', not 'ask'.

The question can be asked the next time the config process is run, but defaulting to 'ask' is wrong, since you're now adding a new hoop to jump through by default, where none existed before.