Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
static_typed
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
15 ms
·
91.
▲
by
static_typed
14y ago
Now is a good time to review alternative frameworks. A lot of them are simpler to understand, rely on less magic, and have communities around them that are interested in security as well as functionality.
92.
▲
by
static_typed
14y ago
Sadly, in the Ruby community shiny and magic are seen as more important than secure, robust or well engineered. That is the bottom line, and if choosing a new framework or language for your new projects, developers should really consider th
93.
▲
by
static_typed
14y ago
You could always wait till the server gets compromised, then the customers could alert you?
94.
▲
by
static_typed
14y ago
Our main client has one security agreement in place - anything but Ruby on Fails please! They seem quite happy with Python so far.
95.
▲
by
static_typed
14y ago
Because the PR machine for Rails is big, and people are slow to admit they sometimes back the wrong horse. Yes - well done devs for the quick turnaround in fixes. No - constant sticky plaster patch fixes are not the same as proper design, s
96.
▲
by
static_typed
14y ago
We actually moved off Ruby/Rails because of all this, but previously it was a test in QA, then patch Prod, both on same day of the word hitting the street that there was yet another hole to close
97.
▲
by
static_typed
14y ago
We don't seem to see the Python community embrace magic and shiny quite so much as in Ruby. That alone seems to help.
98.
▲
by
static_typed
14y ago
Yes, given we have seen issues in Core Ruby libraries (only recently updating the CSV lib), in Rails, in Ruby Gems, in Rack, it seems to pervade the Ruby Community. Secure is not cool, nor magic enough, it seems.
99.
▲
by
static_typed
14y ago
Members of our team have been receiving recruiter calls for the past few days - it seems a few places running Rails apps are on the lookout for developers to help secure and update their apps. At least one has apparently experienced the awe
100.
▲
by
static_typed
14y ago
Another day, another Ruby security bump. Sigh. Serious point - as Ruby seems to attract all the younger generation of programmers these days, and the current trend seems to be dev early, release early, security hole early, could this be tur
101.
▲
by
static_typed
14y ago
Security and good software engineering principles are perhaps not the first focus in the Ruby community, and that is a shame. Yes it is nice to have cool frameworks with lots of magic, and we can create a blog in one command. But none of th
102.
▲
by
static_typed
14y ago
Sure. We had a number of Rails apps running in our production environment. The recent weeks have been a very stressful time. A critical Rails or Ruby related vuln is discovered, and then we have to make emergency changes to try avoid the ap
103.
▲
by
static_typed
14y ago
We did. Until a few days ago. IT Security pulled the apps after the recent critical vulns in Rails, and now this vuln with RubyGems. Still using OpenBSD for hosting, but the apps are being ported to PHP and Python as we speak.
104.
▲
by
static_typed
14y ago
Not sure where anyone said it was part of Base, I am sure it was generally acknowledged as a port that was falling behind, and therefore presenting a security risk if installed, and a burden to maintain, given most users fall back to Ruby G
105.
▲
by
static_typed
14y ago
I think the overall points raised help shape the bigger conversation about the current state and implementation of Ruby Gems. Who built your Gem? How do you verify that still holds? You may trust developer A who released a nice Gem, but wha
106.
▲
by
static_typed
14y ago
Finally someone else gets it. Security is not solved by a gem install makerailsmadsecurer. Security is a process, and it does not stop. How many people install gems happily without really understanding what it actually permits? Especially w
107.
▲
by
static_typed
14y ago
I think he was actually pointing out a difference in approaches. OpenBSD tend to take the conservative line, the Ruby crowd seem to take the front-door open with Yaml parsers blazing ready to run arbitrary code line. I am sure it is possibl
108.
▲
by
static_typed
14y ago
Rails Security is apparently "omakase" - meaning 'leave it to someone else', apparently.
109.
▲
by
static_typed
14y ago
To be fair, other platforms and frameworks have had serialization issues, BUT, and this is the big one, they learned from the experience. Will the Ruby community learn? That is the question. Software Engineering are not dirty words!
110.
▲
by
static_typed
14y ago
Is Troll Ruby slang for someone who just got fed up being called into IT Security meetings to report on yet another urgent change to Prod being required because, the Ruby guys just love sticking Yaml parsers in wherever they can, and the wo
111.
▲
by
static_typed
14y ago
Whilst correct that my account is recent, I don't think the comments are really 'talk shit on Rails' - rather they point out the numerous serious security issues with Rails, Ruby Yaml libraries, and ecosystem in general have forced our hand
112.
▲
by
static_typed
14y ago
Looking at the long, long list of Gems required by Rails these days, makes it look less like a framework, and more like a patchwork. Complete with holes of course.
113.
▲
by
static_typed
14y ago
As much as I was a fan of developing Ruby apps, I was constantly shocked by the lack of engineering, security concern, stability of API, basically serious software engineering within the community. It would be good if all this was a clarion
114.
▲
by
static_typed
14y ago
Oh the timing. So, there was a big meeting, where some of the devs pleaded the case that the recent wave of security issues in the Ruby world were a tipping point, and that we were over it. They presented a good case, and I think the archit
115.
▲
by
static_typed
14y ago
Actually I see it more of indicative problem with the design of Rails. We keep getting told we should like magic, convention over configuration, but maybe it would be better to have a config file where we can turn the magic off in Rails. Bu
116.
▲
by
static_typed
14y ago
When we started seeing brogrammers and fauxgrammers, crashing code, let alone a tech crash, was inevitable.
117.
▲
by
static_typed
14y ago
The smell of late night coffee, having to update Ruby on Fails yet again, or better, the colder more bitter coffee in the morning, when having to offline and rebuild a compromised server due to this framework. It started with such promise,
118.
▲
by
static_typed
14y ago
Given we are still seeing more security issues with Rails, shouldn't the developers down tools for 5 mins to stop with the shiny-shiny, and maybe rewalk the codebase, the dependencies they set, and review things? Yes, they are quick to band