Fixed in 977fc5f0e.

I just tried on an up to date fedora 26 system, and could not reproduce this.

Werner indicated that the current behaviour is intentional.

Maybe ask on a mailing list for help to find out why your environment is broken.

I tried on a fresh installation of Ubuntu 14.04.5 and could not reproduce the problem. Apparentlcy your test suite tries to link against an installed version of the library, which is very odd.

Fixed in 3aba49f.

After reviewing the content on the wiki, I don't think anymore that migrating the wiki as a whole is a good strategy, so I will close this simplicistic task. Discussing on the mailing list is of course appropriate.

Was reverted.

Done in a7bd2cbd.

No worries :)

Can you provide a patch for our version of the libtool macros that only adds support for illumos?

I only removed the documentation in the STABLE-BRANCH-1-4. Nobody said we want to remove this feature, and it is still documented in STABLE-BRANCH-2-0 and master.

I only removed the documentation in the STABLE-BRANCH-1-4. Nobody said we want to remove this feature, and it is still documented in STABLE-BRANCH-2-0 and master.

I just removed the paragraph (gpgtwoone is not used anymore anyways). Fixed in eb15d5ed8.

Good enough for now.

@wltjr Great :)

@wltjr Thanks for your comments. I think you mistyped the second bug number, T2013 seems unrelated to what you say.

libgpg-error is a placeholder project for the master version of our libtool, but all other packages are likely to be affected as well.

I think you should take this up with the support of your in-house web service, and if the developers of it find a bug, they can report it here.

This looks suspiciously like T1547: gnupg >= 2.0.21 won't build on OSX 10.8.5 with XCode5.

No response.

No response.

Well, at least this works without changing the environment:

dcfb01959802 looks much better, thanks for the review. All tests passed.

Reverted.

I created a new task for that T3322. The verein doesn't have any ownership over the logo so this is still your decision as head of g10 code.

I think that's fixed now.

Fixed in ebc65ff45 by always saving to standard path.

Done in a8d0b8d23.

The maximum passphrase length is defined in agent.h:

To remain compatible with PGP6 we are limited to ustar. If you want to support other archive types, archive first and then encrypt/sign the archive.

Also a lot of redirects, for example this bounces you from https to http.

Could be done by adding "--yes" to the command line. Requires a new version of the gpgme_op_delete functions with a flag "force".

Normally this error message can only come from gpgsm or dirmngr in case a certificate is listed that does have unsupported (unknown) critical extensions. Are you using X.509? What certificates do you have imported? You should be able to see the error and more information on the command line with "gpgsm -kv" and maybe some more options...

As others have pointed out, we don't implement the Bell-Lapadula model.

Fixed in 94eea0ed2c8b47cb0fe02b22cbe668705a5fe0d0

gpg 1.4 only gets important updates.

This is solved easily by using "--yes", which sets the force flag on the DELETE_KEY operation. This prevents gpg-agent from doing a confirmation.

Here is what Vinay Sajip wrote:

Thanks, fixed in 01c68a6a.

According to the link above, the reason we need entropy on import is the KEYWRAP between gpg and gpg-agent. The reason we are stalling is that we use getrandom() and the urandom pool is apparently not initialized on that system.

The beta is not released, but maybe Andre can make use of that info.