But sadly I can't see any problem with the mail. Looking at the source of the mail it has the image as one attachment. That attachment is displayed. There are no other attachments part of the mail and so other clients also only show that one attachment.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 2 2019
yes I got the screenshot but they sadly did not tell me much. I don't have a good idea right now why it does not work for that one account.
Fix missing curly brace.
May 1 2019
Thanks !
This change has been pushed to repository.
This change has been pushed to repository.
+
Thanks, WK
But before, I have a dumb question-> I need to connect the wires first, isn't it?
++
Apr 30 2019
I have sended the email...
Put
log-file /somewhere/scd.log debug ipc,cardio verbose
into ~/.gnupg/scdaemon.conf and kill scdaemon. Then look at the output. I would suggest to first stop the pcscd so that GnuPG's internal CCID driver will be used. Make also sure that there is no a permission problem with the usb port. In case of a CCID (card reader protocol) problem a
debug-ccid-driver
in scdaemon.conf will also be helpful.
Without -no-undefined, libtool refuses to create the shared library (dll) on Cygwin, because libtool knows that creating a shared library (dll) on Cygwin does require all symbols to be defined.
Unfortunately but traditionally, by default libtool has to assume a library being created will have undefined symbols.
Hence, if the library to be created is designed to have all symbols defined, libtool needs to be informed about this fact using the -no-undefined flag.
This flag does allow libtool to create a shared library even on platforms known to require all symbols to be defined for shared libraries.
@werner Here are the patches:
If you have a patch please send it either by mail to gnupg-devel or attach it here. Thanks.
Please explain in more detail what the problem with Cygwin is.
In T4457#124752, @matheusmoreira wrote:I thought about building a list of keys targeted for deletion so gpg can then ask the user to confirm the deletion of each key individually.
So long I change between smart cards, I can do it multiple times. If a Yubikey is recognized and a smart card follows next it will not work. Most recently I face also problems to detect the Yubikey (Message: no such device), but Smart Cards still working fine.
Did you get the screenshots from Thunderbird (works fine in both accounts) and Outlook (failure in one account)? If not, please provide e-mail address.
Apr 29 2019
Since 2.1 the standard use of gpg-agent is to have it started on demand by the components which require it. The use of
"gpg-agent --daemon /bin/sh " should be used for debugging only.
Request for key | Thu, 7 Jun 2018 11:48 +0200 |
Reply from us | Thu, 7 Jun 2018 19:05 +0200 |
Report date | Fri, 8 Jun 2018 09:14 +0200 |
Fix committed | Fri, 8 Jun 2018 11:09 +0200 |
Announcement and release | Fri, 8 Jun 2018 15:41 +0200 |
With the last release we improved the handling of sent mails, again.
Without more reports and without the info needed to analyze this further I'm lowering the priority.
I've applied your patch with an additional comment to our master branch. Thanks!
Apr 28 2019
Email did not get through (should use plain old text email), so I prepared patch myself. See D477, https://dev.gnupg.org/D477
Apr 27 2019
@dkg, thanks for the feedback. I read [doc/HACKING](https://www.gnupg.org/faq/HACKING.html) and revised the commit message so that it contains ChangeLog entries and a marker line before my description. I compared my new message to prior log entries and they seem to match now. Is this appropriate? If so, I will revise my other commits in the same manner.
Thanks for this work, @matheusmoreira ! I personally think a reusable function in common/ would be preferable, but it's probably up to @werner to decide what's best here.
Apr 26 2019
@dkg Sure! I thought I was supposed to email the patches to the development mailing list. [I've uploaded my delete-secret-subkey branch to GitHub.](https://github.com/matheusmoreira/gnupg/tree/delete-secret-subkey) You can see a comparison here. I'll describe my changes.
I think this can go to wontfix for now. Inline PGP inside of S/MIME,.. well that is not good.
I am pretty sure that this had the same underlying cause as T4332 which was fixed with Gpg4win-3.1.7
With the new keytreeview since 45f27eb3940617a8daff9b218b066ac482b9515d this is resolved.
This was fixed with c591cb20edfe70de29d343a6ce13c4b710bdeba6
This was resolved in a different way.
This was fixed.
Closing this as invalid until the info requested in the last comment is provided.
@werner This issue also applies to GPA. Looking at the edit key interface I can't see how we can handle this. Am I overlooking something or do we just loose the error information / is it not emited by gnupg?