- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Sep 30 2019
You should always run gpg with --verbose if you run into an unknown error. It shows more information; in your case info about the requested pinentry. The strace does not show this. You probably have no permission to launch the X version opf the pinentry because the xauth does not work. As a quick test use ssh -X root@localhost instead.
Sep 29 2019
sysconfdir:/etc/gnupg bindir:/usr/bin libexecdir:/usr/lib/gnupg libdir:/usr/lib/gnupg datadir:/usr/share/gnupg localedir:/usr/share/locale socketdir:/root/.gnupg dirmngr-socket:/root/.gnupg/S.dirmngr agent-ssh-socket:/root/.gnupg/S.gpg-agent.ssh agent-extra-socket:/root/.gnupg/S.gpg-agent.extra agent-browser-socket:/root/.gnupg/S.gpg-agent.browser agent-socket:/root/.gnupg/S.gpg-agent homedir:/root/.gnupg
Please provide a full description of what you did. What command line did you use, have you su-ed or logged in regular.? What is the output of "gpgcof --list-dirs" ?
Sep 28 2019
Sep 27 2019
Do not use this legacy debug stuff. Use --debug CATEGORY. For example
OK, I identify the problem.
Sep 26 2019
Sep 25 2019
For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.
For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.
It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.
It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.
Sep 24 2019
Sep 23 2019
Sep 22 2019
Sep 21 2019
It is not just about being annoying but for security reasons. It would be too easy for other applications *think webbrowser or Acrobat) to take a screenshot and pop up a modified version of that screenshot with data entries to act as a MitM.
Sep 20 2019
$ gpg-connect-agent --dirmngr 'getinfo version' /bye
D 2.2.17
OK
Can you check which dirmngr version you are running
gpg-connect-agent --dirmngr 'getinfo version' /bye
thanks for the dns explanation - IMHO, there should be added something about that in the wiki
When it does not work for you on http1 either, then I guess, it's really just some outdatedness of my gpg/dirmngr and this ticket can be closed.
It does not work either. Your problem is the use of a wildcard DNS for archlinux32.org:
The test above was with gpg master but I got the same result with current 2.2:
ok, I disabled it again. btw: why do we need openpgpkey.archlinux32.org in the cert? Is this standard or did I misconfigure something?
Thanks. Here is a dirmngr log:
Sep 19 2019
I set archlinux32.org back to http2 - so you can see for yourself, how gpg fails to retrieve the key for buildmaster@archlinux32.org
I believe, it means, that it may fall back to http1.1 - the documentation is not clear to me on this.
A simple test however shows, that at least curl has no problems to use http1.1 or http1.0 with the http2 enabled nginx.
Does your ngix configuration mean that there is no fallback to standard http?
And it is merged into master.
Along with the support of multiple readers/token, the parts which assumes Windows 32-bit are fixed, too.
Sep 18 2019
For argparse.c, it can be only stopped with nonnull attribute for the API, I suppose.
I take this so that libgpg-error can be released soon.
Sep 17 2019
Sep 16 2019
Sep 15 2019
The feature has been implemented for the -qt, -tqt, -gtk, and -curses pinentries.
Sep 14 2019
The message has not been encrypted to you. Ask the sender to encrypt to you.
Sep 13 2019
How to fix "failed: no secret key
Sep 12 2019
This is generally the better tracker to report Gpg4win / Kleopatra issues. The git systems are linked in a way that I can both automatically add a commit here and in the KDE tracker.
I just noticed the KDE report a bit quicker because there is less traffic, but I would have seen it here within the day.
In T2300#90092, @aheinecke wrote:Ah nevermind. I think myself that this is nobug and current behavior is correct.
To implement / test the "not literally RFC compliant but in practice better" behavior let us call this now a wish and feature request as there are certificates in the wild other then intevation's and customers in large institutions run into that.
Sep 11 2019
There is no need to use the new CTB format for a packet with tag 3. OpenPGP implementations need to support all packet header encodings. We do not plan to make this configurable.