Perl whipupitude to the rescue

It's been widely posted by now that 50,000 or so cleartext user names, email addresses and passwords were compromised from Perl Monks. Yesterday, as the news broke, a discussion started on IRC about how to respond. As some were debating hashing the exposed passwords and checking against other Perl community sites and various other remedies, I suggested that at a minimum, CPAN authors be notified so that they could change their PAUSE passwords if needed.

As the discussion swirled, I grabbed two modules from CPAN, whipped up a short script to email a warning to all CPAN authors and emailed it to Andreas, who manages CPAN & PAUSE. The elapsed time from concept to the email to Andreas, using two modules I'd never used before, including a test to my own email account, was probably 15 minutes. Andreas picked it up a couple hours later and started emailing CPAN Authors.

Here is the entire script:

#!/usr/bin/env perl
use 5.010;
use strict;
use warnings;
use Parse::CPAN::Authors;
use Email::Stuff;

my $mailrc = shift @ARGV;
die "usage: $0 <mailrc>\n" unless $mailrc && -f $mailrc;

my $pca = Parse::CPAN::Authors->new($mailrc);

my $body = << 'END_MAIL';
Dear CPAN author,

This email is being sent to inform you that all passwords on the popular
Perl Monks website were compromised.  Many CPAN authors have accounts
there and in some cases have used the same password for PAUSE.

If you have any reason to suspect that your PAUSE account password
is no longer secure, please visit http://pause.cpan.org/ and change it.

If your PAUSE account is not affected, please disregard this message and
accept apologies for the unsolicited email.

Regards,
PAUSE Administrators
END_MAIL

for my $author ( $pca->authors ) {
  Email::Stuff->from     ('module@perl.org'                  )
              ->to       ($author->pauseid . '@cpan.org'     )
              ->subject  ("Perl Monks compromised, PAUSE accounts at risk")
              ->text_body($body                              )
              ->send;
}

(If you're a CPAN Author, the text should be familiar to you as you either got it yesterday, don't have a current email address on PAUSE, or it got caught in your spam folder.)

So even as the community appreciates the value of "modern" Perl, it's good to remember that Perl and CPAN still rock when you need a quick solution to a problem.

This entry was posted in cpan, perl programming and tagged . Bookmark the permalink. Both comments and trackbacks are currently closed.

8 Comments

  1. Purdy
    Posted July 30, 2009 at 7:39 am | Permalink

    Yeah, but can you do it as a one-liner? ;)

    Thanks for the heads-up!

  2. Ken Williams
    Posted July 30, 2009 at 2:42 pm | Permalink

    Somehow I didn't get the email, though my CPAN/PAUSE addresses are current. The mailer isn't still running, is it?

  3. Jan Dubois
    Posted July 30, 2009 at 2:54 pm | Permalink

    Are you sure the script has run to completion yet? I have not received any such notification. I get RT notifications to my @cpan.org address without problem, so I know the email is settup correctly.

    • david
      Posted July 30, 2009 at 6:23 pm | Permalink

      I only know that Andreas ran it. I also know that PAUSE went down at some point. Hopefully coincidental and not that the sysadmins though that thousands of emails sent in a burst was a problem. :-)

  4. Jim Keenan
    Posted August 2, 2009 at 10:51 am | Permalink

    To the best of my knowledge, I have yet to receive the email from PAUSE. I did, however, take the precaution of changing my PAUSE password.

  5. Lars Balker Rasmussen
    Posted August 3, 2009 at 9:25 am | Permalink

    I just got the email. For time-sensitive stuff, this is probably not the best way to send out that amount of email :-)


    Received: from pause.fiz-chemie.de (HELO pause.perl.org) (195.149.117.110) by 16.mx.develooper.com (qpsmtpd/0.80) with ESMTP; Mon, 03 Aug 2009 08:25:03 -0700
    Received: from pause.perl.org (localhost.localdomain [127.0.0.1]) by pause.perl.org (8.13.8/8.13.8/Debian-3) with ESMTP id n6TL86Kq000381 for ; Wed, 29 Jul 2009 23:08:06 +0200

  6. Posted August 11, 2009 at 11:13 pm | Permalink

    If you'd used CPANDB you wouldn't even need to provide the author file as an argument.

  7. tgape
    Posted August 14, 2009 at 7:10 pm | Permalink

    Email queuing is somewhat esoteric. Sendmail's recommended configurations, specifically, are only usable for low-volume systems. Even on my home system, I find I get better performance by using significantly different configs. Specifically, Sendmail's 'background' delivery mode is just plain wrong. I don't know if they still recommend this, but they shouldn't - I've shown them plenty of evidence (reports of benchmarks) which indicate it doesn't offer better performance than 'interactive' in best-case scenarios, it's not much better than 'queueonly' or 'deferred' if they're actually configured to be competitive, and under high volume, it breaks. Badly.

    Also note, if the email was not customized per recipient, you get *much* better performance by including multiple recipients on each body - 95+% of the work is typically on processing the message body, so if you put 10 recipients per body, so that you only have 5k message bodies, you've cut off over 80% of the work. Your MTA can split the message out to the multiple destinations just fine. Even if none of the recipients on a particular message body are on the same destination server, getting it to your own server as one body will save significantly. It only needs to be spam processed once, it only needs to be virus-scanned once, and it only needs to be queued once. Most MTAs can handle 100 recipients per message or more. If downstream MTAs cannot handle it, but they are standards compliant, your MTA will split the message just fine. As such, if your MTA can handle 100 recipients per message, you can easily save over 98% of the message processing... (Disclaimer: really old Notes systems have a bug. Anyone still running Notes 5.x could have issues, under certain uncommon configurations. As I understand it, Notes 6.x, 7.x, and 8.x do not have that issue. Also note, that configuration was *always* misguided/wrong, and anyone *still* running under it should've already found the need to reduce their MaxRecipients setting to something very low, which mitigates it entirely.)

    Sorry for the long response - former postmaster.

© 2009-2014 David Golden All Rights Reserved