Ok I tested with Exquilla. I configured an Exchange account once through Thunderbirds built-in account (IMAP) and once with Exquilla
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 19 2018
Hey, you want to get this into 1.11.1 I assume - Let's consider this a bug fix and not another API change.
Hey, you want to get this into 1.11.1 I assume - Let's consider this a bug fix and not another API change.
Weel, you GnUPG version is actualluy the lates. Unfortunately I tested with a beta version. Let's wait a day to see whether there is more fallout and if not I will do a 1.11.1
Look like you are using an older GnuPG version and thus the test fails. I need to tweak the test.
Work is in progress, but you can already see :
- some independent changes to the build system https://github.com/gpg/gnupg/compare/master...catenacyber:fdf1ec2
- adding the code for fuzz targets and build them https://github.com/gpg/gnupg/compare/fdf1ec2...catenacyber:fd62943
- changes to gnupg code to go beyond first bugs detected https://github.com/gpg/gnupg/compare/fd62943...catenacyber:3c14d0d
I have a patch for this, but its not so good and we did not see a chance to get it upstream. For even medium sized mail accounts it already took to long as Enigmail (or better the Thunderbird Addon API) is prohibitively slow.
Thanks for the report.
I clarified the title a bit to include exchange / exquila.
Let's use the new issue as the problem is described completely there and it makes it more clear.
This was done.
No problem :).
Currently I cannot access this newer pinentry release.
My .bashrc is almost default, hence it doesn't have the line you requested.
Apr 18 2018
Mh, we can probably drop the GPGME part of this. In the longer term I'm hoping for the automatic refresh in dirmngr. So that refresh-keys would not be needed.
Are you asking for a way to --refresh-keys via GPGME? IF so shall that be a syncronous thing or just a trigger. Note that we the last update time is already part of gpgme_key_t and can thus be used to check whether a trigger worked.
Anyway this will be a larger change and may need gpg support.
I already created a new issue for this in the new version of gpg4win (v3.1.0) with GpgOL v2.1.0. This is the issue: T3917.
Thanks for looking into this issue :-)
You may want to check with Hanno Böck
Apr 17 2018
Ben: We need to use a faked system time thing to make those tests more stable.
I backported the fix for 1.8.3.
The semantics of --list-only are not well defined. Needs some overhaul.
Cherry-picked this for 1.8.3.
FIPS rules changed anyway and thus more rework will be needed anyway. I keep this open at low priorirty.
This is a build system setup problem with standard solutions.
An option to ignore SRV records would also be good for debugging. Thus I raised the priority and truned this into a feature request.
Then please set DISPLAY ;-)
Do you have a chance to try with a more recent pinentry; ie. 1.10 ? This may give better diagnostics.
Another thing I would suggest is to debug the invocation of pinentry: Put
Thanks for the description and the patch. I know what fuzzing is and GnuPG underwent quite some public and non-public fuzzing already. You may want to check with Hanno Böck to see how fuzzing can be done with gpg.
Sorry myself.
I will try to be clearer :
Ok, thanks for the reply
Thank you :)
Thanks. I only now noticed that this is the same as we already use for 32 bit MIPS. I have no more questions. Will push to master and the 1.8 branch.
That is all intended. You can always create broken messages which don't result in _one_ clear error code.
Clang doesn't support the "h" inline asm constraint and the C version of umul_ppmm() works on MIPS64.
Sorry, I do not understand your request. Please describe what you want; linking to some arbitrary external sites is not sufficient.
Your patch indicates that all clang versions for MIPS64 support this feature. Is my reading correct?