with the next GnuPG version (2.2.28 and 2.3.0) you can do a read

This feature does not use Outlook per se.. It's a problem with Exchange really. An Exchange Add-in would be needed to solve it, an Outlook add-in such as Gpgol can't do anything about it..

Seems that it is not a coincidence that Wayland starts with a W like Windows. ;-)

IIUC... Could you please try this patch?

diff --git a/random/rndlinux.c b/random/rndlinux.c
index a7a78906..c20c5d4c 100644
--- a/random/rndlinux.c
+++ b/random/rndlinux.c
@@ -35,10 +35,13 @@
 #if defined(__APPLE__) && defined(__MACH__)
 #include <Availability.h>
 #ifdef __MAC_10_11
+#include <TargetConditionals.h>
+#if !defined(TARGET_OS_IPHONE) || TARGET_OS_IPHONE == 0
 extern int getentropy (void *buf, size_t buflen) __attribute__ ((weak_import));
 #define HAVE_GETENTROPY
 #endif
 #endif
+#endif
 #if defined(__linux__) || !defined(HAVE_GETENTROPY)
 #ifdef HAVE_SYSCALL
 # include <sys/syscall.h>

Fixed in 1.42.

Looks good to me: "make && make check" passes.

Our tentative plan is:

This is a bit more complex for us. I have often noticed the pattern of Windows users that if something does not work as expected they click "Run as Administrator". When they do that once with our software our backend software gnupg is also started with elevated privileges, it might create lock files with elevated permissions it might create data files. For example a user then generates a new key, but already had some keys the public key will be placed in the existing keyring and the permissions will not be changed. But the new key files created will be created with elevated privileges. Then the user runs Kleopatra again as normal user and reports bugs because he cannot access his newly created key files.

Good catch, we need to update at several places.

FWIW, in GnuPG we use

It seems you still don’t get what was wrong about this issue. There is no opposition to separation of roles (which is, however, a rather complex topic that involves determining a threat model and only then defining what is right or even mentoring what one must) — this is about unconcerned communication, the very way error message is written, implying that the rest steps are widely known, could be guessed or found on your own. For example, I have 20+ years of experience as a beta tester and didn’t get what was required from me to do to make Kleopatra work again, hence the outbreak. To have an example of good communication, try Veracrypt. Bottom line: software is meant to be a solution, not just pieces of code displaying windows and messing with files.

I was wrong in my last comment. Escaping by another \ is needed.

It should be fixed with 49ad2b0e05e3fcb8c8c2e23bb1c6063b390dee02, though I don’t have a gcc-10 to check. It does work with gcc-9.3 with -fno-common.

You are coming pretty late to the party ;-). Since 2.1.0 we don't use the ancient keyserver helpers anymore but reworked the entire network access. I even doubt that I can still test with a 2.0 version.

We have two or three other open issue which I would like to address before a release. FWIW, release ticket is T5305.

Do what ever you want with _gcry prefixed functions - this is never considered an API or ABI break. There are some exceptions for internal functions used by macros but those are clearly marked.

Good to hear that it works now.

A PATH with spaces is too Windowish (or macOS). IIRC, we had once checks that the used directories have proper names; we can expect this for build environment. Spaces in file names are horrible from a security POV it is just to easy to get things wrong (hello ssh).

I already backported the above for Fedora so I am not in hurry now. But I believe others might hit the same issue.

@werner Can you comment about bugfix release?

These functions are internal to library and, for example, on linux/windows builds are not externally available.

Admin here. I'm sorry your replies did not make it to this site but somewhere got stuck. So copying them for completeness:

In https://github.com/rust-random/getrandom/issues/38 they seem to have decided to use SecRandomCopyBytes on iOS, while in https://github.com/LuaJIT/LuaJIT/issues/668 they pushed https://github.com/LuaJIT/LuaJIT/commit/787736990ac3b7d5ceaba2697c7d0f58f77bb782 which I believe falls back to /dev/urandom. In both cases, they are only staring at iOS as an issue; though, it could be that using Rust at the same time as targeting an official macOS application are both rare enough to allow this to have gone two years without a rejection... making this weak_import hack not happen on iOS might be sufficient. If you do this, I recommend checking for TARGET_OS_IPHONE, not TARGET_OS_IOS, as (despite the somewhat hardware-specific sounding name) the former also encompasses tvOS and watchOS (which, if anything, will have stronger checks); I'd personally be satisfied with just some way of manually disabling getentropy by force, though (as I had been previously using ac_cv_func_getentropy=no).

So, I actually just filed an issue about this work: T5375, and then found this opposing task while following through on the various commits ;P... Apple actually forbids usage of getentropy in applications they publish to their App Store (citing ITMS-90338: Non-public API usage), and so there needs to be a way to disable this weak_import. FWIW, I'm not sure if this is only on iOS or on macOS as well (I haven't gotten around to trying to publish a macOS build with the new libgcrypt yet).

Very strange. Both logs show no error.

Sorry, first log was without API.
This log includes API calls.

Here we go. ;-)

Just drag and drop it into the input field. There is also a little cloud icon that makes this explicit.

Thanks for this very quick reply.

Sorry, but we are a security software. If you give any application that you run on your system root privileges then that is not a secure behavior. This kind of stuff has been deprecated with Windows Vista. Yes we changed the error to a warning as it was too zealous. I agree. It is not our place to educate users. But users should change your operating procedures. You should not handle protection worthy data on a system without privilege seperation.

@gniibe Note that you also need to at least add the semicolons, as BSD sed is trying to parse "gp}" as substitution flags (which, honestly, makes more forward-compatible sense than GNU sed's behavior...).

Mmh, all these issues should be fixed with the most recent versions.

Or, if we keep the code of newline (so that it will eventually support path with a space in future):

Thank you. Sorry for the use of GNU sed extension. It could be just a whitespace, if it's OK not to support path having a space.
sed -n -e "/^libraries/{s/libraries: =//;s/:/ /gp}") should work.

@gniibe OK, so... "worst case": I guess this worked? ;P

@gniibe Actually, I just realized that neither of the commands I provided work, as I failed to notice you were trying to also replace :'s with newlines (as I guess libraries from clang can return multiple paths). I'd momentarily edited my comment to just try to add back your colon replacement, before remembering you can't do that either: \n is a GNU sed extension. Hilariously, I'm always in contexts where I can assume I'm using bash (which isn't ok for configure), so I've never bothered to learn a technique that doesn't involve $'\n'... do you have a strategy for doing this replacement? :(