View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004520 | Taler | exchange | public | 2016-05-23 11:39 | 2016-05-26 12:09 |
| Reporter | Florian Dold | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.0 | ||||
| Target Version | 0.0 | Fixed in Version | 0.0 | ||
| Summary | 0004520: TALER_EXCHANGE_deposit does not distinguish between merchant and customer errors | ||||
| Description | The function TALER_EXCHANGE_deposit returns NULL *both* when the signatures are invalid *and* when the merchant configuration is wrong (refund_deadline.abs_value_us > wire_deadline.abs_value_us). This means that we're telling the wallet "invalid coin signatures", when in fact the source of the problem is somewhere else (bad merchant configuration). We need: a) error codes to distinguish between those error cases, so we can report back correctly to the merchant and the wallet b) logging, because this kind of issue shouldn't log something like May 23 13:26:09-220782 taler-merchant-httpd-25945 ERROR Assertion failed at exchange_api_deposit.c:411. May 23 13:26:09-220799 taler-merchant-httpd-25945 WARNING External protocol violation detected at taler-merchant-httpd_pay.c:613. since it makes diagnosing these kind of issues more annoying than it should be. | ||||
| Tags | No tags attached. | ||||
| I don't think this is what we want. Basically, if we return different error codes, we also need to expect the clients to handle both cases. But we really don't want to write logic to handle the expiration/edate mess, as that is already a bug. What we should do is not return two different error codes, but in the case of the API violation be more strict and just call GNUNET_assert(). That'll give us a nice core dump showing where and how the API was violated. | |
| Fixed in f471cfc..079ef7c. API violations (that client could and should have checked against and prevented) now result in GNUNET_assert(). | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-05-23 11:39 | Florian Dold | New Issue | |
| 2016-05-23 11:39 | Florian Dold | Status | new => assigned |
| 2016-05-23 11:39 | Florian Dold | Assigned To | => Christian Grothoff |
| 2016-05-24 18:31 | Christian Grothoff | Note Added: 0010732 | |
| 2016-05-24 18:38 | Christian Grothoff | Note Added: 0010733 | |
| 2016-05-24 18:38 | Christian Grothoff | Status | assigned => informing |
| 2016-05-24 18:38 | Christian Grothoff | Fixed in Version | => 0.0 |
| 2016-05-24 18:38 | Christian Grothoff | Resolution | open => fixed |
| 2016-05-24 18:38 | Christian Grothoff | Product Version | => 0.0 |
| 2016-05-24 18:38 | Christian Grothoff | Target Version | => 0.0 |
| 2016-05-26 12:09 | Christian Grothoff | Status | informing => closed |