In this node, I provided a patch for shellwords.pl. It seems that this program was silently untainting data. I submitted the patch to P5P, but in researching further, I discovered that Text::ParseWords had the same potential security hole. Further, it turns out that the CPAN.pm module uses this module. I attempted to contact the maintainer of Text::ParseWords with a patch, but it appears that pomeranz@netcom.com has disappeared into the aether. This is a core module, but I'm not sure that I should submit the patch to P5P.

What's the protocol for submitting a patch for a module that's not maintained? This seems a more significant issue since this module is part of the standard distribution. I've been trying to find information about this, but the P5P faq, CPAN, and PAUSE seem to have no information on this.

The patch, by the way:

--- ParseWords.pm.orig  Tue May 21 12:51:06 2002
+++ ParseWords.pm       Tue May 21 12:51:52 2002
@@ -50,6 +50,7 @@
 sub parse_line {
        # We will be testing undef strings
        no warnings;
+       use re 'taint'; # if it's tainted, leave it as such

     my($delimiter, $keep, $line) = @_;
     my($quote, $quoted, $unquoted, $delim, $word, @pieces);

[download]

Cheers,
Ovid

I took the advice of lshatzer and submitted the patch to P5P (and found the author using cjf's recommendation). Jarkko Hietaniemi sent a notification that the patches will be in Perl 5.8.0. I'm in the core now :)

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Replies are listed 'Best First'.
Re: Patching an unmaintained module
by lshatzer (Friar) on May 21, 2002 at 22:01 UTC
    If it is in the core, then you should submit the patch to P5P, and cc the author, with methods provided by cjf. This seems to be the way I've seen 'unmaintained' modules in the core before. The most important thing is the core module get patched, if the author keeps a copy maintained outside of the core, he can backport it himself, for future releases or life on CPAN.
[reply]
Re: Patching an unmaintained module
by cjf (Parson) on May 21, 2002 at 20:46 UTC

    I'm not sure how to go about submitting a patch for an unmaintained module, but a couple quick searches on the email address turns up lots more contact info. You could probably get a hold of the author through those addresses.

[reply]
Re: Patching an unmaintained module
by shotgunefx (Parson) on May 22, 2002 at 07:49 UTC
    I have a similar issue with PDF::Create detailed here. I tried contacting the author with no luck.

    -Lee

    "To be civilized is to deny one's nature."
[reply]
Re: Patching an unmaintained module
by cjf (Parson) on May 22, 2002 at 09:27 UTC

    Okay, so a secondary address for the author was found, he was contacted, and the patch was sent to the P5P. All is well.

    But what if the module wasn't part of the core and the author could not be contacted? What's the protocol in such a situation?

[reply]
      Taken from cpan faq:

      How do I report/fix a bug in a module/script?

      Use http://rt.cpan.org/ to open a bug ticket.

      Please contact the author of the module/script. The documentation of the module/script should contain a contact address or you can try CPANID@perl.org where CPANID is the authors CPANID.

      Most of the checklist in reporting bugs in Perl above applies for modules as well. Make your bug report as good as possible if you really want the bug fixed. If the module is included with the Perl distribution you should also follow the Perl bug reporting tips.

      How do I go about maintaining a module when the author is unresponsive?

      Sometimes a module goes unmaintained for a while due to the author pursuing other interests, being busy, etc. and another person needs changes applied to that module and may become frustrated when their email goes unanswered. CPAN does not mediate or dictate a policy in this situation and rely on the respective authors to work out the details. If you treat other authors as you would like to be treated in the same situation the manner in which you go about dealing with such problems should be obvious.

      • Be courteous.
      • Be considerate.
      • Make an earnest attempt to contact the author.
      • Give it time. If you need changes made immediately, consider applying your patches to the current module, changing the version and requiring that version for your application. Eventually the author will turn up and apply your patches, offer you maintenance of the module or, if the author doesn't respond in a year, you may get maintenance by having interest.
      • If you need changes in order for another module or application to work, consider making the needed changes and bundling the new version with your own distribution and noting the change well in the documentation. Do not upload the new version under the same namespace to CPAN until the matter has been resolved with the author or CPAN.

      Simply keep in mind that you are dealing with a person who invested time and care into something. A little respect and courtesy go a long way.

[reply]
Re: Patching an unmaintained module
by Matts (Deacon) on May 22, 2002 at 22:19 UTC
    Often if there's a bug in a module but the author is unreachable, or slow at updating it, the easiest thing to do is subclass the module. I've done this a number of times now, by just copy and pasting the method in question and adding my changes into a new module that has @ISA = qw(BrokenModule);

    Unfortunately the code above appears to be procedural, so it won't work there. But it's a useful technique for those who haven't heard of it before.

[reply]
[d/l]

Back to Meditations