First of all I find PIN a very bad term. "Personal Identification Number" for example for my Gnuk token is confusing. I use a string there,... So let us use PIN only where it really has to be a number. Otherwise it is a Password.

Okay, I see the problem. The microsoft toolchain is more picky about de-facto standard use patterns with common blocks and the author of that code was not ware of this. Thanks for reporting, will be fixed in the next release.

Despite that I created this task, I am still not not convinced that removing the term passphrase is a good idea. If we do this in gnupg we would need to change all strings to make it clear that the passphrase is used to protect one's own key and has nothing to do with encryption etc. In fact the term PIN would be better because it is common knowledge that you use a PIN to get access to something you own. There would be less confusion on the purpose of the passphrase. Sure PIN is usually considered to be a number. However my bank allows a string to be used as, what they call, PIN.

There has been some progress here. At least we no longer use "passphrase" in new code. We still have not yet replaced all old occurances.

This is not about a function, but about the variable _gpgrt_functions_w32_pollable. And this is not about exporting the variable from the library, but about declaring it as extern in gpgrt-int.h, so that gpgrt-int.h can be included in multiple translation units without defining the variable in each.

This function is not exported on purposes. Even the name of the header file indicates that tis is internal. External, that is public functions of the API, are defined gpgrt.h and only made externally visible by including them in the .def file. This has not been done and so I don't understand your bug report.

Hi Werner and thanks for looking into this.

According to sks-keyservers.net both servers you mention run the very same software. Thus I would like to understand why you think they require the use of a legacy option.

Fixed. Thanks.

Good idea.

No... In this situation, my atachment is a rar file

I've already sent jens a mail this morning.

Interesting. Thanks for reporting this. This happened in the past because images had a "content-id" (so they were marked to be an embedded image) but were not really embedded. I did not have a very good fix then because it is hard for us to detect (easy for Outlook itself though) so there might be more special cases where this happens.

for user ID selection, you could also potentially match on substring, so uid dkg could select/deselect all user IDs that contain "dkg".

fwiw. Your patch is beautiful in which it follows our coding style and debug output. I'm confident that we will accept it but currently I have to read up on Job's a bit.

That is a very interesting problem that we did not have on our radar.

During a meeting with Werner today agreed:

• All content under gnupg.org should be handled by Verein
• Metazoa should write an offer regarding gnupg.org

(- Markus Meier is working for gnupg._com_!)
Contact to Metazoa already running. Will update Ingo Bläser.

When bogus entry is "", the error is GPG_ERR_NO_PASSPHRASE, and user cannot input the passphrase.

Confirmed that manually created entry in gnome-keyring-daemon causes trouble.

I would have thought this is a logical usage for gpg cards - seems this is harder to achieve as I thought.

The quality bar is switched off by default. That feature including the quality was ordered and accepted by a client. I don't like it either and thus the new default of having it disabled is a useful solution.

But to resolve this bug I also want to remove stuff like "ooooh you should use numbers or something like that" we have that in configuration but our default code is too dumb to be useful (afaik "password" is accepted with 90% quality). We also have a bug for the quality thingy, which I also find important because that is the first contact with our software.

Found it: T3724

No that bug is different. Nowadays you have to solve four dialogs to create a key without a passphrase.

So you mean the bug that you see a second set of passphrase dialogs iff you told the first one that you don't want a passphrase? That is not trivial to fix because we use the passphrase cache to avoid the double passpharse questions. Without passphrase cache we need a separate code path.

No! That is not what I want with this issue. We should ask once for a passphrase and then shut up.