MantisBT - Issues

0011528: Various CSS / JS files shown not found in upgrade taler-merchant v1.5.16 (prod) to v1.6.5 (test)

Sat, 20 Jun 2026 20:15:31 +0200

At the very end of installation (as upgrade):

/var/lib/dpkg/info/taler-merchant.postinst: line 99: /usr/share/taler-merchant//spa/index.css: No such file or directory
/var/lib/dpkg/info/taler-merchant.postinst: line 100: /usr/share/taler-merchant//spa/index.css: No such file or directory
/var/lib/dpkg/info/taler-merchant.postinst: line 99: /usr/share/taler-merchant//spa/index.js: No such file or directory
/var/lib/dpkg/info/taler-merchant.postinst: line 100: /usr/share/taler-merchant//spa/index.js: No such file or directory
/var/lib/dpkg/info/taler-merchant.postinst: line 99: /usr/share/taler-merchant//spa/lang.js: No such file or directory
/var/lib/dpkg/info/taler-merchant.postinst: line 100: /usr/share/taler-merchant//spa/lang.js: No such file or directory

0011526: PQ-secure TCP/UDP encryption

Sat, 20 Jun 2026 12:26:37 +0200

We must update our crypto.
In order to stay true to the steganographic noise requirement (Elligator) we could use a KEM combiner that uses a PQKEM which has ciphertexts that are indistinguishabled from noise.
The choices are:

ML-KEM (the compressed ciphertext is still kind of distinguishable)
NTRU-HRSS
FrodoKEM

FrodoKEM ciphertexts are much larger (10-15x), but it is more common.
PQclear implements both.

0011520: need short wire transfer subject support for KYC AUTH

Fri, 19 Jun 2026 23:29:56 +0200

... also in the merchant backend.

0011523: webext should use preparePay...V2 requests

Fri, 19 Jun 2026 21:14:38 +0200

... instead of the old/deprecated version.

This allows better progress and error reporting.

0011478: Apps should automatically adopt amount from Template Link for xOTP / MDB devices [meta]

Fri, 19 Jun 2026 17:13:55 +0200

To support further work with xOTP/MDB devices, it would be beneficial if the mobile applications (iOS and Android) could directly take over and process the amount specified in the template link.

Example Link:
taler://pay-template/backend.demo.taler.net/instances/sandbox/xOTP_MDB?amount=KUDOS:0.1&nfc=1

Currently, this feature is not implemented in the backend/apps, meaning the 'amount' parameter is ignored and the default value from the backend is displayed instead.

Expected Behavior:
1. When a template link containing an amount parameter (e.g., ?amount=KUDOS:0.1) is opened, the app should automatically parse and pre-fill that amount for the transaction.
2. The pre-filled amount must be locked and NOT changeable by the user.
3. Immediately after reading the link and parsing the data, the app should skip any intermediate steps and open the confirmation screen directly.

0011529: Upgrade to taler-merchant v1.6.5 (test) might break prior installations: SQL migration to DB scheme v36 fails

Fri, 19 Jun 2026 14:46:12 +0200

Tested by upgrading from v1.5.16, cf. 0011518.

TL;DR:

