[opensuse-ruby] The case against using RubyGems.org in production
Interesting read: "Let’s get this out of the way: gems are awesome, and RubyGems.org is a great service. ...But lately I’ve been feeling queasy every time I add a new gem to an app. The more I think about it, the more it seems that the way we use gems isn’t just flawed. It’s a disaster waiting to happen." https://www.honeybadger.io/blog/2013/06/25/stop-using-rubygemsorg-in-product... Klaus -- SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Monday 01 July 2013 08:37:32 Klaus Kaempf wrote:
Interesting read:
"Let’s get this out of the way: gems are awesome, and RubyGems.org is a great service.
...But lately I’ve been feeling queasy every time I add a new gem to an app. The more I think about it, the more it seems that the way we use gems isn’t just flawed. It’s a disaster waiting to happen."
https://www.honeybadger.io/blog/2013/06/25/stop-using-rubygemsorg-in-produc tion
The solution which is suggested in this blog, is, by the way, how we do it in
SUSE Studio. We run a geminabox server as source for all the gems we deploy.
--
Cornelius Schumacher
On 07/01/2013 11:30 AM, Cornelius Schumacher wrote:
On Monday 01 July 2013 08:37:32 Klaus Kaempf wrote:
Interesting read:
"Let’s get this out of the way: gems are awesome, and RubyGems.org is a great service.
...But lately I’ve been feeling queasy every time I add a new gem to an app. The more I think about it, the more it seems that the way we use gems isn’t just flawed. It’s a disaster waiting to happen."
https://www.honeybadger.io/blog/2013/06/25/stop-using-rubygemsorg-in-produc tion
The solution which is suggested in this blog, is, by the way, how we do it in SUSE Studio. We run a geminabox server as source for all the gems we deploy.
I think the real crux is not about running an own mirror or not. The attack vector is that it's easy to get security issues merged into random Github (Ruby) projects (which may end up on rubygems.org) and having people using them blindly. It's a real nasty topic not specific to Ruby / gems in any way. It's about monitoring upstream changes for flaws, which usually can't be reasonably done upfront. For us, a better solution is to reduce gem usage to the bare minimum and stick with well-known ones that have a broad developer community behind. Audits by our sec guys can help too. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 01.07.2013 11:30, Cornelius Schumacher wrote:
On Monday 01 July 2013 08:37:32 Klaus Kaempf wrote:
Interesting read:
"Let’s get this out of the way: gems are awesome, and RubyGems.org is a great service.
...But lately I’ve been feeling queasy every time I add a new gem to an app. The more I think about it, the more it seems that the way we use gems isn’t just flawed. It’s a disaster waiting to happen."
https://www.honeybadger.io/blog/2013/06/25/stop-using-rubygemsorg-in-produc tion
The solution which is suggested in this blog, is, by the way, how we do it in SUSE Studio. We run a geminabox server as source for all the gems we deploy.
You do "Review the code for treachery" too? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On Monday 01 July 2013 12:33:12 Stephan Kulow wrote:
On 01.07.2013 11:30, Cornelius Schumacher wrote:
On Monday 01 July 2013 08:37:32 Klaus Kaempf wrote:
Interesting read:
"Let’s get this out of the way: gems are awesome, and RubyGems.org is
a great service.
...But lately I’ve been feeling queasy every time I add a new gem to an app. The more I think about it, the more it seems that the way we use gems isn’t just flawed. It’s a disaster waiting to happen."
https://www.honeybadger.io/blog/2013/06/25/stop-using-rubygemsorg-in-pro duc tion
The solution which is suggested in this blog, is, by the way, how we do it in SUSE Studio. We run a geminabox server as source for all the gems we deploy.
You do "Review the code for treachery" too?
Sascha is right, that running the server is not the actual issue, but it is a
necessary condition to be able to control what's being used by an app. We do
look at what we are using, but of course we are not able to review every
single line of code for every version update. So, as Sascha also already said,
relying on the reputation of upstream projects is also part of it. One nice
side effect of channeling gems through an own server is that you have a
complete track of the code you are using as gems, so in case there is any
doubt about possibly compromised gems, it's possible to analyze that.
--
Cornelius Schumacher
On 07/01/2013 01:28 PM, Cornelius Schumacher wrote:
On Monday 01 July 2013 12:33:12 Stephan Kulow wrote:
You do "Review the code for treachery" too?
Sascha is right, that running the server is not the actual issue, but it is a necessary condition to be able to control what's being used by an app. We do look at what we are using, but of course we are not able to review every single line of code for every version update. So, as Sascha also already said, relying on the reputation of upstream projects is also part of it. One nice side effect of channeling gems through an own server is that you have a complete track of the code you are using as gems, so in case there is any doubt about possibly compromised gems, it's possible to analyze that.
Webyast uses brakeman for periodical checking for possible vulnerabilities and there are other tools out there. We could incorporate brakeman into the build process of rubygem-* RPMs and forbid using gems directly. Or we could monitor upstream projects in use. Still not a bullet-proof way but might be better than nothing. Bye Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 07/01/2013 01:45 PM, Lukas Ocilka wrote:
On 07/01/2013 01:28 PM, Cornelius Schumacher wrote:
On Monday 01 July 2013 12:33:12 Stephan Kulow wrote:
You do "Review the code for treachery" too?
Sascha is right, that running the server is not the actual issue, but it is a necessary condition to be able to control what's being used by an app. We do look at what we are using, but of course we are not able to review every single line of code for every version update. So, as Sascha also already said, relying on the reputation of upstream projects is also part of it. One nice side effect of channeling gems through an own server is that you have a complete track of the code you are using as gems, so in case there is any doubt about possibly compromised gems, it's possible to analyze that.
Webyast uses brakeman for periodical checking for possible vulnerabilities and there are other tools out there. We could incorporate brakeman into the build process of rubygem-* RPMs and forbid using gems directly. Or we could monitor upstream projects in use. Still not a bullet-proof way but might be better than nothing.
what you mean by "forbid using gems directly"? what you mean by "monitor upstream projects"? Running brakeman on github projects?
Bye Lukas
-- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 07/01/2013 02:05 PM, Jordi Massaguer Pla wrote:
On 07/01/2013 01:45 PM, Lukas Ocilka wrote:
Webyast uses brakeman for periodical checking for possible vulnerabilities and there are other tools out there. We could incorporate brakeman into the build process of rubygem-* RPMs and forbid using gems directly. Or we could monitor upstream projects in use. Still not a bullet-proof way but might be better than nothing.
what you mean by "forbid using gems directly"?
By creating an internal policy, let's call it strict recommendation.
what you mean by "monitor upstream projects"? Running brakeman on github projects?
Yes, that's what I meant. Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 01.07.2013 13:45, Lukas Ocilka wrote:
On 07/01/2013 01:28 PM, Cornelius Schumacher wrote:
On Monday 01 July 2013 12:33:12 Stephan Kulow wrote:
You do "Review the code for treachery" too?
Sascha is right, that running the server is not the actual issue, but it is a necessary condition to be able to control what's being used by an app. We do look at what we are using, but of course we are not able to review every single line of code for every version update. So, as Sascha also already said, relying on the reputation of upstream projects is also part of it. One nice side effect of channeling gems through an own server is that you have a complete track of the code you are using as gems, so in case there is any doubt about possibly compromised gems, it's possible to analyze that.
Webyast uses brakeman for periodical checking for possible vulnerabilities and there are other tools out there. We could incorporate brakeman into the build process of rubygem-* RPMs and forbid using gems directly. Or we could monitor upstream projects in use. Still not a bullet-proof way but might be better than nothing.
I doubt brakeman would highlight anything described in the blog Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
On 07/01/2013 02:12 PM, Stephan Kulow wrote:
On 01.07.2013 13:45, Lukas Ocilka wrote:
Webyast uses brakeman for periodical checking for possible vulnerabilities and there are other tools out there. We could incorporate brakeman into the build process of rubygem-* RPMs and forbid using gems directly. Or we could monitor upstream projects in use. Still not a bullet-proof way but might be better than nothing.
I doubt brakeman would highlight anything described in the blog
Well, you might be right. We haven't tried that yet. Neither with breakman nor with any other (security) scanner. Lukas -- Lukas Ocilka, Cloud & Systems Management Department SUSE LINUX s.r.o., Praha -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-ruby+owner@opensuse.org
participants (6)
-
Cornelius Schumacher -
Jordi Massaguer Pla -
Klaus Kaempf -
Lukas Ocilka -
Sascha Peilicke -
Stephan Kulow