Maybe create a gem? #2

Open
douglascamata opened this Issue Oct 21, 2015 · 20 comments

Comments

Projects
None yet
5 participants
@douglascamata

Do you think it is possible to create a gem to automatically check if you have a "leaky gem" installed?

I know that if you have a Gemfile it would be pretty easy to implement a command to check this. If you use Rails creating an initializer to do the same thing is also easy. But is it possible to check gem versions at "require" time?

@sergey-alekseev

This comment has been minimized.

Show comment
Hide comment
@sergey-alekseev

sergey-alekseev Oct 21, 2015

Contributor

@douglascamata yes, that's my initial idea.
However creating a gem takes a bit time. On the contrary testing the general idea as a simple gems list takes a little effort. I think the idea's testing is successful, so I'm going to create a gem soon. Thanks for your proposal and confirming my initial thoughts.

Leaving this issue open until I create a gem.

Contributor

sergey-alekseev commented Oct 21, 2015

@douglascamata yes, that's my initial idea.
However creating a gem takes a bit time. On the contrary testing the general idea as a simple gems list takes a little effort. I think the idea's testing is successful, so I'm going to create a gem soon. Thanks for your proposal and confirming my initial thoughts.

Leaving this issue open until I create a gem.

@douglascamata

This comment has been minimized.

Show comment
Hide comment
@douglascamata

douglascamata Oct 21, 2015

@sergey-alekseev remember to update here when you start the gem, I want to contribute 👍

@sergey-alekseev remember to update here when you start the gem, I want to contribute 👍

@somazx

This comment has been minimized.

Show comment
Hide comment
@somazx

somazx Oct 21, 2015

bonus points if your gem checking for leaky gems itself leaks memory 😛

somazx commented Oct 21, 2015

bonus points if your gem checking for leaky gems itself leaks memory 😛

@douglascamata

This comment has been minimized.

Show comment
Hide comment
@douglascamata

douglascamata Oct 21, 2015

@somazx it can be a hidden feature, like an easter egg, lol

@somazx it can be a hidden feature, like an easter egg, lol

@grosser

This comment has been minimized.

Show comment
Hide comment
@grosser

grosser Oct 21, 2015

How about adding as advisory to bundler-audit then it can live with all the other gems and we do not need different mechanisms

grosser commented Oct 21, 2015

How about adding as advisory to bundler-audit then it can live with all the other gems and we do not need different mechanisms

@douglascamata

This comment has been minimized.

Show comment
Hide comment
@douglascamata

douglascamata Oct 21, 2015

@grosser it's a nice idea! But I also would love to see it working without bundler too, if possible. And I think it is better if I need only 1 line of code in the main file of my project to activate the verification at require-time than a command that I need to run.

@grosser it's a nice idea! But I also would love to see it working without bundler too, if possible. And I think it is better if I need only 1 line of code in the main file of my project to activate the verification at require-time than a command that I need to run.

@grosser

This comment has been minimized.

Show comment
Hide comment
@grosser

grosser Oct 21, 2015

How would you know what gem version is used if not for a Gemfile.lock ... so you need bundler ...

grosser commented Oct 21, 2015

How would you know what gem version is used if not for a Gemfile.lock ... so you need bundler ...

@douglascamata

This comment has been minimized.

Show comment
Hide comment
@douglascamata

douglascamata Oct 21, 2015

@grosser dunno how I would check that without bundler yet, but it might be possible somehow :P

@grosser dunno how I would check that without bundler yet, but it might be possible somehow :P

@douglascamata

This comment has been minimized.

Show comment
Hide comment
@douglascamata

douglascamata Oct 21, 2015

irb(main):001:0> require 'middleman'
=> true
irb(main):002:0> Gem.loaded_specs["middleman"].version
=> #<Gem::Version "3.4.0">
irb(main):001:0> require 'middleman'
=> true
irb(main):002:0> Gem.loaded_specs["middleman"].version
=> #<Gem::Version "3.4.0">
@grosser

This comment has been minimized.

Show comment
Hide comment
@grosser

grosser Oct 21, 2015

That does not mean that your app is actually using that version of the gem
... it's just a random gem that was installed on your machine.

I'd prefer something simple/useful/integrated instead of
one-off/hacky/standalone :)

On Wed, Oct 21, 2015 at 2:09 PM, Douglas Camata notifications@github.com
wrote:

=> true
irb(main):002:0> Gem.loaded_specs["middleman"].version
=> #

—
Reply to this email directly or view it on GitHub
https://github.com/ASoftCo/leaky-gems/issues/2#issuecomment-150024976.

grosser commented Oct 21, 2015

That does not mean that your app is actually using that version of the gem
... it's just a random gem that was installed on your machine.

I'd prefer something simple/useful/integrated instead of
one-off/hacky/standalone :)

