I have enabled login again and added the following login hint:
"Login via your Roundup account on bugs.gnupg.org has been disabled due to the migration to Phabricator. We apologise for any inconvenience caused. If you have previously used your Roundup account in this wiki, you can request a new password using the link above."

Perfect! This works exactly as I wanted. I indeed use Fedora 26, adding this line below to my .bash_profile works perfectly with the Yubikey to find the gpg keys on it and use it for ssh.
export SSH_AUTH_SOCK=$XDG_RUNTIME_DIR/gnupg/S.gpg-agent.ssh

Please use the systemd unit files as shipped upstream. This allows the agent to be launched automatically whenever someone tries to use one of its sockets, but doesn't pre-emptively launch the agent until needed.

Hi. You can start gpg-agent using gpgconf --launch gpg-agent. I'll delegate the systemd questions to Daniel.

As said that is a distro thing and nothing we, as upstream authors, will decide for those who build gnupg on their own. Reading README and following migration instructions is a MUST for everyone installing a new version of a software.

99.9% users will upgrade to gpg2.1 once and never think about downgrading. On Debian for example, to get gpg 1 or 2.0 back, you'd need to rollback the whole dist-upgrade which is so tricky (and officially unsupported) that restoring the whole system from a backup is the only realistic option. Thus, offering to delete secring.gpg on key deletion wouldn't be obnoxious at all. Secret key deletion already asks a number of questions, one more wouldn't be bad. I guess deleting secring.gpg when the passphrase is being changed would be a good idea, too.

It is there for a purpose. If the distros want to enforce a certain policy, they can do that. But we can't do that.
Sure, we could print a warning note. But then we would need to print a lot of warning notes all over the place to the effect that nobody will care about that and ask for an option to silence them.

The migration documentation is something distro maintainers read, but it's humanly impossible for an user to read all such documentation on every of several thousand packages on a dist-upgrade.

Stephan released revised document which should fix this.

I would not say that this remark is in a dark corner. Migration steps are actually important for, well, migration to a new version.

Thanks, fixed in 01c68a6a.

See here in current code. https://dev.gnupg.org/source/gnupg/browse/master/g10/keygen.c;cea4313644b531ef87b8c8e4bfddde4388cbbe0d$2375

GnuPG allows an ISO date at the prompt since 1999, see bd7298cf0d, but it is not apparent from the prompt (hidden feature).

Fixed in cea431364.

Well, we don't maintain a wiki, so I think this should be tracked elsewhere.

In T3284#100822, @werner wrote:

No. gpg-agent is a different implementation of the ssh-agent protocol than ssh-agent. Making the keys persistent is on purpose.

No. gpg-agent is a different implementation of the ssh-agent protocol than ssh-agent. Making the keys persistent is on purpose.

But that is not very user friendly. I wasn't aware of that way to list and delete keys for example.

Note that you can do

There are two issues here.

Hi Justin

this discrepancy is easily explained. You are entering a date that is interpreted as UTC, and it is echoing it back using your local time zone. PST is UTC−8:00, matching the output.

My point is that without clear documentation of what is expected, it's pretty hard to tell whether the code is even working or not. Sounds like it isn't :(

Is this correct?

I don't think this issue is actually resolved. there's a feature here (i think) but it's not documented to the point where anyone can figure out how to use it. If there's no way to use it, the feature should be removed (or at least deprecated).

Nobody provided a better description, so I am closing here. Of course, we can still add one if somebody wants to improve it.

The passage has been removed from the dirmngr man page, and I marked the gpgsm option as obsolete.

I removed the man page and the link for now. Currently there doesn't seem to be an easy way to update it automatically.

Maybe this can be done by Neal along with the book?

T1967: GnuPG should select a key for signing without trying to use missing subkeys and T1983: gpg2 prefers missing secret key to available key on card is related, possibly.

No way to fix, itself. Better warning/error message can be done.

The page now links to the Wiki which makes sure that things are up to date.

Ubuntu uses a bad combination of an older gpg version and a more current
libgcrypt version. We can't do anything about it. Someone may want to escalate
this to Ubuntu; they should definitely get an update out.

Fixed in 135185b7.

By resolved, I meant that the man page now states:

  gpgv  assumes  that  all  keys in the keyring are trustworthy.  That does also
  mean that it does not check for expired or revoked keys.

Your wish is to change this behaviour. This would be an API break and thus I
hestitate to do this for 1.4 and 2.0. However, 2.1 has a lot of changes anyway
and I think it is okay to change it for 2.1.

I don't think this is actually resolved.

As noted in https://lists.gnupg.org/pipermail/gnupg-devel/2016-April/031032.html
, gpgv accepts signatures made from revoked or expired keys.

It should reject signatures made from keys it believes to be revoked or expired.

The attached tarball contains:

     pubkey.gpg -- a binary-format 2048-bit RSA OpenPGP certificate

     C47D9EDFF117EE2AA11B162D017D715B3D0C4AF2.key -- the corresponding
                                                     secret key (for
                                                     reference/experimentation
                                                     only)

     before.txt.asc -- clearsigned message made by the key before
                       certificate creation time

     during.txt.asc -- clearsigned message made by the key between
                       certificate creation and certificate expiration

     after.txt.asc -- clearsigned message made by the key after certificate
                      expiration

of these, gpg approves of during.txt.asc and after.txt.asc, but not before.txt.asc.

If someone comes up with a brief description on how to use it, we can add it.

I'm not convinced that the +-prefixed lines address clint's concern.

In particular, the parenthetical remark "(domain means the domain part of the
mail address)" is the important bit -- will this be documented somewhere?

I have added this note to the description of the tsign command in the gpg man
page from master (2.1). Won't be changed for 1.4.

+ or groups. For more information please read the sections
+ `Trust Signature'' and `Regular Expression'' in RFC-4880.

(domain means the domain part of the mail address).

Removed from doc with commit d877528

Hi Justus,
my report describing the problem, not proposing a solution.
(I think that most report should describe the issue,
so that good solution ideas can be measursed against how could they
solve this and other problems.)

If there is no technical reason to have --faked-system-time
in 2.0.x, I guess that fixing the documentation is the easier solution.

I don't understand the bug report. Do you want the feature backported or the
documentation fixed?

Fixed in c7cb4008. This will take effect next the web site is published.

This is a feature of the org-mode export. I'm looking into this.