Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't ask passwords twice and allow specifying custom GPG options #23

Open
FooBarWidget opened this issue Mar 10, 2013 · 6 comments
Open
Assignees
Milestone

Comments

@FooBarWidget
Copy link

Currently gem build foo.gemspec --sign invokes gpg twice, causing it to ask for the password twice. This is annoying, there should be a way to have it ask for the password once. In our packaging scripts we ask for the password, store it in a chmod 600 file .gpg-password, invokes gpg with gpg --sign --detach-sign --passphrase-file .gpg-password ..., then delete the file.

Come to think of it, the temp password file should probably be in /tmp so that it's wiped on the next boot, in case the system crashes while GPG is running.

The ability to pass custom GPG options to gem build --sign would also be helpful. Our packaging scripts currently generates a signature for tarballs as well. With the --passphrase-file I can ask for the password once, and have GPG sign multiple files.

@grant-olson
Copy link
Owner

In my case, I use gpg2 and then gpg-agent caches the passphrase, so I only enter it once. That is one way to configure things so an actual user doesn't need to enter the password twice (or three times on rubygems 2.0).

I agree that we should probably be able to hook into gpg for the use case you outlined as well as others. I'm not sure about the best way to implement a feature like this. Something like gem build foo.gemspec --sign --gpg-arg '--passhrase-file X' seems wrong.

@FooBarWidget
Copy link
Author

By now I've also setup gpg-agent for remembering passwords.

--gpg-arg is not a very clean solution but I think it's better than trying fight GPG by wrapping it too much.

@grant-olson
Copy link
Owner

Now I'm thinking I'll just whitelist specific gpg args, and mangle the names to make it obvious they're gpg: gem build foo.gemspec --sign --gpg-passphrase-file foo --gpg-homedir ~/non_default_keyring etc. Then if we ever get to the mythical future where there is a pure-ruby back-end it's obvious does and does not require gpg.

This should go out in the next major release.

@ghost ghost assigned grant-olson Mar 11, 2013
@FooBarWidget
Copy link
Author

I read your proposal from 2 years ago and how Evan rejected it because he thinks only Ruby dependencies are acceptable. I don't think you should pay too much heed to that. Rewriting a security-critical piece of software like gpg is no small task and is prone with security errors. There are all sorts of low-level stuff that you can do in C, but not in Ruby, such as locking and clearing memory areas so that passwords are no longer in RAM and never in swap.

I believe we're all much better off relying on the real gpg than dreaming about a pie-in-the-sky Ruby version of gpg.

@grant-olson
Copy link
Owner

Agree 100% on gpg.

The hard part isn't even doing the RSA sig check, which everyone seems to think is all you need to do. It's accounting for everything in the trust calculations: (1) is the signing key's signature good, (2) has the key been revoked, (3) is it expired?, (4) Is it within 3 hops, (5) marginally or fully trusted, (6) Is the signing key self-signed, etc, etc.

But I still like isolating out the commands that just get forwarded to gpg and making that relationship explicit instead of implicit, so I'll implement as described above.

@grant-olson
Copy link
Owner

Still need to go back and deprecate the old --key and --homedir options now that we can use --gpg-homedir and --gpg-local-user

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

No branches or pull requests

2 participants