From c1f87fbeecc175eb9a5d94b8c677b62e1672e3b9 Mon Sep 17 00:00:00 2001
From: Vidhi Jain <vidhi.jain@intertek.com>
Date: Tue, 11 Aug 2026 16:56:36 +0530
Subject: [PATCH] Fix swapped bind values when updating a stored tls-auth key

importTaKey() shares one pair of bindValue() calls between its INSERT
and its UPDATE, but the two take their parameters in opposite order:
the INSERT is (item, value) while the UPDATE is
"SET value = ? WHERE item = ?".

Replacing an existing tls-auth key therefore wrote the item id into the
value column and looked the row up by matching the integer item column
against the base64 key data. No row matches on SQLite, and PostgreSQL
rejects the comparison outright, so the stored key was never replaced
and the user was told the import had failed.

Bind each branch separately.
---
 lib/pki_x509.cpp | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/lib/pki_x509.cpp b/lib/pki_x509.cpp
index 35baedfb..65863746 100644
--- a/lib/pki_x509.cpp
+++ b/lib/pki_x509.cpp
@@ -348,12 +348,19 @@ bool pki_x509::importTaKey(const QByteArray &takey)
 				<< QString::fromLatin1(existing_takey.toHex()).left(6);
 	}
 	if (existing_takey != data) {
-		if (existed)
+		/* The two statements take their parameters in opposite order,
+		 * so each branch binds its own. Sharing one pair of
+		 * bindValue() calls put the item id into the key column and
+		 * searched for the row by the key data. */
+		if (existed) {
 			SQL_PREPARE(q, "UPDATE takeys SET value = ? WHERE item = ?");
-		else
+			q.bindValue(0, data.toBase64());
+			q.bindValue(1, sqlItemId);
+		} else {
 			SQL_PREPARE(q, "INSERT INTO takeys (item, value) VALUES ( ?, ? )");
-		q.bindValue(0, sqlItemId);
-		q.bindValue(1, data.toBase64());
+			q.bindValue(0, sqlItemId);
+			q.bindValue(1, data.toBase64());
+		}
 		q.exec();
 	}
 	TransCommit();