- Hashes of (normal) denominations and age-restricted denominations are
calculated seperately
- The hash of the age-restricted ones will then be added to the other
hash
- The total hash is signed/verified
So far: test_exchange_api runs, including withdraw_age!
However, test_auditor_api fails and another is in a endless loop!
Age_mask now taken into account when denominations are being setup.
However, tests fail, because denoms can't be found!? Probably because
on initial generation of the denominations, the age mask is not setup,
yet, because age restriction hasn't been enabled yet!?
- all prepared statements re: denominations now handle age_mask
- signatures parameters adjusted.
Now compiles and Tests run but fail.
- good: we find denoms[] and age_restricted_denoms[] filled correctly in
output to /keys
- bad: fails at exchange_api_handle.c:882, signature verification of
denom.
Towards a complete test with age restriction
- substantial amount of fixes in various parts
- slight refactoring of extensions
- fixes of post handler for /management/extensions
- fixes for offline tool extensions signing
State:
- compiles, runs and tests succeed when age restriction is not
enabled
- compiles, runs and tests fail, when age restriction is enabled
- substantial amount of fixes in various parts
- slight refactoring of extensions
- fixes of post handler for /management/extensions
- fixes for offline tool extensions signing
State:
- compiles, runs and tests succeed when age restriction is not enabled
- compiles, runs and tests fail, when age restriction is enabled
- TALER_EXCHANGE_DenomPublickey now carries age_mask
- TALER_TESTING_cmd_withdraw_amount* takes age parameter
- WithdrawState carries age_commitment and its hash
- withdraw_run derives new age commitment, if applicable
- age restriction extension simplified
- its config is now global to extension
- helper functions and macros introduced
- age restriction support for
- melt is done
- reveal continued
- link started
- major refactoring of extensions
- extensions live now in a separate library, libtalerextensions
- refactored all components using age_restriction accordingly
- plumbing for plugin support for extensions roughly layed down
- taler-offline-tool now handles extensions
- command "extensions" added with subcommands "show" and "sign"
- parses extensions from taler config
- shows and signs of extensions and their configurations
- creates signed set of configurations for upload
- added test for retrieval of extension config
- simplified signature verification for extensions
- remove per-extension signatures, also from DB schema
- adjust prepared statements accordingly
- adjust DB event handler for extensions
- allow NULL for config for extension in DB schema
- handler for /management/extensions adjusted to new datastructures
- changed test for TALER_denom_blind/TALER_denom_sign_blinded with and
without TALER_AgeHash
- minor updates and various fixes
add back #include <sys/eventfd.h>, but conditionalize on #ifdef __linux__
(This fix follows the spirit of the other changes (i.e.,
adding #ifdef __linux__) but might not be the best solution.)
The current "/recoup" API does not have clear idempotency semantics, as we've discussed on the phone. This is already bad by itself, as it makes it hard to write down what the API does other than "whatever the implementation does".
However, it actually breaks correctness in this (admittedly kinda contrived, but not impossible) case:
Say that we have a coin A obtained via withdrawal and a coin B obtained via refreshing coin A. Now the denominations of A gets revoked..
The wallet does a recoup of A for EUR:1.
Now the denomination of B also gets revoked. The wallet recoups B (incidentally also for EUR:1) and now A can be recouped again for EUR:1. But now the exchange is in a state where it will refuse a legitimate recoup request for A because the detection for an idempotent request kicks in.
This is IMHO bad API design, and the exchange should simply always recoup the maximum amount.
Furthermore, we usually follow the principle of "API calls that take up DB space are paid". With the current recoup API, I can do many tiny recoup requests which the exchange then has to store, right?
I guess it would not be a big change to remove the "amount" value from the recoup/recoup-refresh request bodies, right?
- Florian
Parse age restriction information from "/keys"
- parse "age_restriction" extension, extract mask for age groups
- parse denominations from "age_restricted_denoms", too, if available
More work towards support for extensions:
- Prepared statements and DB-plugin-functions for setting and retrieving
configurations from the database added.
- primitive "registry" of extensions for age restrictions and peer2peer
(stub)
- TALER_Extensions now with FP for parsing, setting and converting a
configuration.
- /management/extensions handler now verifies signature of the (opaque)
json object for all extensions.
- /management/extensions handler calls the FP in the corrensponding
TALER_Extension for parsing and setting the configuration of a
particular extension
More work towards age restriction:
- TALER_Extensions interfaces for config-parser, -setter and converter
implemented for age restriction
- DB event handler now retrieves config from database, parses it and
sets it (the age mask) in the global extension.
- load_age_mask now loads age mask from the global extension (and not
from the config file)
- add age_restricted_denoms to /keys response
More worke towards support for extensions and age restriction:
- taler-exchange-httpd_management_extensions.c almost completed
- handling of request implemented
- stub "set_extensions" for database transaction added
- utility functions added
- TALER_exchange_offline_extension_agemask_{sign,verify}
- TALER_agemask_parse_json