On Wed, Oct 21, 2015 at 2:09 PM, Douglas Camata notifications@github.com
wrote:

=> true
irb(main):002:0> Gem.loaded_specs["middleman"].version
=> #

—
Reply to this email directly or view it on GitHub
https://github.com/ASoftCo/leaky-gems/issues/2#issuecomment-150024976.
@douglascamata

This comment has been minimized.

Show comment
Hide comment
@douglascamata

douglascamata Oct 21, 2015

@grosser this is the actual version of the gem that was loaded by the require statement. It's not a just random gem installed on my machine. Gem.loaded_specs is only populated when you actually require a gem and it uses information of the gem's gemspec file.

I don't like bundler-audit because of the command, as I said. You need to have the habit of running bundle audit. With my suggestion you will just need to put one line of code in your project to be remembered that a gem version leaks memory every time you require it. It's very simple to do this, it's useful and integrated into your code.

@grosser this is the actual version of the gem that was loaded by the require statement. It's not a just random gem installed on my machine. Gem.loaded_specs is only populated when you actually require a gem and it uses information of the gem's gemspec file.

I don't like bundler-audit because of the command, as I said. You need to have the habit of running bundle audit. With my suggestion you will just need to put one line of code in your project to be remembered that a gem version leaks memory every time you require it. It's very simple to do this, it's useful and integrated into your code.

@grosser

This comment has been minimized.

Show comment
Hide comment
@grosser

grosser Oct 21, 2015

If you don't use bundler then a require will load a random version of the
gem,
so to do anything meaningful we need bundler anyway ... so it's pointless
to build something bundler-agnostic.

Same can be done by making bundler-audit requirable, which adds the feature
for it's security checks and nobody needs to add a separate dependency to
another project.

(FYI checking on require will wastes startup time, adds another dependency
to the project, and means that the check is failing if not constantly
bundle-updating the gem ... so much more inconvenient then adding bundle audit --update to CI)

On Wed, Oct 21, 2015 at 3:23 PM, Douglas Camata notifications@github.com
wrote:

@grosser https://github.com/grosser this is the actual version of the
gem that was loaded by the require statement. It's not a just random gem
installed on my machine. Gem.loaded_specs is only populated when you
actually require a some gem and it uses information of the gem's gemspec
file.

I don't like bundler-audit because of the command, as I said. You need to
have the habit of running bundle audit. With my suggestion you will just
need to put one line of code in your project to be remembered that a gem
version leaks memory every time you require it. It is very simple to do
this, it's useful and integrated into your code.


Reply to this email directly or view it on GitHub
#2 (comment).

grosser commented Oct 21, 2015

If you don't use bundler then a require will load a random version of the
gem,
so to do anything meaningful we need bundler anyway ... so it's pointless
to build something bundler-agnostic.

Same can be done by making bundler-audit requirable, which adds the feature
for it's security checks and nobody needs to add a separate dependency to
another project.

(FYI checking on require will wastes startup time, adds another dependency
to the project, and means that the check is failing if not constantly
bundle-updating the gem ... so much more inconvenient then adding bundle audit --update to CI)

On Wed, Oct 21, 2015 at 3:23 PM, Douglas Camata notifications@github.com
wrote:

@grosser https://github.com/grosser this is the actual version of the
gem that was loaded by the require statement. It's not a just random gem
installed on my machine. Gem.loaded_specs is only populated when you
actually require a some gem and it uses information of the gem's gemspec
file.

I don't like bundler-audit because of the command, as I said. You need to
have the habit of running bundle audit. With my suggestion you will just
need to put one line of code in your project to be remembered that a gem
version leaks memory every time you require it. It is very simple to do
this, it's useful and integrated into your code.


Reply to this email directly or view it on GitHub
#2 (comment).

@grosser

This comment has been minimized.

Show comment
Hide comment
@douglascamata

This comment has been minimized.

Show comment
Hide comment
@douglascamata

douglascamata Oct 21, 2015

@grosser I don't see the issue of random version of the gem picked if you don't use bundler as part of the gem's problem. This gem responsibility would be just check if the loaded gem version leaks memory, it doesn't matter how the gem got there. But talking real, everyone uses bundler, so the correct version of the gem will be loaded and verified.

I also think a little startup time wasted in development/test is a fair price to pay for automatically checking these things that can give a big headache in production. Adding to CI is nice, but what if you don't have CI for whatever the reason?

Anyway, let's see what bundler-audit guys says about your question. And just to make it clear, I really liked your suggestion about bundler-audit integration and IMHO we should do both ideas.

@grosser I don't see the issue of random version of the gem picked if you don't use bundler as part of the gem's problem. This gem responsibility would be just check if the loaded gem version leaks memory, it doesn't matter how the gem got there. But talking real, everyone uses bundler, so the correct version of the gem will be loaded and verified.

