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

[FooBarWidget]

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]

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]

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]

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.

[FooBarWidget]

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]

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]

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