@ebo: I just a did a test build: gnupg-vs-desktop-3.2.0-beta178-x86_64.AppImage in my directory

This has been well tested during development and is thus ready for a release.

That should be easy on Unix but on Windows we have the nul nul: and iirc also /dev/nul.

ack

We have a fix for now and thus I lower the priority. Given that EasyPG mimics the GPGME API we should here also use another pipe to convey the passphrase (e.g. for symmetric encryption).

I don't see a value to do this for 2.2 and introduce a regression with that.

@iklocker: Which gpg bug to you mean?

Seems to be solved in the current version (vsd 3.2.0-beta178).

It might actually be useful to have an random number API in gpgme. When we do that we can also add a way t search for random numbers with an upper limit in each octet.

Bugs goes back to 2002 where we stopped checking trust for keys without any signature. This was really useful but has this strange behaviour.

BTW, with one of the recent gpgme fixes we now get

$~/b/gpgme/tests/run-keylist  --extern --verbose foo
run-keylist: file /home/wk/s/gpgme/tests/run-keylist.c line 414: <Dirmngr> No keyserver available

which is what users (and kleopatra) expects.

Note that for vsd we also need to change our default configuration file. The new "none" value provides a better error message than the old default of assuming that the AD carries the keyserver (which it does not in practise).

Thank you.

Why do you need an integer - for real random this must be larger than 64 bits and then you have problems to to find a suitable type for a variable.

For reference this is the code used to fill the pubkey table:

static gpg_error_t
store_into_pubkey (enum kbxd_store_modes mode,
                   enum pubkey_types pktype, const unsigned char *ubid,
                   const void *blob, size_t bloblen)
{
  gpg_error_t err;
  const char *sqlstr;
  sqlite3_stmt *stmt = NULL;

You are right - issuing an SQL statement returns the rrror. Hwoever, the selfcheck from sqlitebrowser does not show any errors.

I guess we should follow the GNU standards and provide only info files ;-)

The copy of the database we received for this case is not damaged. A possible problem might be insufficient rights to read the database. For example created with an Admin account and then later used by a different user.

BTW. you should use gpg --quick-set-expire FINGERPRINT 5y this is easier for scripting. Using
--export-options no-export-clean should keep the old signatures.

gpg only uses the latest self-signatures and ignores old one. Thus I do not understand your problem.

Looks more like a support question but feel free to create a sample message, encrypt it to info at gnupg.com (WKD) and attach that message to this report.

This is a support requests. Please consult one of the mailing lists or the gpg4win forum. In case this turned out to actually be a bug, please feel free to reopen it.

I am not sure about the initial state of the key. What you are doing is to sign the key with itself (self-signature). Why?
In any case, I can't replicate this. Let's talk about this next week.

Not easy do decide whether something is a PIN or a PUK and we will need to check a lot of places. So, not now.

This adds a lot of complexity to a program which should be simple. I tend to say, just accept a small(?) race condition in cache flushing. The power issue of waking up every minute or so is a constructed one and does not result in a noticeable battery drain in real life.

Turning this into a feature request: We should create P12 files using AES instead of 3DES

If we ever add a way to take the password from a file we will for sure hide that in the log files. Ceterum autem censeo tesserae esse delendam.

Kleopatra is a 64 bit application, right? For GnuPG we are working on 64 bit support for Windows. This is planned for 2.6. problems are how to represent sockets, file descriptors, streams and so on. Regarding the time interface, we should have everything ready in the GPGME<->GnuPG interface. In GPGME we need to check that we don't use int instead of time_t, though. When that has been done/fixed we could use a 64 bit gpgme and kleopatra along with the 32 but gnupg. Might be easier for approval reasons.

It turned out that we need to fix this for use by Kleopatra on Windows.

That is intentional. If we are able to remove a file we do it. Solution for you is easy: gpg .... -o - </dev/null >/dev/null

Needs to be checked for 2.4 - no backport to 2.2, though.

Needs to be checked again with stable. No backport to 2..2, though.

Won't be backported to 2.2 once we got something in 2.4.