We do have an Italian translation but it is quite outdated:

Hello Werner,

@werner can you confirm if the environment I provided will work with OpenSSH support fully implemented?

I am sorry, but I do not understand your request. Please give real commands as examples.
You known that you can always use --output FILENAME to force a certain file name?

I also don't want to leave my card in the reader authenticated for a full day, it just doesn't sound like a good practice to me. I also very often just forget about the card, so it just sits there, keys open for use.

Using a not yet existing directory is a security feature. The directory is created at a time the signature has not yet been verified and thus it would be too easy to trick a user into overwriting important data.

--locate-external-keys exists since 2.2.17 and ignores the local keys.

I will consider a -p option for gpgtar.

So, if there's no support for native OpenSSH yet, I'll wait for it. After it's supported, I should be able to get the scenery I described working, right?

Unfortunately you can't pass extra arguments.

@bvieira You need to set pinentry-mode=loopback for gpg program used in git.

Thanks for your reply, but it is an OPTIONAL feature. The annoying part is not deleting the files. Comparing hundreds of time stamps to ensure you are current on what you want encrypted vs. unencrypted files that are either under development and/or complete, and therefore ready for encryption. This frequently needed comparison takes a significant amount of time, and is prone to error. Any responsible user will ensure there are tested file backups to prevent catastrophic losses, or they can simply NOT use the option.

I'm actually trying to do the following:

In the meantime you can use [0]. I have tested with ssh key on yubikey and AuthenticationMethods publickey, win32-ssh (or ssh-portable, which is the new repository name) correctly works with gpg and pinentry is called. Despite it being called wsl, wsl environment is not required.

See also: T3506

I have removed that feature intentionally. There were some issues where encryption errors were not properly reported to Kleopatra and handled by Kleopatra. This could result in catastrophic data loss. I have fixed ~3 issues regarding to that and then decided that in our architecture we cannot absolutely guarantee that this never can happen and cannot happen in the future. We have resolved all the issues, but they could occur again.

In T3362#137094, @werner wrote:

There is not a lot of demand for this, thus we have not continued to think about it.

@gniibe: We could implement this on the card by extending our ugly hacks on the login-data DO, which are currently:

Everything up to a LF is considered a mailbox or account name.  If
the first LF is followed by DC4 (0x14) control sequence are
expected up to the next LF.  Control sequences are separated by FS
(0x18) and consist of key=value pairs.  There are two keys defined:

 F=<flags>

 Where FLAGS is a plain hexadecimal number representing flag values.
 The lsb is here the rightmost bit.  Defined flags bits are:

   Bit 0 = CHV1 and CHV2 are not synchronized
   Bit 1 = CHV2 has been set to the default PIN of "123456"
           (this implies that bit 0 is also set).

 P=<pinpad-request>

 Where PINPAD_REQUEST is in the format of: <n> or <n>,<m>.
 N for user PIN, M for admin PIN.  If M is missing it means M=N.
 0 means to force not to use pinpad.

A new 'C' flag maybe?

There is not a lot of demand for this, thus we have not continued to think about it.

In T3362#103156, @gniibe wrote:

@werner , I understand your poiont.

So, the best approach would be:
(1) Define some DO (Data-Object) or attribute/flag per key to control timeout or "force" by the card itself.
(2) Modify scdaemon so that it always ask authentication state to the card before doing crypto operation.
(3) Modify gpg frontend so that it shows those attribute/flag and setup.

Then, it is the card itself to control timeout or "force".

0.2.0 was just released with support for GCM. Tested against openpgpkeys.pm.me

I implemented subkey collapsing in 2.3. It is enabled by default but you can disable it it with

if a user decided to use the Web Key Directory, this should be used instead of falling back to whatever has been configured (nothing else by default)

On the ml there was another request for this use case

Unicode file names will now also work - see T4083 and T5030

Unfortunately we can't help you here as this is not a GnuPG problem or one of software we maintain.

Excellent! thanks for having considered this.

The options now work as documented. More tests on Window are required and eventually we need to handle non-ascii characters in file names.

Hello,
just reading the issue in detail.

Thanks. Added to 2.2.

For the reference of full mod_sqrt, see https://eli.thegreenplace.net/2009/03/07/computing-modular-square-roots-in-python/

Patch backported to 2.2

Any news on this?

C++ interface is also availabale in 1.14.0 (see rM690d967196d9).

As of today we don't want to maintain another binding; see T3395

The Python bindings are troublesome enough; as of today we don't want to maintain a Perl module.

C part done; C++ interface is not yet done.

• compressed representation of EC point can be used in:
  • public key
  • (exporting) private key
  • signature
  • ECDH ephemeral key
• Accepting compressed representation,for the initial implementation, I'd like to limit our effort for curves of NIST and Brainpool, except NIST P-224, which p = 3 mod 4.

Creating is not that useful - we prefer modern curves anyway.

I think that retrieving a parameter in compressed format is all what we need as per API.

(3) _gcry_ecc_os2ec in libgcrypt/cipher/ecc-misc.c should be modified to support parsing compressed representation.

What kind of API should we offer?
(1) offering something like q@comp name for gcry_mpi_ec_get_mpi
But...
If the intended use case will be in create_request function in gpg/sm/certreqgen.c, the 'q' is already generated in the form of SEXP.
It is up to an application (gpgsm), to convert non-compressed point representation to compressed point representation, here.

It's in master (to be gnupg 2.3).
Enjoy.

The qualitybar has now been removed from 2.2 and master.

We will need this for 1.9

Yes, its on my agenda.

Since this issue is what I came across when googling for gpg inspect revocation certificate, I thought I’d add what I found out:

I'd be interested, is this is still on the agenda?

Your welcome.

I regret to have distracted your attention. All the above applies to a terminal window (KDE's konsole) in my GUI KDE. On the bare FreeBSD console, everything is fine. So this is a bug in some KDE library or konsole. I'm sorry I did not have the idea to test that on the bare console right away. I'll close this bug here.

Hello Mr. Niibe,

It seems that nl_langinfo(CODESET) returns US-ASCII on your system.

My FreeBSD box is currently not up, so I can't test right now. You may want to look into gnupg/common/utf8conv.c and there set_native_charset(). For historical reasons we start off with latin-1 but then swicth to the selected charset and intialize iconv accordingly. In the case of an error we sometimes fallback to utf-8. You may want to add some debug code (log_debug ("foo bar string=%s\n", some_string);)

in your test, which you did on Linux I guess, utf-8 is written downcase, whereas on my system, it is written uppercase 'UTF-8, conforming to what I find elsewhere (e.g. Wikipedia and RFC 3629). I do not know though, if there is a recommended way to spell it. So the bug might be: gpg does not compare the RFC spelling uppercase, but the linuxism: utf-8 witten downcase. Then the correct fix would be to compare uppercase UTF-8 only, and let Linux fix their system to use the correct uppercase throughout the system... ;)
2nd, I know that FreeBSD has some issues with internationalization: it does not support charsets in their POSIX meaning, but emulates them by combining all available locales and (matching) CODESETs. Usually, this is not a problem, and most translations and handling of UTF-8 works as expected. Maybe this has some subtle effect causing this issue.

Hello Werner,

OpenPGP specifies the use of UTF-8 for all meta data (ie. everything except for the signed/encrypted data). GnuPG has always supported this. I don't known on which OS you are but some don't have UTF-8 support on the command line or tty so you need to tweak your environment first.