MantisBT - Issues

0011481: WebExtension wallet should support prepared transfers for withdrawals and KYC auth via transferOptions

Thu, 11 Jun 2026 21:44:57 +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

0011476: taler-pkg should generate debian changelog and support dev versions

Thu, 11 Jun 2026 21:40:20 +0200

We want to address two issues with this:
* Right now every component needs to bump their debian changelog whenever there's a release or even dev release. That's tedious and not helpful.
* Even for testing minor changes in our staging environment, we need to do a full patch tag, which doesn't lend itself well to testing experimental changes

The taler-pkg tooling should support `.dev-$n` versions and also just generate the changelog file.

0011513: Check DB restore w/ backup from merchant v1.6.2; then upgrade to merchant v1.6.4

Thu, 11 Jun 2026 21:09:44 +0200

An issue introduced in taler-merchant v1.6.3 rel to Garbage Collection, was tested to make instances inaccessible: should be fixed in taler-merchant v1.6.4; testing herewith.

0011511: Test global KYC Auth Reset for an installation's instances and in taler-merchant v1.6.4

Thu, 11 Jun 2026 21:01:59 +0200

Test extension to ticket 0011446.

Text was:

Just to be sure, as stage is now running taler-merchant v1.6.3 and has garbage collection of the psql DB ("taler-merchant") fixed; should not cause problems, but better test.

Indeed, issues arised, so to be done first:

Test GC to work properly in v1.6.4; cf. 0011513.

Then (to the core of this ticket):

It was not yet tested to delete the *.kyc_merchant data of all instances at once and then request an update form the exchange on this.

0011446: Test KYC Auth reset via SQL [installation-wide KYC Auth Reset in separate ticket]

Thu, 11 Jun 2026 18:36:37 +0200

Directly related to 0011428, trying on TOPS/Stage if this works, i.e., doesn't create additional issues or even ends up w/ dysfunctional instances.

Three types of merchants shall be considered:

* kycauth_1_pending: merchant which entered an IBAN, but did not yet pay
* kycauth_2_kyc_ok: as above, but transfer fulfilled; exchange acceptance gotten
* kycauth_3_kyc_ok_and_withdraw: dito as w/ kycauth_2*, but additionally the merchant also acts as wallet user and withdrew money from the exchange he verified against as merchant, and doing so to the *very same IBAN* which was used as merchant (for IBAN settlements from paid orders)

0011432: Margins of taler-ops.ch (also after newest proposals: stage.taler-ops.ch) suboptimal for mobile devices

Thu, 11 Jun 2026 18:31:03 +0200

We saw this in friday's MKT meeting, @cm_7 could reproduce with his newer iPhone (me with an older XR, too), but also on a newer Samsungn Galaxy device, the website didn't look good; text too close to the margins (left and right) or already cut.

0011472: In DE (at least): Confusing text at phone no. field when creating instance

Thu, 11 Jun 2026 18:30:40 +0200

The text is confusing, because this number is supposed to be a mobile phone number and not just any generic number.

0011512: bank account selection on manual withdrawal is wrong

Thu, 11 Jun 2026 16:45:35 +0200

try this operation taler://withdraw-exchange/exchange.stage.taler-ops.ch

right now stage exchange is configured with 2 accoutns

"accounts": [
{
"payto_uri": "payto://iban/CH1130000001166556117?receiver-name=Taler+Operations+AG&receiver-postal-code=2502&receiver-town=Biel-Bienne",
"prepared_transfer_url": "https://nexus.stage.taler-ops.ch/taler-prepared-transfer/",
"priority": 0,
"debit_restrictions": [
{
"type": "regex",
"human_hint": "Swiss bank accounts only",
"payto_regex": "payto://iban/CH.*",
"human_hint_i18n": {}
}
],
"credit_restrictions": [
{
"type": "regex",
"human_hint": "Swiss bank accounts only",
"payto_regex": "payto://iban/CH.*",
"human_hint_i18n": {}
}
],
"master_sig": "WEYWEHWHFGXREB95KWHFNFT94XWPGEQC85M2N3TAPS38W0ZGD0QJ0C844KDKZJ6AYV0W28Y8VMJ40MT3V815320CSJVJB0KY3E6CA3G"
},
{
"payto_uri": "payto://iban/CH6808573105529100001?receiver-name=Taler+Operations+AG&receiver-postal-code=2502&receiver-town=Biel-Bienne",
"priority": 0,
"debit_restrictions": [
{
"type": "regex",
"human_hint": "Swiss bank accounts only",
"payto_regex": "payto://iban/CH.*",
"human_hint_i18n": {}
}
],
"credit_restrictions": [
{
"type": "regex",
"human_hint": "Swiss bank accounts only",
"payto_regex": "payto://iban/CH.*",
"human_hint_i18n": {}
}
],
"master_sig": "J2VC1YXHR34F5DNYE0RYX4K04PGF6K7BYQZ5RQ5SSTY2NESX11K2F8EMVJTWR84WNHQ0N11E9RTVHJKJFEH5CGWXVXEX8HP7VZHD63R"
}
],

but it should not show bank accounts here and just show that information in the next step when the user receives instructions on how to make a wire transfer.

0010531: Order & Templates v1 SPA (for testing or expert mode)

Thu, 11 Jun 2026 03:20:48 +0200

