Andreas, I hope you don't think I'm out of line here, but I'm putting on my security hat from when I was working with WhiteHat and making a comment about the overall design of the module and specifically about the test suite.
Rob, I'm sure that functionally speaking this module is well-meant, but time and again, we warn people about "curl | bash" as an outstandingly boneheaded thing to do. One should never simply execute something that happens to be at the far end of a URL that one does not control, and that is generally accessible on the Internet, and hope everything will be okay. But the reason that this module was pulled earlier was not that it does this -- though I would argue that even the basic idea of implementing a security vulnerability as a module is a terrible idea -- it was pulled because of all the following: - the test suite accesses a site the installer does not control without warning them this will happen - it obscures the site being used - the code being downloaded is not the minimum possible needed to ensure that the test passes - the code being downloaded is deliberately obfuscated to make it difficult for the installer to vet it for safety - worst, the code that it currently downloads appears to be malware. (side note: it *does not matter* if it isn't! The fact that it is not blindingly obvious is in itself highly suspect). The combination of all these is not only unsafe but outright dangerous. Rob, it's possible that you didn't know this.I'll totally give you the benefit of the doubt. But if you didn't know that you've been sending out something that you didn't intend -- well, you've got a mighty fine argument as to why this module is dangerous. If you did, I question the lack of transparency. There is absolutely no need to obfuscate this code if this is simply for a test. Consider: if you (Rob) lose control of the site that the test suite uses, or someone gains access to it without your knowledge, every installer who reruns the test suite is potentially a victim of any number of attacks - let's say ransomware, for starters. Even if you changed what it's loading to a cleartext dummy "hey look I got installed" module, you'd still be weakening the security of every installation that used this module to be only as good as your security is. Are you prepared to take on that level of responsibility for every random yahoo who uses Perl and decides this module is a good idea? Even if you think you are, I do not think this is a good idea. I would think that from a legal standpoint you might be on very shaky ground if there was a successful breakin vectored through your site, and that CPAN, or Andreas, or the Perl Foundation, might also find themselves in legal hot water if a court decided that leaving this in place was negligent. That is playing with fire that we do not need to do. My personal opinion is that this module is a potential Trojan and should be removed, period. If it is to be allowed to stay, at a minimum, it should be moved to the Acme namespace to make it plain that this module is not meant for production. Its current naming obscures that fact. In addition, it needs a huge disclaimer at the top of the POD that stresses that this module deliberately implements remote code execution, and that this is inherently dangerous. There should also be a big banner during CPAN install that says this. Last, the test suite must be rewritten to use a `file:` URL or to run a localhost-only HTTP server which loads unobfuscated, minimal code that verifies the operation of the module. The linking out to the obfuscated site and loading of obfuscated code must be removed completely, and the old versions that did this must be removed. In my opinion, this module is dangerous, so much so that it is not salvageable without some very serious rewriting. If it is meant to load CPAN modules then it should only be able to do that; a generalized remote code execution framework is a ridiculously bad idea and should not be permitted on an official site. A footgun that the responsibility of the user to police is one thing. A footgun that we deliver loaded, with ammunition that might suddenly be something extremely dangerous, and actually fire during *the test suite* is wildly inappropriate -- and I for one do not want it to be something someone potentially ends up in court about. On Tue, Jul 28, 2020 at 11:50 PM Andreas Koenig < andreas.koenig.7os6v...@franz.ak.mind.de> wrote: > >>>>> On Tue, 28 Jul 2020 21:08:11 -0600, Rob Brown <b...@cpan.org> said: > > > Hey Andreas, > > I'm getting hounded with complaints about my Module::AutoLoad suddenly > > not working [...] > > Hi Rob, > > first of all, please accept my apologies. I was intending to write to > you immediately, but then got distracted and found the open case again a > bit late. > > I've now brought Module-AutoLoad-0.06.tar.gz back to your directory and > made your account active again. But the module is not indexed anymore. I > hope this works for you. > > As a way forward I'm leaning to suggest something that protects your > fellow CPAN users from accidentally running into it again and/or > something that reduces the potential to get people nervous and maybe > also reduces the amount of required hacking when things go wrong next > time. > > I think whatever meets such criteria should be good enough. I'm thinking > of something like a disclaimer like when you sell a heating you're > required to tell the customer that they have to be careful because the > device gets hot when deployed. Otherwise *they* get a chance to ruin > *your* day. In other words, better err on the side of caution. > > Sorry for the late answer and I hope this all now works again both for > you and the rest of the community for at least the next ten years. > > Greetings from Berlin, > -- > andreas >
