Homebrew-core: PSA: [email protected] users should run "brew install gnupg"

[ilovezfs]

Users who have [email protected] (or the old homebrew/versions/gnupg21) please do the following:

brew update
brew uninstall -f [email protected] gnupg21
brew install gnupg

The current gnupg formula in homebrew/core is now 2.1.x so you will be getting the same version you have now, but this manual step is necessary in order for you to get future upgrades and revision bumps of the formula.

TL;DR: The reason for this inconvenience is that the gnupg2 formula was renamed gnupg, and we can only have one "old name" at a time. The gnupg2 => gnupg rename is responsible for getting the people who have 2.0.x upgraded to 2.1.x, which means the old name needs to be gnupg2 not [email protected].

[chrisfinazzo]

This is probably due to being still on Xcode 7.3.1 + CLT + and old version, but brew doctor also warns about unlinked kegs - specifically dirmngr and gpg-agent. Can I just uninstall and then explicitly request 2.1 by tapping homebrew/versions?

$ brew info gnupg
gnupg: stable 1.4.21 (bottled)
GNU Pretty Good Privacy (PGP) package
https://www.gnupg.org/
/usr/local/Cellar/gnupg/1.4.21 (57 files, 5.4MB) *

[ilovezfs]

@chrisfinazzo

brew update
brew uninstall -f --ignore-dependencies $(brew deps gnupg)
brew upgrade

[chrisfinazzo]

Even when specifying gnupg, Hmm. Does this _have_ to be in a subshell?

$ brew uninstall -f --ignore-dependencies $(brew deps gnupg)
brew uninstall, rm, remove [--force] [--ignore-dependencies] formula:
Uninstall formula.

If --force (or -f) is passed, and there are multiple versions of formula
installed, delete all installed versions.

If --ignore-dependencies is passed, uninstalling won't fail, even if
formulae depending on formula would still be installed.

Error: Invalid usage: This command requires a keg argument

[ilovezfs]

It means your homebrew/core is outdated, as that would be the message when brew deps gnupg itself outputs nothing, which would not be the case with an up to date homebrew/core respository.

[ilovezfs]

Rendering this moot temporarily: https://github.com/Homebrew/homebrew-core/pull/12141.

[orome]

This has left me (and my Homebrew installation) very confused about what I need to have for a full
GnuPG Tools maintained with Homebrew. I currently have:

• gnupg
• gnupg2
• gpg-agent
• gpgtools (as a cask)

Can I prune some of these? Are they all necessary? Are any redundant (or interfering)?

[ilovezfs]

In general, you need these:

gettext
gmp
gnupg
gnutls
libassuan
libffi
libgcrypt
libgpg-error
libksba
libtasn1
libunistring
libusb
libxml2
nettle
npth
p11-kit
pinentry

Alternatively, just GPGTools alone from cask is sufficient.

If you want both GPGTools and a compatible non-cask formula version, you need these:

dirmngr
[email protected]
gpg-agent
libassuan
libgcrypt
libgpg-error
libksba
libusb
libusb-compat
pinentry
pth

[orome]

So I should be able to remove gnupg, gnupg2, and gpg-agent (and dependencies) and then just install gpgtools? There's nothing in the former three that's not provided in the latter?

[ilovezfs]

So I should be able to remove gnupg, gnupg2, and gpg-agent (and dependencies) and then just install gpgtools?

Correct.

There's nothing in the former three that's not provided in the latter?

The gnupg formula provides version 2.1 whereas GPGTools only provides 2.0.

[LoganBarnett]

Reinstalling gnupg got me back on 2.1 after the auto update. Thanks!

[orome]

@ilovezfs: That (installing just gnupg and gpgtools (as a cask)) seems to do the trick and would be an answer to my SO question.

[ilovezfs]

@orome you'll want to be careful with that combination. GPGTools doesn't support 2.1 yet, so you'll likely run into the issues discussed in https://github.com/Homebrew/homebrew-core/pull/11083#issuecomment-286513994

[orome]

@ilovezfs Thanks for the warning! But GPGTools on the Mac (GPG Keychain, at least) seems to see what's in private-keys-v1.d (at least if I remove secring.gpg). Does that confirm that it's using 2.1 (despite what it says in the settings panel)?

[ilovezfs]

No. Basically, it's not going to see anything created with 2.1. Beyond that, you're playing with an unsupported configuration that may work to a certain extent. See upstream comment here: https://github.com/Homebrew/homebrew-core/pull/11083#issuecomment-286718737

[orome]

@ilovezfs Oh, I thought that private-keys-v1.d was a 2.1 thing.

[JCount]

Currently, since it uses GnuPG 2.0.30, gpgtools is entirely incompatible with GnuPG 2.1.x. Any keys that GnuPG 2.1 uses and stores in it's new keystore format will be completely unavailable to gpgtools. Trying to use both GnuPG 2.0.30 and GnuPG 2.1.x at the same time, (which is what you are doing), is playing with 🔥.

[orome]

@JCount So what's going on when GPG Tools is able to see and use private-keys-v1.d? That much seems to work fine for me. Are there other issues I'm not seeing that will bite me at some point?

[JCount]

To ease the migration to the no-secring method, gpg detects the presence of a secring.gpg and converts the keys on-the-fly to the the key store of gpg-agent (this is the private-keys-v1.d directory below the GnuPG home directory (~/.gnupg)). This is done only once and an existing secring.gpg is then not anymore touched by gpg. This allows co-existence of older GnuPG versions with GnuPG 2.1. However, any change to the private keys using the new gpg will not show up when using pre-2.1 versions of GnuPG and vice versa.

from https://www.gnupg.org/faq/whats-new-in-2.1.html

[JCount]

Essentially, they can technically be installed at the same time, but you cannot use both at the same time feasibly.

[ilovezfs]

Regarding 2.1 support for GPGTools, I suggest you track https://gpgtools.lighthouseapp.com/projects/66001/tickets/142-update-to-gnupg-21

Also see the most recent discussion of it here: https://gpgtools.tenderapp.com/discussions/problems/51244-inquiry-about-the-state-of-gnupg-21x-support-as-20-approaches-eol

[orome]

@JCount That's what's confusing me:

However, any change to the private keys using the new gpg will not show up when using pre-2.1 versions of GnuPG and vice versa.

GPGTools sees changes to private-keys-v1.d.

[JCount]

I have done my best to convince you that what you are doing is inherently risky, and feel free to read more of the page I linked to. Just because things may seen to be fine, it is quite likely not to be the case. My strong advice is to pick one version of GnuPG, and stick with it.

There really is no reason to debate this topic further, because you will decide what you will, and this is really straying way outside the bounds of Homebrew. If you want to discuss this further, doing so with individuals who are part of the GPGTools community is really a more appropriate audience and venue.

[orome]

@JCount I'm not trying to frustrate you. It's just that all of the information I've (already) read here describes behavior I'm not seeing. So I'm trying to understand why that is. I'm not disputing that what I'm doing may be generally risky, but my reading of what these references say is specifically that GPG Tools will not use or respond to changes in the new location of private keys, but that's not the case (for me). So somethings wrong.

[MikeMcQuaid]

This has moved far from "Homebrew issue" into "chatting about GPG" so: locking.