Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support for additional sources from the environment #2141

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
4 participants
Contributor

brettporter commented Nov 1, 2012

For issue #2140

Contributor

brettporter commented Nov 2, 2012

Sorry, didn't mean to leave 8bec6a0 in there, obviously...

This environment variable supports adding additional sources that may be
specific to your environment, without having them added to the Gemfile.lock
file. This is particularly useful for configuring private repositories that
may need to store personal credentials.

mkb commented on b7043d2 Nov 2, 2012

This looks great.

If you prepend the env sources rather than append, it reduces the risk of a malicious public game eclipsing a private one.

Owner

brettporter replied Nov 5, 2012

That's a good point, I'll adjust.

Owner

brettporter replied Nov 5, 2012

I reviewed, and it seems that appended sources are already the way to achieve that - it is last wins. Added a spec to the branch to confirm this behaviour.

Owner

indirect commented Nov 19, 2012

So I'm not terribly sure about this. The main problem is that allowing this setting means that someone checking out the code literally will not be able to install the Gemfile. I have an alternative that (I think) will solve the same problem.

How about if Bundler stores the username and password for authenticated gem repositories in the bundle config, instead of the entire authenticated source URL? That means you can still include the source in the Gemfile, and installing that Gemfile will simply prompt you for the creds when a 401 comes back, and then save those creds for future installs that depend on that source. What do you think?

Contributor

brettporter commented Nov 20, 2012

The user/password configuration would certainly be useful, as long as it could be pre-configured in a headless environment. In that case, I'd also need something like #2062 where you could direct requests through a proxy gem server.

I'm using this in one case to avoid propagating the URL & credentials across multiple internal projects, and instead just specifying once in the build environments.

The other use case I've seen is for Gemfury, which has a private access URL (which is read/write), which you don't necessarily want to bake into a project's version control even if it contains required gems, or make the project's source code private just to obscure the location of the repository.

I agree with indirect: not being able to install the gemfile is a major flaw here.
Working around the flaws of an unauthorised service (like Gemfury) seems to me only to be obscuring the fact that the service is inherently insecure.

The alternative suggested seems like a better idea...

@indirect indirect closed this Aug 4, 2013

Why was this closed? As #2140 was closed too, there is no open reference nor final answer to this request anymore.
I still like the suggestion made by @indirect, what about creating a ticket for storing username/password in the bundle config?

Owner

indirect commented Aug 5, 2013

As discussed in this ticket, keeping required credentials in Bundler's config is definitely at odds with the idea that having the repo means you can install and use the dependencies of that repo. That said, I'm not opposed to creds in bundle config, so feel free to send a pull.

On Sun, Aug 4, 2013 at 10:51 PM, Bert Bruynooghe notifications@github.com
wrote:

Why was this closed? As #2140 was closed too, there is no open reference nor final answer to this request anymore.

I still like the suggestion made by @indirect, what about creating a ticket for storing username/password in the bundle config?

Reply to this email directly or view it on GitHub:
#2141 (comment)

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