Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenBSD removes Rails from the ports tree

marc.info

Post reply on HN
Print view View original

51–60 of 73 posts

Re: OpenBSD removes Rails from the ports tree

#51

Post by snogglethorpe »

PommeDeTerre wrote: post #50
eric970 wrote: post #47

Earlier quoted context omitted.

Dude, every one of your posts on HN I've seen has been about how Ruby sucks and should be thrown away. Either you're a troll or you're a very angry and upset person. Either way, I feel sorry for you.

I don't mean you any offense, but your response is the kind that makes the entire Ruby community look very bad. It is perfectly normal for responsible software developers, system administrators and business leaders to get angry or upset by security vulnerabilities. The impact such vulnerabilities can have on an organization is staggering. When they're exploited, there can be huge sums of money lost. There can be seri…

Er, I'm sure this is true, and I'm no Rails fanboy (indeed I've never even used Rails, and haven't written more than 10 lines of Ruby in my life), but the grand-parent poster really does come off as a troll or someone with an axe to grind.

He's vague and inflammatory, and avoids technical details in favor of generically insulting language ("the 'IT security' team describes ruby culture as immature"), apparently more aimed at denigrating a particular community than clarifying any issues or solutions. Much of what he writes is borderline absurd ["Rewriting in python and PHP"... really? PHP is their choice for a better-"engineered" replacement?!]

Everybody sometimes writes vague and snarky posts, but doing so repeatedly is a warning sign...

Re: OpenBSD removes Rails from the ports tree

#52

Post by begurken »

eric970 wrote: post #47
static_typed wrote: post #46

Earlier quoted context omitted.

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 app or server getting compromised. Of course, given the large number of these critical issues, the business decided to pull and rewrite the apps based on input from the It Security t…

Dude, every one of your posts on HN I've seen has been about how Ruby sucks and should be thrown away. Either you're a troll or you're a very angry and upset person. Either way, I feel sorry for you.

