curl get.mojolicio.us | sh
sarciszewski opened this issue · comments
curl get.mojolicio.us | shWhy are you instructing people to pipe tainted/untrusted network data directly to sh from command line?
Why are you serving your code via two layers of redirects?
Why are both redirects sent in the clear (HTTP without TLS a.k.a. barebacking)?
This is a bad habit that I've seen in a lot of PHP projects, and I'm a little sad to see Perl developers falling into the same pattern.
Further Reference: https://defuse.ca/triangle-of-secure-code-delivery.htm
Please adjust your attitude before participating in the development of Mojolicious.
"Please adjust your attitude..."
Answer my questions first. You're facilitating in the cultural diffusion of a very bad habit that I've been trying to get developers out of ever since I heard of composer.
"... before participating in the development of Mojolicious."
Oh excuse me your highness. Here I was just asking questions to discern what your reasoning was for engaging in such abhorrent practices, and you tell me I'm only allowed to help your project if I say it in a way that pleases you?
Blow me.
Summary of the above:
- Person is driving through a school zone at 100mph.
- Police officer: WTF IS WRONG WITH YOU DO YOU WANT TO KILL KIDS?
- Person is like "I'll need you to calm down before I let you write me a ticket."
Holy christ, yo.
Discussions of tone-policing and project-management aside, please consider the OP's comments (whether you can stomache his tone, or not.) This is a horrible practice that needs to stop spreading.
I agree with ELLIOTTCABLE; this is a pretty severe and nasty security problem that has the potential to lead to Very Bad Things. Whether or not you like the tone is irrelevant to the merit of the bug; in this case, double-redirects and in-the-clear HTTP combined with cargo-cult shell instructions merit some very careful consideration and--in my opinion--a very fast fix.
(I wouldn't say irrelevant, @Dr-Syn; the right of a project owner to run their project how they will is inviolable. Not saying I think it indicates a very good project manager, but …)
@ELLIOTTCABLE Which is why I specified "to the merit of the bug" ;-) Tone of the report really doesn't have a bearing on whether or not the bug exists; while politeness is nice and to be encouraged, dismissing a report out of hand because you don't like the wording is...not.
I agree it's a bad practice as well, but that's also why I don't use it... or have considered using anything similar to it. Piping something from the internet to sh ... it really gives me the chills.
Unfortunately junk like this is market driven. People think it's a good idea to have one-liner cuteness over any potential badness. So ... the best thing we can do is teach people not to trust commands like this and then projects will stop promoting it since no one will use it. Until then ...
At the heart of it, I feel like the OP dismissed the suggestion of GitHub when opening the issue to read the contributing guide, which has the section http://mojolicio.us/perldoc/Mojolicious/Guides/Contributing#Reporting-security-issues
Please report security issues directly to the CPAN email address of the pumpkin-holder, which is currently sri@cpan.org, and give us a few days to develop and release a proper fix.
@dougwilson It was too late for that, even before the issues was posted. It was publicly disclosed on HN.
https://news.ycombinator.com/item?id=8095830 - 14 hours ago
I'm not going to reward this behavior with answers. Anyone who truly cares is welcome to open a new issue and ask in a civil manner, and i will explain why most changes we could do would simply be security theatre.
"I'm not going to reward this behavior with answers."
Because you don't have any?
"Anyone who truly cares is welcome to open a new issue and ask in a civil manner, and i will explain why most changes we could do would simply be security theatre."
That's a vapid statement. In any given situation "most changes we could do would simply be security theatre", but there are a subset of "all possible changes we could do" that would actually lead to increased security. That is why I referenced this article in the OP: https://defuse.ca/triangle-of-secure-code-delivery.htm
PGP signatures, reproducible builds, and userbase consistency verification -> win.
HTTP redirect + HTTP redirect on a different domain + Github raw over HTTPS -> lost.
What will you do if someone hijacks one of the two domains, loads it up with a MitM proxy, and trojans the build script to append an attacker's public key to ~/.ssh/authorized_keys? You have no plan. Dismissing the suggestions of someone who's trying to help because you don't like my (tone|attitude|.+?) isn't helping anyone.
@sarciszewski I'm locking this issue now, should you decide to start over with a new issue, please be nice, or i will be forced to ban you permanently from the project.
@sarciszewski why don't you do that to prove your point?