New implementation for signing releases #274

danielsz · 2015-08-18T14:52:53Z

Client libraries like bootlaces should not have to configure anything.
Signing and encrypting in Boot-clj works out of the box, with no configuration. This can be made to work because we are going to make assumptions about the end user's environment. In turn, those defaults will be capable of being overridden with environment variables.
Secret keyring location is the default one ($HOME/.gnupg/secring.pgp). Can be overridden with BOOT_GPG_SECRING.
Name/Email is the one we find. Provided the secret keyring has only one user, we can be sure that we have the correct one. If more than one are found, we throw an error. Name/Email can be set with BOOT_GPG_USER.
Default signing key is the first one returned by (keyring/list-public-keys keyring). This will work on a straightforward GPG setup. If the user follows best practices and has derived subkeys from his master keypair, he can set those with BOOT_GPG_SIGNING_KEY_ID and BOOT_GPG_ENCRYPTING_KEY_ID.

* Client libraries like bootlaces should not have to configure anything. * Signing and encrypting in Boot-clj works out of the box, with no configuration. This can be made to work because we are going to make assumptions about the end user's environment. In turn, those defaults will be capable of being overridden with environment variables. * Secret keyring location is the default one ($HOME/.gnupg/secring.pgp). Can be overridden with BOOT_GPG_SECRING. * Name/Email is the one we find. Provided the secret keyring has only one user, we can be sure that we have the correct one. If more than one are found, we throw an error. Name/Email can be set with BOOT_GPG_USER. * Default signing key is the first one returned by (keyring/list-public-keys keyring). This will work on a straightforward GPG setup. If the user follows best practices and has derived subkeys from his master keypair, he can set those with BOOT_GPG_SIGNING_KEY_ID and BOOT_GPG_ENCRYPTING_KEY_ID.

micha · 2015-08-18T15:13:27Z

boot/core/src/boot/task_helpers.clj

-(defn read-pass
-  [prompt]
-  (String/valueOf (.readPassword (System/console) prompt nil)))
-


We may want to either keep this or move it to boot.util? It seems like a handy function to have hanging around.

@micha it's still in boot.pgp but I agree that a fn reading user input/passwords could be in boot.util as well.

frankiesardo · 2015-08-31T01:26:15Z

boot/worker/src/boot/pgp.clj