While you may not agree with static_typed (his name suggests he's probably not a huge Ruby fan), the Rails community (& to some degree the Ruby community) should listen to folks like him. This is because more and more people would agree with static_type's statements.

The high chance that more catastrophic rails exploits will be found in the next month (if all of the paths to YAML.load have been found, I'll eat my hat) will increase the number of people making or agreeing with statements like static_typed's. After an exploit or two have been found in February or March, people will be pointing at Rails and saying 'I told you so'.

Re: OpenBSD removes Rails from the ports tree

#53

Post by pizzeys »

PommeDeTerre wrote: post #50
eric970 wrote: post #47

Earlier quoted context omitted.

Dude, every one of your posts on HN I've seen has been about how Ruby sucks and should be thrown away. Either you're a troll or you're a very angry and upset person. Either way, I feel sorry for you.

I don't mean you any offense, but your response is the kind that makes the entire Ruby community look very bad. It is perfectly normal for responsible software developers, system administrators and business leaders to get angry or upset by security vulnerabilities. The impact such vulnerabilities can have on an organization is staggering. When they're exploited, there can be huge sums of money lost. There can be seri…

If Ruby has had a bad time lately, then surely PHP has had a bad decade? It just seems odd to jump out of the frying pan and into the fire, is all.

Re: OpenBSD removes Rails from the ports tree

#54

Post by inopinatus »

static_typed wrote: post #39
inopinatus wrote: post #35

Earlier quoted context omitted.

Since neither Ruby nor Rails are part of the OpenBSD base system, this point is largely moot. Practically the entire ports tree consists of software that was not developed with careful security from the beginning. I think yours is a straw man argument, and it is not a surprise to me that you felt the need to fling invective at the Ruby community as backup.

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 Gems anyway. It is rather sad that any story with 'ruby' in the title seems to bring out people who are quick to shout, stamp, accuse and drown out any voices that question how thin…

The guy above clearly applied the coding standards of the OpenBSD base system to a contributed package and used that as a basis for argument. Irrespective of how Ruby's developers do things, it is sloppy thinking.

As for going through the ports tree, your presumption is odd, of course I haven't sat with each and every developer. Perhaps you intended irony. Ho hum. But where's the invective? It is exceedingly rare for software to be written with as much security-consciousness as OpenBSD. I don't think that's a controversial statement.

Re: OpenBSD removes Rails from the ports tree

#55

Post by inopinatus »

igravious wrote: post #43
inopinatus wrote: post #36

I'd like to take this opportunity to highlight BSDPAN, which is how FreeBSD integrates her own package database with Perl's native module installation. Since 99% of package management is just files on a filesystem and a bit of dependency analysis, for the purposes of easing installation, permitting bidirectional awareness of state, and alerting administrators to security updates. I would commend any OS that has the s…

I know this is a bit of a me too post but this is something I have thought should exist for years now. Another benefit this would provide would be that you'd only have to learn one set of incantations rather than forgetting and looking up whatever subsystem it is you're messing with. For the life of me I don't know why this does not exist yet. I have such a desire for it that I thought long and hard about building so…

There are workflow issues to generalising the case. In particular, since this is a devops issue any such solution has to be based on satisfying the needs of developers (e.g. ease of deployment, version specificity), and the needs of admins (ease of patching & audit, dependency management) across a wide variety of packaging mechanisms for both base OS and many language-specific ecosystems.

It's no surprise to me that the unit of deployment, for many sites, is becoming the virtual machine template. Since you don't even need to bother maintaining it; just keep your data separate from your code, rebuild the image when necessary with latest libs & pkgs, and throw away old ones. This is how many PaaS providers are doing things.

Re: OpenBSD removes Rails from the ports tree

#56

Post by hosh »

inopinatus wrote: post #37
wildchild wrote: post #10

Wise decision. Ruby has it's own package system. I believe every developer using rvm/rbenv for managing ruby versions. Rails should be installed using rubygems. I always cry seeing pretty outdated rails packages in distributives. I don't care.

Unfortunately this leads to language binaries & libs being distributed by the developer with the application. Sysadmins then install the whole massive hairball in /opt as a single unit and never update it until the developer provides a point release. Which never happens because the dev team has been disbanded, they're all on new projects now. If you don't think that's a problem in the real world, you ain't seen 95% o…

We're in the age of technologies like Chef, Puppet, and virtual machines. Said hairballs are described by code, and versionable.

And if that is still a problem for 95% of the enterprise IT, I guess that's why startup tend to kick their butts out in the frontiers.

Re: OpenBSD removes Rails from the ports tree

#57

Post by hosh »

chimeracoder wrote: post #41
tedunangst wrote: post #38

Earlier quoted context omitted.

As somebody who occasionally uses software, besides just developing it, learning the command syntax and idiosyncrasies of a half dozen package systems is a pain in the butt. I want to type "pkg_add things I want" and be done with it.

Not to mention that package management isn't a problem that should be solved at every single level possible - package management for the OS, package management for developing in $LANGUAGE, package management for extensions of $PROGRAM written in $LANGUAGE, etc.... Aside from the fact that that's redundant, it's highly error-prone.

As a long time Rails dev, I never trust the package maintainer's OS packages for Rails. I need specific versions of Rails and gems, often times specific git commits.

In places where the IT staff insists on making sure this isn't "redundant", they usually use something like fpm to create a deb or an rpm out of the gem specified by Gemfile. Which you then have to drop into a custom deb/rpm repository. On top of that, the ops staff don't know how to do that properly, so they end up with a bunch of testing and development dependencies that the Rails application doesn't need.

... or, you have the deploy process call, "bundle install"

The redundancy is in the OS packages, not in application dependencies. So it is actually better to automate such with something like Chef and Puppet. From there, I can define exactly what the application needs from the OS.

I have seen this play out in a lot of ways, devs vs. sys admin. In the past, sys admins "win" since compute resources were still scarce. We're in the age of virtual machines now and configuration automation. Applications get their own VMs, sometimes in multiple nodes. We don't have Unix high priests guarding the altar with SSH keys, hand-deploying things in secret early-morning ceremonies. We have automation to deploy for us, which means we want to make it easier for the automation to deploy, not necessarily for someone to shell in and maneuver around with hand installations.

Things being application-centric, the "right" thing is to conform to the requirements of the dev team's app, not the other way around.

Re: OpenBSD removes Rails from the ports tree

#58

Post by hosh »

dlisboa wrote: post #28
wmoxam wrote: post #26

Earlier quoted context omitted.

It makes sense from the perspective of it being a dependency of some end user software such as Typo or Redmine

I've been messing around with FreeBSD for a few days and it has RubyGems set up very conveniently. Root installed packages (like the ones from ports) would already be attended through the root installed RubyGem. Aside from OpenBSD which has their security procedures for installed software it doesn't seem like any ports distro really need to have copies of gems in their package tree if the RubyGems package is set up c…

I can tell you that deploying a Rails app needs to come from using rubygem and bundler, never the OS's package management.

As for security concerns: you can and should vet gems, but it won't matter if the application itself has vulnerabilities.

We don't have very many Rails app written as a packaged system for deployment. The kind you see are often SAAS apps or something to interact with people internally. They are often bespoke and written for specific needs.

Re: OpenBSD removes Rails from the ports tree

#59

Post by inopinatus »

hosh wrote: post #56
inopinatus wrote: post #37

Earlier quoted context omitted.

Unfortunately this leads to language binaries & libs being distributed by the developer with the application. Sysadmins then install the whole massive hairball in /opt as a single unit and never update it until the developer provides a point release. Which never happens because the dev team has been disbanded, they're all on new projects now. If you don't think that's a problem in the real world, you ain't seen 95% o…

We're in the age of technologies like Chef, Puppet, and virtual machines. Said hairballs are described by code, and versionable. And if that is still a problem for 95% of the enterprise IT, I guess that's why startup tend to kick their butts out in the frontiers.

I appreciate your butt-kicking energy! However, I must note: configuration idempotency tools that regard infrastructure as code are not new. I think you'll find that the inadequacy of cfengine, puppet & chef to the task is why they are not universally used. Devops is a very young discipline and these tools are the stepping stones toward a more coherent model of component deployment. I'm not saying they're crap, just that we can and will do better. Chef is probably the best effort so far, although I am unconvinced by the client/server variant.

In particular, none of them yet solve the problems of client application deployment. They are also implicated in the VM sprawl many cloud users experience.

Finally, they have convinced some developers that systems administration is something they can do themselves. Experience consistently proves this wrong; I've lost count of developers out of their depth, asking for rescue from suboptimal deployment decisions and needing rescuing. Either that or they discover a penchant for systems admin as well, and thus become devops people (this is what happened to me). I've seen the latter happen most often in the ISP world; perhaps network engineers have that mindset.

Personally I foresee a stronger role for packages as an output from continuous integration pipelines (another young discipline).

Re: OpenBSD removes Rails from the ports tree

#60

Post by duaneb »

static_typed wrote: post #46
rjbond3rd wrote: post #45

Earlier quoted context omitted.

Whoa, could you elaborate? I'm sure people would love to hear more context for totally rewriting (not second-guessing, just intensely curious).

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 app or server getting compromised. Of course, given the large number of these critical issues, the business decided to pull and rewrite the apps based on input from the It Security t…

> Of course, given the large number of these critical issues, the business decided to pull and rewrite the apps based on input from the It Security team who described the current Ruby developer culture as being immature, ignorant of software engineering principles, unaware of secure coding, too enamoured with shiny/magic/convenience to care about longer-term implications in their design choices, thinking that constant band-aid fixes are the right way forward rather than acknowledge and fix poor design and implementation, and basically a liability for the company and it's data.

And you're switching to PHP? Someone should be fired for that decision.

Post reply on HN