Here is my understanding:
--log-file option is valid for for background task like gpg-agent, dirmngr and scdaemon.
For gpg, it only works with --batch or --server.

Last week:

• T4744: Password is _never_ prompted in an X session but is in a bare tty
• T4654: Gemalto Ezio Shield (CT710): CCID command failed: Parameter error at offset 7: Backport to 2.2 too.
• Chopstx RISC-V port starts to run well (only for LED blinking, though).
• GnuPG: Create gniibe/sos branch for saving leading zero bytes

This week:

• Chopstx: release 1.18 before merging RISC-V change. Then, create STABLE-BRANCH-1-0. master will be 2.0, merging RISC-V branch.
• GnuPG: continue gniibe/sos branch
• bug fixes, when I see some bug reported to dev.gnupg.org

This will be in 2.2.18, closing.

In my own opinion, it will be good when desktop environments support GnuPG as one of first class citizens, to protect user's data.
For example, currently, libscret stores secret data (such as WiFi shared secret, etc.) by its own cipher preference and method (and it is symmetric cipher by user's password). I don't think it is secure enough.
For me, it will be good if it is protected by user's gpg key using asymmetric crypto.

Sorry in advance for long explanation. :-) Well, let me show my stand point at first (to avoid confusion): I don't like the concept of "desktop integration" when it makes difficult for a user to control his environment.

Could you try to put no-allow-external-cache in your gpg-agent.conf?
If it changes the behavior, it is your desktop environment which caches your input, I suppose.

I thought I close this after the release of 2.2.18.
Anway, it's done, so, closing.

Last week:

• gpgme: Make dist to generate Python doc (RST and TEXinfo) from ORG
• gpgme: qt test failure fix for GnuPG 2.3
• Learn RISC-V for MCU
  • Initial work for Chopstx
  • I realized that the development environment is not mature yet
    • dfu-util requires local patch for GD32VF
      • standard dfu-util (in Debian) is unstable (only stable for 1KB)
    • OpenOCD seems not to work yet

This week:

• Bug fixes for GnuPG
• Back to X448 for GnuPG
• If time remains, work for Chopstx for RISC-V

Last week:

• T4654
• Saving leading zeros for ECC
  • Problem originates OpenPGP specification
  • libgcrypt: fixes mostly done
  • gpg, gpg-agent: need to locate MPI assumption here and there
  • other implementations share same problem
• Learn RISC-V for embedded

This week:

• possible fixes of GnuPG to save-leading-zeros for ECC
• implement context switch for Blumbee core (RISC-V for embedded)
• have a look at GPGME

Sorry, it was simply my confusion (between GEMPC_PINPAD and GEMPC_EZIO).
Fixed now.

Last week:

• libgcrypt
  • Clean up existing code to be friendly for ECC_DIALECT_SAFECURVE
    • Use "/q" for public key and secret key, handle point representation as an opaque bytes
    • Use "/e" for ephemeral key, handle point representation as an opaque bytes
    • Use unsigned integer for cofacter (not MPI)
    • Use mpi_ec_t to remove ECC_public_key and ECC_secret_key
      • Once, it attempted to have an abstraction of mpi_ec_t only in libgcrypt/mpi (not publishing internal to libgcrypt/cipher), but now ec-context.h is used in libgcrypt/cipher. It didn't work as originally written in the past.
    • more clean up of ECC.
  • Introduce new practice with new dialect of ECC_DIALECT_SAFECURVE
    • Native to the Curve algorithm
      • fixed-size, little-endian for
        • Point representation
        • binary of secret
        • integer in "s" in signature (in future)
  • Define X448 using ECC_DIALECT_SAFECURVE
• GD32FV103
  • Got the board and write LED blinking using kp's gcc-riscv64-unknown-elf package in Debian.
  • It found that USB peripheral is different. At start, it runs from 0x00000000 need to jump to 0x08000000.
  • BOOT0/BOOT1 setup enables DFU mode at boot from USB: we can use dfu-util in Debian.

This week:

• OpenPGP
  • Examine the standard. What needed is introducing native bytes instead of MPI which has integer semantics
    • Say, I say "Simply, Opaque String" (SOP) for now, to be replaced by more relevant term.
    • Just like MPI which has two-octet scalar for its bit-size and octet string, but no assumption it's big-endian.
    • Bit-size is normally 8*(sizeof octet string), but it is also OK (for backward compatibility) bit-size%8 != 0 (0x40 prefix for EdDSA/Curve25519 point representation).
    • For point representation, secret, and integer in signature
• GnuPG
  • Investigate how to introduce handling of SOP

Last week:

• Struggled for T4713: Bug in get_best_pubkey_byname
  • Original problem of mine (newer key is not selected because the first one is not in the list of candidates) has been solved.
  • Should -r someone -e and --locate-keys someone match?
• libgcrypt ECC code clean up

Or... it could be a feature, not bug, so that failure of -e -r someone can be examined by --locate-keys someone.

Let me clarify the point.

I think that we should apply further change:

diff --git a/g10/getkey.c b/g10/getkey.c
index 077209415..1c337149c 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1369,7 +1369,7 @@ get_best_pubkey_byname (ctrl_t ctrl, enum get_pubkey_modes mode,
     *retctx = NULL;

I found more wrong cases of get_best_pubkey_byname.
For ranking results,
(1) It may return non-encryption primary key as the most relevant key, when its validity is higher.
(2) It may not select encryption primary key even if its creation time is newer.

In my opinion, --locate-key should locate encryption key.

@pow, thanks for a reference. But problem here is that there are multiple products with same name.

Last week:

• Problem of OpenPGP format definition
  • ECC object defined as "MPI"
    • it can be interpreted as "MPI" (big-endian), but actually not (composed by prefix, fixed-length big-endian x 2)
    • or it's not big-endian for EdDSA
• libgcrypt ECC (and GnuPG):
  • Binary object in SEXP handling
    • FIXED: public part should be handled by "/q" (or "/e") because it's actually not defined as big-endian

This week:

• GnuPG
  • Backport rG7535f1d47a35: gpg: The first key should be in candidates. to 2.2.
  • "/q" things
• libgcrypt
  • X448
• OpenPGP format
  • ECC clarification and X448