What's in daily use for 15 yrs? GPGME? I thought GPGME was new, but in any case it's broken in the cases mentioned in that thread.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 12 2018
Feb 10 2018
Feb 1 2018
Originally dirmngr was designed to be a system service for the reason that CRLs are not user specific. However, the majority of systems today are used by a single user and thus we dropped that feature when integrating dirmngr into gnupg.
Jan 31 2018
Come on, it is in daily use for 15 years. MUA which can't handle MIME at all but PGP are still able to decrypt PGP/MIME. That is why ME specified PGP/MIME this way.
Nov 15 2017
Thanks for noticing. I've changed it and clarified that GpgOL is for Windows only and not for the Outlook Web App / Android or Mac.
Nov 14 2017
Nov 13 2017
Nov 12 2017
Ah well, no rules without exception.
Oct 24 2017
We could signal an error. However, that would break existing behaviour and can only be done for 2.3.
Oct 20 2017
Oct 11 2017
Thanks. I added you to the wiki page.
Oct 10 2017
thanks for the links to documents.
we've setup submisson-address and policy links.
Sep 28 2017
oh ... I see thanks. I am thinking now about an analogy between the place where I live in real life and the unix home directory, (also called a login directory). Very interesting indeed ...
Did just that in master and 2.2.
Sep 27 2017
Sep 25 2017
article 13 states the inviolability of the home ;-)
Sep 24 2017
I do like to read about historical facts, motivations, etc ... as far as I know 'g10' is related to artikel 10 grundgesetz...
Sep 19 2017
OK, I changed my own purpose. I don't touch internal representations.
Sep 12 2017
I'm fine with (and i totally understand) wanting nothing but UTC in the machine interface and internal representations.
[copied from gnupg-devel@]
Sep 8 2017
I think any existing script that assumes UTC should add an explicit Z suffix. (that is, i don't think the breakage is a big deal, and anyone writing scripts that needs this kind of precision will be more likely be thankful that we have a sensible, normalized interface).
It is pretty much confusing. When a user specify in YYYY-MM-DD format with no hh:mm:ss, it is interpreted as local time (noon of that day).
When a user adding Thh:mm:ss, it is UTC.
While I confirmed that GnuPG interprets YYYY-MM-DDThh:mm:ss in UTC (which should be interpret as local time according to ISO-8601), I don't know how we can fix this.
If I change the interpretation of GnuPG (possibly supporting the format with Z suffix and timezone), it may break existing script which assumes UTC.
Bug confirmed in rGa766a37290cf: Print keyid in gpg --list-packets..
fwiw, i agree that GnuPG should interpret these as ISO-8601 strings. At the very least:
Aug 21 2017
Aug 18 2017
Aug 16 2017
I guess for older releases it is less relevant to have very accurate version information. From now on this is more a regular maintenance task than a unit of work, so I am closing it.
Gave it a head-start.
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."
Aug 15 2017
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
Aug 14 2017
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.
Aug 10 2017
Aug 8 2017
Aug 4 2017
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.
Aug 3 2017
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.
Jul 31 2017
Jul 26 2017
Thanks, fixed in 01c68a6a.
Jul 20 2017
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.
Jul 19 2017
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.
Jul 18 2017
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.
Jul 17 2017
Jul 14 2017
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).
Jul 13 2017
Nobody provided a better description, so I am closing here. Of course, we can still add one if somebody wants to improve it.
Jul 2 2017
Jul 1 2017
The passage has been removed from the dirmngr man page, and I marked the gpgsm option as obsolete.
Jun 30 2017
I removed the man page and the link for now. Currently there doesn't seem to be an easy way to update it automatically.
Jun 29 2017
Maybe this can be done by Neal along with the book?
Jun 28 2017
Jun 13 2017
Jun 8 2017
May 5 2017
Apr 28 2017
Apr 27 2017
Apr 11 2017
No way to fix, itself. Better warning/error message can be done.
Mar 30 2017
Mar 2 2017
The page now links to the Wiki which makes sure that things are up to date.
Feb 23 2017
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.
Jan 2 2017
Dec 22 2016
Aug 2 2016
Fixed in 135185b7.