+          (#(keyring/get-secret-key keyring %))
+          (pgp/unlock-key passphrase)))))
+
+(defn read-pass


I'm concerned about having a prompt as the only way to pass a passphrase around. Unattended builds (CIs) need another option to be able to run. Maybe it's possible to use the .gpgconf? I know you can specify passphrase=.. in it.

The current approach was to use a Java API as opposed to shelling out to the gpg binary, so .gpgconf does not apply.
Generally speaking, using the passphrase switch should be avoided. Passing the passphrase automatically can be achieved with gpg-agent. But this also relies on the gpg binary.

A straightforward solution to your concern would be to add a BOOT_GPG_PASSPHRASE environment variable that, if set, will be used instead of the prompt.

I know, lein uses gpg-agent which I quite like as an approach because it shifts complexity on the tool itself that you can configure using .gpgconf. I'd rather have push accept optionally the passphrase so in my CI machines I can have a profile.boot that does (task-options! push {:passphrase "My pass"}). Environmental variable might be overkill in this case.

Re: environmental variables adding another one might be more in line with the implementation of this pull request, but I'm actually arguing it would be better to remove all of them and pass them explicitly as optional arguments (making the configuration explicit when you call the function rather than relying on the global environment state). Just my 2 cents.

In the current PR, GPG configuration is driven by environment variables. They are documented here: https://github.com/boot-clj/boot/wiki/Deploying-with-Boot
For consistency's sake, the passphrase feature would be just an additional environment variable. Furthermore, the advantage of an environment variable is that the user can use a third-party library like bootlaces to deploy artefacts. He doesn't need to deal directly with the push task, and yet he still retains control over configuration options.

I think He doesn't need to deal directly with the push task, and yet he still retains control over configuration options. is a non-argument. Rather than having my configuration nicely in a profile.boot now I need to export an environment variable.

Each environment variable you add to the project adds global complexity and clutter. If it's only used by one task, then why not it be a parameter to the task itself? You get automatic documentation for it and you can set it programmatically rather than shelling out.

I mean, fine by all means if you want to give the option to drive the implementation via env vars, but don't take away the task options: they are much more easier to use and repl-friendly.

I have no problem with whatever configuration mechanism we are going to adopt. This PR is a proof of concept that can be refined and finalized by others. @micha has started this https://github.com/adzerk-oss/env which will likely address this problem. Please feel free to contribute to this PR.

danielsz · 2015-10-16T05:15:36Z

@micha @alandipert Bumping this PR. Is there something I can do to help get this accepted. I would love to hear your comments or reservations. If I remember correctly, this PR doesn't break anything.

Deraen · 2015-10-18T15:49:56Z

The implementation looks good but I feel strongly that gpg-agent should be used instead of password prompt.

Deraen · 2015-10-18T15:57:43Z

Is there a reason for not using gpg binary for everything? Leiningen is doing it and I don't see any problems with it. In this case I think it would be the best to do what everyone else is doing.

micha · 2015-10-18T16:00:55Z

I didn't use the gpg binary mainly for windows support. Also I always have trouble with configuring Leiningen with GPG (notice boot itself isn't signed because I can't get it to work reliably).

Deraen · 2015-10-18T16:03:59Z

Leiningen docs mention GPG4Win: https://github.com/technomancy/leiningen/blob/master/doc/GPG.md#windows

micha · 2015-10-18T16:13:13Z

I'm on board with using gpg, especially gpg-agent. Since it uses unix domain sockets we can't do it from java, unfortunately, and will have to shell out to gpg.

Deraen · 2015-10-18T17:18:11Z

I did quick test with gpg binary using code from Leiningen: https://github.com/Deraen/boot-contrib-gpg/blob/master/src/deraen/boot_contrib_gpg.clj

In addition to signing, it supports reading repository credentials from ~/.boot/credentials.edn.gpg.

danielsz · 2015-10-18T23:05:26Z

Awesome. Any implementation solving the limitations of the current one is a big win. Leveraging gpg-agent for configuration-less signing and reading credentials is also a big win.

Deraen · 2015-11-08T14:58:55Z

I merged the alternative implementation using GPG binary.

danielsz mentioned this pull request Aug 18, 2015

Push task makes assumptions regarding pgp setup which negate best practices #255

Closed

micha reviewed Aug 18, 2015
View reviewed changes

martinklepsch added this to the 3.0.0 milestone Aug 19, 2015

frankiesardo reviewed Aug 31, 2015
View reviewed changes

Deraen mentioned this pull request Oct 18, 2015

Use gpg binary for signing and reading credentials from encrypted file #311

Merged

Deraen closed this Nov 8, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New implementation for signing releases #274

New implementation for signing releases #274

danielsz commented Aug 18, 2015

micha Aug 18, 2015

martinklepsch Aug 18, 2015

frankiesardo Aug 31, 2015

danielsz Aug 31, 2015

danielsz Aug 31, 2015

frankiesardo Aug 31, 2015

frankiesardo Aug 31, 2015

danielsz Aug 31, 2015

frankiesardo Aug 31, 2015

danielsz Sep 2, 2015

danielsz commented Oct 16, 2015

Deraen commented Oct 18, 2015

Deraen commented Oct 18, 2015

micha commented Oct 18, 2015

Deraen commented Oct 18, 2015

micha commented Oct 18, 2015

Deraen commented Oct 18, 2015

danielsz commented Oct 18, 2015

Deraen commented Nov 8, 2015

New implementation for signing releases #274

New implementation for signing releases #274

Conversation

danielsz commented Aug 18, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielsz commented Oct 16, 2015

Deraen commented Oct 18, 2015

Deraen commented Oct 18, 2015

micha commented Oct 18, 2015

Deraen commented Oct 18, 2015

micha commented Oct 18, 2015

Deraen commented Oct 18, 2015

danielsz commented Oct 18, 2015

Deraen commented Nov 8, 2015