Here is a design idea for integrating token families into order creation.
Also we need to rename "Taler payment options" to "Taler payment settings".

For Templates I propose to locate "Payment options" under "Supported currencies" field.

0011506: write DD for 100% fee idea

Thu, 11 Jun 2026 01:44:07 +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

0011456: DB reconnect logic needs rework

Thu, 11 Jun 2026 00:54:41 +0200

When the database is restarted (or we otherwise loose the connection), our current
reconnect handling logic is not adequate. This needs a fix all the way down in libgnunetpq
and then all the way up in all components, as we clearly should have some notification logic.
We might also want to consider moving the general PREPARE macro helpers into libgnunetpq
to de-duplicate the code.
merchant may need some additional special handling to recover the now dynamic search_path.

0011501: webext does not work with paivana

Wed, 10 Jun 2026 22:40:59 +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.

0011498: Version 1.6

Wed, 10 Jun 2026 22:33:52 +0200

KYC procedure don,t work

0011499: PB in parametr

Wed, 10 Jun 2026 22:21:41 +0200

The version specified in the parameter is no longer available

0011508: add support for delete bank account MFA

Wed, 10 Jun 2026 18:43:02 +0200

self provisioned instance can delete bank accoutns

0011507: Design UI for 100% fee idea

Wed, 10 Jun 2026 18:36:50 +0200

Based on info from DD??

0011492: psql: taler-merchant-httpd user and taler-merchant DB tried to be recreated while upgrading

Wed, 10 Jun 2026 18:10:56 +0200

Just seen on betel, not sure if this is intentional; never seen for any other taler-merchant upgrade:

taler-merchant-dbinit v1.6.2
Setting up database user taler-merchant-httpd.
Database user 'taler-merchant-httpd' already existed. Continuing anyway.
GRANT
Database 'taler-merchant' already exists, continuing anyway.
Initializing database taler-merchant.
Database configuration finished.

0011213: In email auth code user "admin" is (always?) shown as login name

Wed, 10 Jun 2026 18:09:51 +0200

I see this the first time (introduced in taler-merchant v1.5.0?):

1.
Not sure if the login line in the email should even be showed, but in any case it's not admin; I used "mechant1_5_0" as username.

2.
Confusion login vs. username should also be avoided; if this line should stay, then I'd suggest to say username.

0011500: merchant GC fails with SQL error

Wed, 10 Jun 2026 17:09:26 +0200

$ sudo -u taler-merchant-httpd taler-merchant-dbinit --gc

2026-06-10T14:13:13.591097+0000 pq-66923 ERROR Query `run_gc' failed with result: column "merchant_serial" does not exist/(null)/ERROR: column "merchant_serial" does not exist
LINE 1: SELECT DISTINCT merchant_serial
^
QUERY: SELECT DISTINCT merchant_serial
FROM merchant_statistic_counter_event
CONTEXT: PL/pgSQL function merchant_statistic_amount_gc() line 20 at FOR over SELECT rows
SQL statement "CALL merchant_statistic_amount_gc ()"
PL/pgSQL function merchant_do_gc(bigint) line 14 at CALL
/PGRES_FATAL_ERROR/ERROR: column "merchant_serial" does not exist
LINE 1: SELECT DISTINCT merchant_serial
^
QUERY: SELECT DISTINCT merchant_serial
FROM merchant_statistic_counter_event
CONTEXT: PL/pgSQL function merchant_statistic_amount_gc() line 20 at FOR over SELECT rows
SQL statement "CALL merchant_statistic_amount_gc ()"
PL/pgSQL function merchant_do_gc(bigint) line 14 at CALL

2026-06-10T14:13:13.591425+0000 taler-merchant-dbinit-66923 ERROR Failed to garbage collect database

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

Wed, 10 Jun 2026 13:24:26 +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.

0011477: Implement NFC Confirmation Code Transmission with NFC

Wed, 10 Jun 2026 13:21:41 +0200

To achieve feature parity with the iOS application, the Android app needs to support sending received confirmation codes to the xOTP Generator/MDB via NFC.
Technical Specifications:
- Format: NDEF (Text format)
- Encoding: Raw 4-byte values
- Identifier Value: 0x42 ('B') as first byte
- Payload Size: 21 bytes expected
- Order: Big-endian / MSB first

0011497: Add new taler-wise adapter

Wed, 10 Jun 2026 09:59:28 +0200

New adapter only supporting incoming transactions for now for the https://wise.com/ platform

0011496: Update depolymerizer-bitcoin in sync with latest taler-rust and bitcoind [1w]

Wed, 10 Jun 2026 09:58:17 +0200

depolymerizer-bitcoin need to be updated with latest taler-rust version and need to be tested with latest bitcoind
New prepared transfer subject format need to be designed for bitcoin (maybe drop retro compatibility ?)

0011473: taler-merchant v1.6.x shows a taler-merchant-dbinit-gc.service systemd unit failure; upon upgrade?!

Wed, 10 Jun 2026 02:46:24 +0200

Error looking like this:

systemctl --failed
  UNIT                             LOAD   ACTIVE SUB    DESCRIPTION                                                            >
● taler-merchant-dbinit-gc.service loaded failed failed Job to remove stale data from the taler-merchant database (run as a tim>

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

1 loaded units listed.

0008892: Design Considerations for future *KEY types

Tue, 09 Jun 2026 18:23: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.