Comments (15)
That would be ok for people wanting to compile a package. But then when the package gets distributed and other systems don't have the certifications in /usr/local/etc/openssl
the program will not be able to do https requests.
from ruby-packer.
Thanks for reporting. Let me re-produce it locally and debug ASAP.
from ruby-packer.
FYI: Under 0.4.0, no change.
from ruby-packer.
Probably the compiled package cannot use the certificates on the system and it doesn't have any included. You could use something like this gem https://github.com/liveeditor/net_http_ssl_fix to fix the issue.
from ruby-packer.
@yourivdlans
Okay. But it doesn't do this in Ruby. And given that this is a very simple test program that only uses stdlib, shouldn't this be documented as part of the install instructions, at least?
I mean, I would really like the Ruby deployment story to be better. So I tried this with a simple program and it didn't work. So I gave up on it, nearly a year ago. Which is presumably not what you want people to do.
from ruby-packer.
@andy-twosticks I fully agree, its not ideal. Compiled programs not using https will probably run fine. I assume the developers hadn't seen this edge case before.
Last resort could also be to disable the certificate verification, but also not an ideal solution.
from ruby-packer.
Can you run:
ruby -e "require 'openssl'; puts OpenSSL::X509::DEFAULT_CERT_FILE"
and:
ENCLOSE_IO_ALWAYS_USE_ORIGINAL_RUBY=1 ENCLOSE_IO_USE_ORIGINAL_RUBY=1 ./a.out -e "require 'openssl'; puts OpenSSL::X509::DEFAULT_CERT_FILE"
If these are not the same directory then we need to tweak openssl configuration.
I think you can work around the problem by setting SSL_CERT_FILE
to the one ruby
shows.
from ruby-packer.
This is my output:
$ ruby -e "require 'openssl'; puts OpenSSL::X509::DEFAULT_CERT_FILE"
/usr/local/etc/openssl/cert.pem
$ ENCLOSE_IO_ALWAYS_USE_ORIGINAL_RUBY=1 ENCLOSE_IO_USE_ORIGINAL_RUBY=1 ./a.out -e "require 'openssl'; puts OpenSSL::X509::DEFAULT_CERT_FILE"
/usr/local/ssl/cert.pem
from ruby-packer.
I think rubyc
can configure openssl to change where DEFAULT_CERT_FILE
points
from ruby-packer.
I've done a bit of testing and come to the following conclusions:
- Using 0.4.0 building openssl with
--openssldir=/usr/local/etc/openssl
will ensure the build succeeds (so gems from https sources get downloaded). But when moving the packaged file to another system that doesn't have the certification in that location it will not be able to do https requests. - Using master it seems I can compile without trouble but I'm not able to run a compiled rails app.
Possible solution:
Would it be an idea to download a certification or copy from the local disk during the build process and placing it in the work dir, then pointing openssl to that dir?
Although then there is the possibility the certification will get outdated and the app will break. Not sure what the best solution is here.
from ruby-packer.
Setting --openssldir
can be exposed as an option for the user running rubyc
, and a default of /usr/local/etc/openssl
seems OK?
from ruby-packer.
I had a look at traveling-ruby
to see how they solved this problem and this is what I found.
- They also compile their own version of openssl but they set the
--openssl-dir
to the path they compile openssl in. - They have a copy of the
ca-bundle.crt
in their repository. - They compile ruby with
--with-openssl-dir
pointing to their compiled version of openssl. - Then they copy the
ca-bundle.crt
to the dir they are packaging ruby from and setting theSSL_CERT_FILE
env var.
So I assume they package root certificates which allows any system / user to run the package regardless of their own certificates installed on the system.
I'd suggest ruby-packer
should do something identical, what do you think?
from ruby-packer.
If we bundle certificates then when CA certificates expire or are revoked rubyc must be recompiled, then users must fetch rubyc, then recompile their application, then distribute their application.
Users can be vulnerable to connection hijacking even when the site they're connecting to doesn't use certificates signed by that CA (although the CA was revoked, it is still included thus still trusted). It will mean a CVE for rubyc if they're bundled inside rubyc, so I don't want to bundle them inside ruby-packer as the maintenance burden is far too high.
Omnibus can download and install the bundle from curl which removes the need to recompile and distribute rubyc, but not the need to recompile the user's application. This is OK, but leaves the expiration and revocation maintenance burden on the application packager and they may not be aware of it.
I prefer to have the packager manage certificates in an informed way. I think it is OK to allow users to make the choice to bundle certificates inside their executable, but it should come with warnings about and protections for the security risks.
As a first pass I would prefer to make the openssl dir configurable so packagers can instruct users in how to configure their CA certificate list. Other applications they deploy may already be configured to use the same store, so this may be a no-op. (Homebrew on macOS allows easy installation and maintenance of CA certificates and I believe most linux distributions have the same. We don't compile OpenSSL on Windows yet, but eventually we'll need to point to someone's method of adding CA certificates for Windows.)
A follow-up may allow users to place trusted CA certificates in a directory that ruby-packer will package into their executable. This should allow users to balance their vulnerability exposure. RubyGems follows this pattern and bundles only the CA certificates for the servers it connects to to limit vulnerability upon revocation of unrelated CA certificates.
from ruby-packer.
Users can be vulnerable to connection hijacking even when the site they're connecting to doesn't use certificates signed by that CA (although the CA was revoked, it is still included thus still trusted).
Very good point.
As a first pass I would prefer to make the openssl dir configurable so packagers can instruct users in how to configure their CA certificate list.
Alright yeah, thats a good first step.
This should allow users to balance their vulnerability exposure. RubyGems follows this pattern and bundles only the CA certificates for the servers it connects to to limit vulnerability upon revocation of unrelated CA certificates.
Really like this idea!
Thanks for the clear explanation. I'll try and create a pull request for that first step today :)
from ruby-packer.
I'm running into this issue as well... any hopes of seeing a solution for this?
from ruby-packer.
Related Issues (20)
- Pack more files HOT 2
- Can not build with Ruby 3.0.0 HOT 1
- Implicit declaration in C99 error when packing a rails project using Ruby 2.4.10 HOT 3
- Error loading nokogiri when starting compiled binary HOT 14
- The build is broken, due to Rubocop error
- rubyc not starting anymore since enclose.io is down
- Dir.glob returns inconsistent results inside memfs
- Reading from memfs file is not thread safe
- `require` is 10 times slower in packed ruby
- Is it possible to compile for Linux but on a Mac?
- Fails to build with both Stable and Pre-release HOT 1
- [Documentation] Differences to ocra?
- how to install another gems in linux system HOT 1
- TestFailed! nmake /f win32\Makefile.msc Failed running HOT 1
- Error building executable gem: error compiling squash.c
- Provide a GitHub action to setup and run rubyc
- Manual pages not compiled HOT 1
- ruby-packer sets BUNDLE_GEMFILE inside the running script
- Build error HOT 1
- ** Ruby-packer replacement, maintained **
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ruby-packer.