taler-merchant-httpd@1b0bd36dc346:/usr/local/bin$ taler-merchant-dbinit 
2026-06-17T12:59:08.256681+0000 taler-merchant-dbinit-786 WARNING Could not run PSQL on file /usr/share/taler-merchant/sql/merchant-0036.sql: psql exit code was 3
2026-06-17T12:59:08.256743+0000 taler-merchant-dbinit-786 ERROR Failed to load SQL statements from `merchant-*'
2026-06-17T12:59:08.256774+0000 taler-merchant-dbinit-786 ERROR Failed to initialize tables
taler-merchant-httpd@1b0bd36dc346:/usr/local/bin$

0011498: Version 1.6

Fri, 19 Jun 2026 13:49:42 +0200

KYC procedure don,t work

0011532: Test check-health-status.sh created for taler.hacktivism.ch in stage

Thu, 18 Jun 2026 15:08:30 +0200

Useful for monitoring purposes, cf. use in transcript: https://bugs.gnunet.org/view.php?id=11518#c28927

0011535: Perfect forward secrecy in E2E group chat encryption

Thu, 18 Jun 2026 00:20:42 +0200

In current state the messenger service is using group exchanged epoch keys to encrypt messages during every epoch with a different key. Every time a user joins a messaging room or leaves it, a new epoch starts and the previous epoch ends. So new users can't access the encrypted older messages even if they get exchanged across all peers sharing the messaging room in the service since the keys to decrypt them are missing.

This provides a form of forward secrecy since users can't easily gain older epoch keys from newer ones. However there currently is still some attack vector based on authentication. Since older messages get exchanged asynchronously and might be delayed for some users, there is a wide time window for specific requests to epoch keys from all users being part of the given epoch.

So in case an attacker would gain access to their private identity key used for signing their request messages, they had the option to gain access to an older epoch key from other peers breaking encryption for all messages down the line in worst case. That is why these requests should be prevented.

0011163: Animation need to be improved for getting demo cash

Wed, 17 Jun 2026 22:39:34 +0200

See attached screen recording. I think we need to add background behind logo

0011518: Test taler-merchant v1.6.5 to be production-ready [-> taler-merchant v1.6.6 might be needed; reproduce furtherly]

Wed, 17 Jun 2026 20:21:31 +0200

Due to a new DB scheme (v38), the taler-merchant v1.6.x introduces new complexities. We need to rule out production systems run into issues by upgrade or in ops; by carefully testing core functionality and also observe mutations to the DB and check if there are errors or warnings by taler-merchant-httpd.

0010202: add lattice-based PQC blind signature support

Wed, 17 Jun 2026 17:40:07 +0200

For now, I think we should base it on:

https://github.com/Chair-for-Security-Engineering/lattice-anonymous-credentials

Just as a 3rd case next to RSA and CS.

0011527: GNUnet PQ migration meta issue

Wed, 17 Jun 2026 17:02:40 +0200

We probably want this.

We need to settle algorithm replacements including PQ-KEMs and combiners we want to implement along with suitable dependencies.
e.g. PQclear

0008892: Design Considerations for future *KEY types

Wed, 17 Jun 2026 17:02:12 +0200

The Design of GNS thus far could be improved to allow easier cryptographic analysis. Each consideration here is of minor severity, i.e. there is no immediate consequence of not implementing the proposed changes, to the best of my knowledge. Nevertheless, these (in some cases breaking) changes might be worth considering for a cleaner design.
I am currently working off RFC 9498 rather than the actual implementation, so I apologize should my analysis not reflect changes made in the meantime.

# Making Full Use of HKDF

To derive a bunch of random looking bits from a zone key (zkey below) and a label, one could take a hash function H and output

H(zkey || label || 0) || H(zkey || label || 1) || H(zkey || label || 2) || ...

where || denotes concatenation.
This is well justified if one is willing to model H as an ideal random function, whose output may only be correlated with its input only by plugging in values and observing what comes out. (This is routinely called a Random Oracle.)
However, algorithms are not random oracles, and in particular cannot always be trusted to generate arbitrarily many independent output bits from highly correlated inputs. For this very reason, modern key derivation functions like HKDF derive only a single key from a keying distribution using a dedicated component called a strong randomness extractor ("Extract") and then use this one key to derive independent looking key streams using another dedicated component called pseudorandom function ("Expand"). In HKDF, these are both implemented using HMAC, which is secure almost independent of where you plug in parameters, IF you are willing to model HMAC or the underlying hash function as a random oracle (which is why the current implementation is "probably" fine). A modular analysis of schemes however requires using HKDF using its extract and expand functionality in the sense above.

For this reason, it may be good practice to first derive blinding key material bkm as follows:

salt := "gns-extract-" || zone_type
bkm := HKDF-Extract(salt, zkey || label)

zkey is assumed to have fixed length, a length encoding or some sort of final delimiter.
The salt here is merely used as a domain separation tag. It includes the zone type so that the encoding of zkey may differ between zone types without having to worry about collisions.
The initial keying material (zkey || label) is chosen such that both the combination of a sufficiently unknown zkey with a predictable label (as required by GNS for unlinkability in a web-surfing-like scenario) as well as the combination of a known zkey with a sufficiently random label (as required for censorship resistance and privacy with re:claim) result in input keying material distributions of sufficient entropy for the extractor to do its job and extract a bkm indistinguishable from random.

bkm may then be used to derive arbitrary random data using HKDF-Expand. For example, to derive a symmetric key for (say) AES-GCM and a blinding factor for (say) EdDSA key blinding one could use

K := HKDF-Expand(bkm, "gns-encrypt-aes-gcm-key", 256/8)
h := HKDF-Expand(bkm, "gns-blind-eddsa", 512/8)

In terms of the RR data confidentiality, query privacy and censorship resistance, this should simplify the analysis a decent bit.

# Simplifying and Future-Proofing the Symmetric Encryption

Contrary to the terminology in RFC 9498, the actual nonce ("number used once") is not the NONCE derived using HKDF (which is always the same, since it is derived deterministically for each zkey-label pair), but rather the expiration time of the record. Encryption algorithms typically only provide any guarantees if this value is only used once.

There are two approaches to "guaranteeing" this. One could write a "MUST" into a specification detailing that expiration times shall be strictly increasing. This approach might however leave the not cryptographically inclined reader (or non-reader. How many people using DNS have read the specifications? :D) with the impression that violating this constraint heuristically to support distributed signing infrastructures, temporary setups and backup solutions might only lead to temporary interoperability problems, rather than a leak of confidential information. Even if all users and implementations were to understand this, it would complicate the above use cases and, as a result, make GNS less flexible.

Alternatively, one could take out the problem. That is, ideally generating a random (at least) 64-bit nonce each time and placing it next to the ciphertext. If one is worried about accidental nonce reuse, there are AEAD schemes like AES-GCM-SIV to handle this exact case. If one does not want to store ciphertexts locally and rather re-encrypt plaintexts on demand, one may either just store the nonce values alongside the expiration timestamp or derive them deterministically by applying an independently keyed pseudorandom function to the plaintext, expiration and blinded public key.

Speaking of AEAD schemes, with the internet moving away from giving users access to low-level cryptographic primitives, many libraries will primarily expose, review, and also optimize, AEAD schemes. It does little harm to use these for encryption, even though integrity is already protected by a digital signature. The AD may also be used to bind the ciphertext to a particular blinded key.

To illustrate the full RRBlock creation, assume a layout such as (bitlengths in brackets, "varies" depends on zone_type or data length):

size(32) || zone_type(32) || expiration(64) || blind_zone_key(varies) || nonce(64) || bdata(varies) || aead_tag(128) || signature(varies)

Here I have left size and zone_type unchanged for compatibility with existing *KEY types, expiration has moved slightly to the front to have fixed size key types in the header as much as possible. Doing so for the nonce would make AD-calculation and deterministic nonce-calculation more cumbersome.

Creation steps:
1. Fill in size, zone_type and expiration
2. Do the KDF extract step above
3. Use the KDF expand to derive randomness for blinding zkey, and fill in blind_zone_key
4. Fill in the nonce randomly, using a stored value, or by applying a PRF to the parts already filled in
5. Use the KDF expand to derive a symmetric encryption key
6. Fill in bdata and aead_tag by encrypting RDATA with everything from size to blind_zone_key as AD and the chosen nonce
7. Fill in a signature over everything before it

If you need every last bit of speed in creating the RRBlock, keep a hash of everything you have filled in so far. You can pass this hash to the nonce-PRF, use it as an effective AD and have it ready for the signature. I do not think that this makes much of a difference, but some to-be-defined *KEY types might make use of such optimizations.

0011533: Free taler-merchant-dbconfig from sudo

Wed, 17 Jun 2026 16:02:32 +0200

Given xBSD ports and even minimalistic Debian for podman (cf. output) which is without sudo, use su:

root@1b0bd36dc346:~# taler-merchant-dbconfig 
taler-merchant-dbinit v1.6.5
Setting up database user taler-merchant-httpd.
Database user 'taler-merchant-httpd' already existed. Continuing anyway.
/usr/bin/taler-merchant-dbconfig: line 91: sudo: command not found
Failed to grant permissions to taler-merchant-httpd
root@1b0bd36dc346:~# sudo
bash: sudo: command not found
root@1b0bd36dc346:~#

0010254: Wallet-core doesn't wake up correctly from background

Wed, 17 Jun 2026 15:37:26 +0200

When the user switches to another app, Taler Wallet is sent to the background (if the user doesn't kill it).
When later the user taps on a talerURI e.g. in Mail.app, Taler Wallet is brought to the foreground again with an "openURL" call. The wallet then passes the talerURI to wallet-core - which does nothing, so the app hangs, spinning the Taler Logo forever...

❗️.onChange() ==> Background)
❗️App Will Enter Foreground
[M] 19:40:45.303 � Controller.swift:325 Controller#1 openURL(_:stack:) taler://pay/backend.chf.taler.net/instances/snack/2025.228-00RDM1DH37PR4/?c=GKMBDTDJGDAH0G03FQZ2M4N6RC
�"id":34 preparePayForUri{"talerPayUri":"taler:\/\/pay\/backend.chf.taler.net\/instances\/snack\/2025.228-00RDM1DH37PR4\/?c=GKMBDTDJGDAH0G03FQZ2M4N6RC"}
❗️.onChange() ==> Active
❗️App Did Become Active

Wallet-core should now examine the talerURI and query the server (in this case backend.chf.taler.net) for the payment data, but it does NOT start a network call.

Workaround: Kill the app, tap on the talerURI in Mail again - this time wallet-core sends a notification (transaction-state-transition) and makes a network call:

❗️.onChange() ==> Background)
❗️App Will Enter Foreground
[M] 19:50:40.198 � Controller.swift:325 Controller#1 openURL(_:stack:) taler://pay/backend.chf.taler.net/instances/snack/2025.228-00RDM1DH37PR4/?c=GKMBDTDJGDAH0G03FQZ2M4N6RC
�"id":20 preparePayForUri{"talerPayUri":"taler:\/\/pay\/backend.chf.taler.net\/instances\/snack\/2025.228-00RDM1DH37PR4\/?c=GKMBDTDJGDAH0G03FQZ2M4N6RC"}
pay-merchant.ts created new proposal for 2025.228-00RDM1DH37PR4 at https://backend.chf.taler.net/instances/snack/ session
pay-merchant.ts waiting for txn:payment:1HVA74PRCSTCFRJKJETAVGHJMKVTJC3A3PR4F7XBP8ZV7PKGHHMG to be downloaded
[9] 19:50:40.237 � WalletCore.swift:323 WalletCore#1 handleNotification(_:_:) {"type":"notification","payload":{"type":"transaction-state-transition","oldTxState":{"major":"none"},"newTxState":{"major":"pending","minor":"claim-proposal"},"transactionId":"txn:payment:1HVA74PRCSTCFRJKJETAVGHJMKVTJC3A3PR4F7XBP8ZV7PKGHHMG"}}
Pending:claim-proposal txn:payment:1HVA74PRCSTCFRJKJETAVGHJMKVTJC3A3PR4F7XBP8ZV7PKGHHMG
❓27 POST https://backend.chf.taler.net/instances/snack/orders/2025.228-00RDM1DH37PR4/claim
❗️ 27 https://backend.chf.taler.net/instances/snack/orders/2025.228-00RDM1DH37PR4/claim

0011531: Publish taler.hacktivism.ch deployment (no systemd + podman-rootless)

Wed, 17 Jun 2026 15:21:50 +0200

Too many scripts are not versioned there, go for deployment git w/ this. Good for experimental setups.

0011530: Test taler-merchant v1.6.6 or higher to be production-ready

Wed, 17 Jun 2026 15:11:01 +0200

This after taler-merchant v1.6.5 shows having issues, cf. 0011518 and 0011529.

0011480: iOS wallet should support prepared transfers for withdrawals and KYC auth via transferOptions

Wed, 17 Jun 2026 15:08:40 +0200

The exchange now supports wire transfers (for withdrawals and KYC auth) that include a shorter subject instead of the full reserve public key.

This short subject may need to be included in specific fields (such as the QR Reference for Switzerland) of the payment.

Wallet-core now supports generating appropriate QR codes for the new transfer options. They are exposed in the transaction details via:
* withdrawalDetails.transferOptions for withdrawals
* kycAuthTransferOptions for KYC auth transfers

0011259: Use PQ-secure hybrid ratchet

Wed, 17 Jun 2026 11:44:15 +0200

https://signal.org/docs/specifications/doubleratchet/#combining-double-ratchets-for-hybrid-security

0011251: CADET encryption authentication smell

Wed, 17 Jun 2026 11:34:46 +0200

The header encyption HENCRYPT and the message encryption ENCRYPT according the spec should both be AEAD schemes

The CADET implementation takes a shortcut: It Encrypts the header and the plaintext separately with the respective keys using TWOFISH(AES(*)) and then appends a MAC using the HK that is calculated over both ciphertexts

Probably not breakable per se, but smells bad.

0011411: p2p receive for 1st time, reject ToS -> flow broken

Tue, 16 Jun 2026 22:16:44 +0200

If you p2p receive with an exchange where you did not accept the ToS and then do NOT accept the ToS but go *back*, the wallet is in a confused state and suggests you can now accept the payment, but that then fails with Tos not accepted.

0011506: write DD for 100% fee idea

Tue, 16 Jun 2026 19:11:01 +0200

There are a bunch of open questions:
* What will the currency be called?
* CHF/EUR but with some meta-data to distinguish it from "transferable" CHF/EUR
* Separate currency name
* How will the exchange signal the fees? I've heard different ideas floating around regarding this

0011484: Notify merchants of relevant changes to the instance (like IBAN no.) [QC]

Mon, 15 Jun 2026 23:32:39 +0200

Regardless of who did the changes, alterations of relevant information like the IBAN(s) used (where paid orders go to, by settlements) should be accompanied by notifications to the tan channels defined, like sms and email.

0011501: webext does not work with paivana

Mon, 15 Jun 2026 23:10:10 +0200

Going to https://paivana.grothoff.org/ and paying (with KUDOS) does not show the article, i.e. it does not go to the fulfillment URL.