101–110 of 121 posts
Earlier quoted context omitted.
No, I disagree. The Ruby community is, generally, far more cohesive and homogeneous than the others you listed. This may partly be due to it being a relatively young community, compared to some others. Anyone who has been to a Ruby conference, especially while not being overly involved with the community otherwise, would likely know what I'm talking about, for example. Almost the entire community is male. There are v…
[deleted]
Earlier quoted context omitted.
I'm surprised people are still making these arguments. Well, that's okay - don't use it then! We'll figure it out on our own. I'm interested on the "maintainability" claim, though, because that one is new to me. Are there any blog posts that make this claim with some kind of example?
The attitude within your first paragraph is an excellent demonstration of the maintainability problems I'm talking about. Programmers five or ten years in the future won't have much say about the software they're being asked or told to maintain. Telling them to just "not use Ruby" won't solve the maintenance issues they're facing while working on some Rails web app developed years earlier. I'm sure you can find numer…
Earlier quoted context omitted.
[deleted]
I suspect behind your comment there's probably a bit of nagging resentment because Rails seems to have triumphed over despite Rails' Obvious Flaws -- amirite? No, you couldn't be any more wrong. I'm not sure why you Ruby on Rails advocates always make this assumption, or accusation, any time that you encounter somebody doesn't hold a pro-Rails attitude. I saw some other commenter in this thread make the same incorrec…
Your original post points to smugness, a lax approach to security and incorrect statements -- none of which I witness or interpreted from this blog post.
In fact I'd argue this blog post actually refutes all of the points you are making. It's factual, detailed, to the point and it doesn't make light of the issue at all.
Earlier quoted context omitted.
[deleted]
[deleted]
I don't mind if you disagree with what I believe and what I express, but I do ask that you please argue against my points, rather than attacking me personally. It's not constructive to label people here as "trolls" just because you have a differing opinion or point of view.
This post is written very confidently. I am less confident than the author of this post that the likelihood of a generic exploit via application input (that is, not using forged cookies) is remote. Wish there was more I could say right now. I'm not saying I have a curl command that exploits the vulnerability. I'd just be careful about making assumptions about this bug.
This smug attitude is something we've seen a lot from the Ruby, and especially the Rails, community, and it always burns them. They had this attitude when it came to the maintainability of Ruby apps. They'd say that Ruby code was much more maintainable than Java code, for instance. Now that we've got some Ruby apps that are several years old, and that have been worked on by a number of different people, it has become…
The security practices i saw are nothing short of ridiculous. If you'd take all the rails vulnerabilities and put them in a pot, and compare them to the holes i've seen in the little time i looked at them it's like comparing a secure vault to swiss cheese.
granted, saying x is secure, because y is inherently insecure is not a valid argument, but i've seen people first hand use these exaggerated advisories to justify that their bug ridden insecure enterprise stack is more justifiable for the enterprise. these people did not know pbkdf2, bcrypt, and even the sql injection whitepaper by microsoft(which btw is a joke).
wanna write secure code? NEVER assume someone else is going to secure it to you. fact is, good advisories and quick reaction to those are not a weakness but a strength.
You want to know the state of encryption in the enterprise world? Get a recent pastebin hack dump. Databases with passwords in plaintext, passwords in md5.
as for your sites basically collapsed? yes they did, it got popular during ruby 1.8.5 ffs. what the hell do you expect? it's slow? well, that's why theres lot's of custom c around. but anyway, since then many many things changed.
Java maintainable? In which world do you live? 8 different layers of OO abstractions 20 levels of dot notation, in which world is that maintainable? Notice how people move to groovy, scala, and other things, not plain java? ever wondered why?
You want highly reliable systems, your answer is not going to be java. Try erlang, but that one is GENUINELY slow.
Oh wait, did I even mention jruby? There you go, all the Java you want, kinda.
This bug is pretty edge, but if there was an easy way for a user to put a symbol in the params hash the bug would be a pretty gnarly universal SQL injection vulnerability for all versions of Rails. Though if that was easy it would most likely have been caught much, much earlier as there are a multitude of find helpers that allow literal SQL to be injected.
Early versions of Rails explicitly made the decision to never symbolize user inputted hashes because symbols are never garbage collected. This would allow memory to grow unbounded. As a result Rails stores all user hash keys as strings.
Earlier quoted context omitted.
I suspect behind your comment there's probably a bit of nagging resentment because Rails seems to have triumphed over despite Rails' Obvious Flaws -- amirite? No, you couldn't be any more wrong. I'm not sure why you Ruby on Rails advocates always make this assumption, or accusation, any time that you encounter somebody doesn't hold a pro-Rails attitude. I saw some other commenter in this thread make the same incorrec…
Ok, but what's your point and how does it relate to the article? Your original post points to smugness, a lax approach to security and incorrect statements -- none of which I witness or interpreted from this blog post. In fact I'd argue this blog post actually refutes all of the points you are making. It's factual, detailed, to the point and it doesn't make light of the issue at all.
The article's conclusion says, "... it is not a “giant bug”, it is much more subtle than that and requires a specific combination of code and circumstances to work. Most apps are not vulnerable."
To me, Thomas Ptacek appears to be suggesting that maybe there is more to this situation than meets the eye, and that maybe the article is not correct in making statements like, "Most apps are not vulnerable."
I merely pointed out that the Ruby on Rails community, in general, has a bad reputation when it comes to making claims. Often, the claims are shown to be complete nonsense.
If there is more to this vulnerability, and that it turns out that many Ruby on Rails apps actually are affected, then I wouldn't be surprised at all. I just hope that people do take this vulnerability seriously, contrary to what some articles may say, and do proper inspections of their Rails web apps.
Earlier quoted context omitted.
[deleted]
tptacek wrote No, he trolls, and you fall for it. You could help clean up the thread by deleting your comment, and then I'll delete this one. I don't mind if you disagree with what I believe and what I express, but I do ask that you please argue against my points, rather than attacking me personally. It's not constructive to label people here as "trolls" just because you have a differing opinion or point of view.
Earlier quoted context omitted.
What kind of hosting infrastructure was involved? You're only looking at part of the picture, I think. It's not just a matter of asking, "will the site hold up?", but rather it's one of "will the site hold up, given an economically-feasible amount of resources?" Throwing a lot of resources at a Ruby on Rails site for one day of heavy traffic is one thing. Having to do that for years on end just to maintain a reasonab…
Colo with 17 app servers. We didn't have to spin up additional workers, and this is about half the number of web servers the last startup-turn-IPO I worked at used (and they used Python!).
This bug is pretty edge, but if there was an easy way for a user to put a symbol in the params hash the bug would be a pretty gnarly universal SQL injection vulnerability for all versions of Rails. Though if that was easy it would most likely have been caught much, much earlier as there are a multitude of find helpers that allow literal SQL to be injected.