Page MenuHome GnuPG

keyboxd: Searching <email@Example.COM>
Testing, NormalPublic

Description

From #gnupg channel on 2025-03-18, I read about this.

To replicate, here is the scenario:

$ export GNUPGHOME=/tmp/gnupg-testing
$ mkdir -m 0700 $GNUPGHOME
$ echo use-keyboxd >$GNUPGHOME/common.conf
$ gpg --recv-keys  0xD9F31F5F75F9B14D
$ gpg -k '<jrm@FreeBSD.org>'  # Note that we use <..> style address here and it includes uppercase letters.
gpg: error reading key: No public key           # key should be available, but failure
$ gpg-connect-agent --hex --keyboxd "SEARCH --openpgp -- <jrm@FreeBSD.org>" /bye
ERR 134217755 Not found <Keybox>

Revisions and Commits

Event Timeline

IIUC, the address is stored with lowercase, but searching is done not converting lowercase.

https://dev.gnupg.org/source/gnupg/browse/master/kbx/backend-sqlite.c$962

gniibe triaged this task as Normal priority.
gniibe added a project: gnupg.

Here is a possible change:

diff --git a/kbx/kbxserver.c b/kbx/kbxserver.c
index fc79209eb..a90deb350 100644
--- a/kbx/kbxserver.c
+++ b/kbx/kbxserver.c
@@ -370,6 +370,8 @@ cmd_search (assuan_context_t ctx, char *line)
       err = classify_user_id (line, &ctrl->server_local->search_desc, 1);
       if (err)
         goto leave;
+      if (ctrl->server_local->search_desc.mode == KEYDB_SEARCH_MODE_MAIL)
+        ascii_strlwr ((char *)ctrl->server_local->search_desc.u.name);
     }
 
   if (opt_more || ctrl->server_local->search_expecting_more)

The issue I identified is for SQLite backend (which stores addrspec converted to lowercase), but it's common issue among backends.

I changed my mind. SQLite specific patch might be better:

diff --git a/kbx/backend-sqlite.c b/kbx/backend-sqlite.c
index 4c67c3ef7..1db2f2c8d 100644
--- a/kbx/backend-sqlite.c
+++ b/kbx/backend-sqlite.c
@@ -154,7 +154,7 @@ static struct
      /* The full user id - for X.509 the Subject or altSubject.  */
      "uid  TEXT NOT NULL,"
      /* The mail address if available or NULL.  */
-     "addrspec TEXT,"
+     "addrspec TEXT COLLATE NOCASE,"
      /* The type of the public key: 1 = openpgp, 2 = X.509.  */
      "type  INTEGER NOT NULL,"
      /* The order number of the user id within the keyblock or

But this is not good for existing public key db.

You mean this would be better becuase it is not clear how we handle X.509 addrsppec (see override_mbox arg of store_into_userid)? I guess COLLATE NOCASE does it the standard way by folding all uppercase characters and not just the ASCII characters as we do in GnuPG. This would be a problem.

OK. Relying on SQLite semantics for COLLATE NOCASE would not be good.
Exactly same existing semantics (only care about ASCII uppercase characters) is good.

gniibe changed the task status from Open to Testing.Wed, Mar 26, 8:20 AM