I also think a little startup time wasted in development/test is a fair price to pay for automatically checking these things that can give a big headache in production. Adding to CI is nice, but what if you don't have CI for whatever the reason?

Anyway, let's see what bundler-audit guys says about your question. And just to make it clear, I really liked your suggestion about bundler-audit integration and IMHO we should do both ideas.

@grosser

This comment has been minimized.

Show comment
Hide comment
@sergey-alekseev

This comment has been minimized.

Show comment
Hide comment
@sergey-alekseev

sergey-alekseev Oct 22, 2015

Contributor

Thanks @douglascamata and @grosser for your considerations.
bundler-audit seems really useful. However they say it "Checks for vulnerable versions of gems in Gemfile.lock". It's a bit different from "leaky versions of gems". So no wonder they consider those memory leaks are not vulnerabilities (1, 2, 3) and requesting CVE/OSVDB ids (1, 2, 3, 4).

I'm open to all 3 options @grosser mentioned in rubysec/bundler-audit#116 (comment). An integration with bundler-audit would be nice.

Contributor

sergey-alekseev commented Oct 22, 2015

Thanks @douglascamata and @grosser for your considerations.
bundler-audit seems really useful. However they say it "Checks for vulnerable versions of gems in Gemfile.lock". It's a bit different from "leaky versions of gems". So no wonder they consider those memory leaks are not vulnerabilities (1, 2, 3) and requesting CVE/OSVDB ids (1, 2, 3, 4).

I'm open to all 3 options @grosser mentioned in rubysec/bundler-audit#116 (comment). An integration with bundler-audit would be nice.

@phillmv

This comment has been minimized.

Show comment
Hide comment
@phillmv

phillmv Oct 22, 2015

Hey,

Thanks for the effort everybody. The ruby-advisory-db is mostly about classes of bugs that are can be abused maliciously. What exactly constitutes a "vulnerability" is a bit of a philosophical point but @grosser you were correct in suspecting that many of them could belong in the advisory-db 😃.

We do impose a bit of a hurdle in that we aggregate advisories that have been published or somewhat vetted elsewhere, i.e. the requirement that notices contain a CVE or osvdb. For the most part, a lot of these memory bugs could very well be applicable.


For your purposes, I would suggest adopting the ruby-advisory-db schema (minus the CVE/OSVDB requirement) and then forking bundler-audit to slurp down that database instead.

The above analysis regarding depending on bundler is correct - runtime checks are annoying to implement properly :).

phillmv commented Oct 22, 2015

Hey,

Thanks for the effort everybody. The ruby-advisory-db is mostly about classes of bugs that are can be abused maliciously. What exactly constitutes a "vulnerability" is a bit of a philosophical point but @grosser you were correct in suspecting that many of them could belong in the advisory-db 😃.

We do impose a bit of a hurdle in that we aggregate advisories that have been published or somewhat vetted elsewhere, i.e. the requirement that notices contain a CVE or osvdb. For the most part, a lot of these memory bugs could very well be applicable.


For your purposes, I would suggest adopting the ruby-advisory-db schema (minus the CVE/OSVDB requirement) and then forking bundler-audit to slurp down that database instead.

The above analysis regarding depending on bundler is correct - runtime checks are annoying to implement properly :).

@sergey-alekseev

This comment has been minimized.

Show comment
Hide comment
@sergey-alekseev

sergey-alekseev Oct 22, 2015

Contributor

@phillmv thanks for your input on this. Let me confirm you recommend the 3rd option @grosser mentioned in rubysec/bundler-audit#116 (comment):

make new gem that checks new database by running bundle-audit with some funky hacks/arguments

Contributor

sergey-alekseev commented Oct 22, 2015

@phillmv thanks for your input on this. Let me confirm you recommend the 3rd option @grosser mentioned in rubysec/bundler-audit#116 (comment):

make new gem that checks new database by running bundle-audit with some funky hacks/arguments

@grosser

This comment has been minimized.

Show comment
Hide comment
@grosser

grosser Oct 22, 2015

Something that just changes the url would be great ... maintaining a fork is not fun :)

grosser commented Oct 22, 2015

Something that just changes the url would be great ... maintaining a fork is not fun :)

@douglascamata

This comment has been minimized.

Show comment
Hide comment
@douglascamata

douglascamata Oct 22, 2015

What about we submit a patch do rubysec/bundler-audit with support to using multiple/another databases and, of course, use ruby-advisory-db as default? Or maybe command-line option to check for memory leaks instead of bug can be abused maliciously?

What about we submit a patch do rubysec/bundler-audit with support to using multiple/another databases and, of course, use ruby-advisory-db as default? Or maybe command-line option to check for memory leaks instead of bug can be abused maliciously?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment