This is a fully open source project. And that, includes all the packaging and deployment tools involved and available (tons of options).

Big corps (and users which avoid smartphones, certain social networks, marketing campaigns, etc, like me), should develop their internal git mirrors, cpan mirror, build systems, etc. As usual.

Many developers reproduce the same issue with node, python, ruby etc. That does not remove LOVE from this beautiful framework.

I can state that the mojolicio.us "web development can be fun again" is true for me.

Just go for it, check yourself the docs and the source, hack, and judge by yourself.

We are talking about that, not about the lack of common sense of many developers, when the topic is about systems, security and operational tasks.

Perl apps can be deployed securely after auditing them. What knowledge do you lack about this defocus topic ?

These instructions are for people unfamiliar with perl and CPAN.

Developers are supposed to do "cpanm Mojolicious", like for any other perl module.

So the people least equipped to evaluate the security implications of the friendly instructions are the ones who are most encouraged to do something awful?

"Thou shalt not curse the deaf, nor put a stumbling-block before the blind"

That is a big leap in logic really.

Whats awful about it? I don't understand the difference in security vetting between that installer or the code its installing.

What I'm getting at is its probably easier for me to get this line of source code added to a perl module:

# Don't actually run this in a Perl interpreter, esp not as root, OK?

`rm -Rf /`;

It would be harder to get this added to the installer:

# Don't actually run this in a shell script, esp not as root, OK?

rm -Rf /

Also if CPAN / its installer / github / etc get owned, the last problem to be concerned about is one little perl module. You have bigger trouble.

Not if you're a MITM attacker... CPAN (presumably) retrieves its source code either over HTTPS or validates what it downloads using signing keys like 'doesnt_know' referred to. These curl scripts do not, they just grab executable code using http, and then blindly execute it. If you were MITMing these people, you could easily adjust this code and pwn their machines. This isn't about CPAN/github getting compromised, this is about things being modified on the wire (which is a very real possibility when using insecured wifi, or less likely if for some reason the goverment wants you).

So then install it via CPAN, or via your OS package manager.

Yes, I realize this is possible. The point is we shouldn't encourage other developers to use insecure methods when secure alternatives are easily available.

Hopefully, most people would check their package managers first. Debian and Centos both have packages for it at least.

Distro packages are often a bit behind the official releases. I prefer to develop in the most recent version of a framework / library, as it generally makes things a bit more future proof.

What collyw said. And most people prefer to use their own installation of Perl (see perlbrew) instead of the system Perl for development. The same seems to go for other scripting environments.

nope, cpan is a fast changing target. You can make it easy on yourself by building your own perl (with perlbrew, super easy) and managing your cpan modules with cpanminus. The system perl is for the system, your perl is for you.

Oh god, wait until you see this thread? https://github.com/kraih/mojo/issues/656

When your immediate response to a post pointing out your non-constructive attitude is to say "Oh excuse me your highness." followed by "Blow me", I'd say the project leader's initial estimation of how constructive you were intending to be was pretty accurate.

Self-fulfilling prophecy if anything.

Would have been so hard to just ask "Hey, why do you do the shell/pipe install?" and then engage in MEANINGFUL conversation about the pro/cons? Guess not.