View Issue Details

IDProjectCategoryView StatusLast Update
0008095Talerexchangepublic2024-03-07 20:47
Reporterfefe Assigned ToChristian Grothoff  
PrioritynormalSeveritytextReproducibilityhave not tried
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.9.4Fixed in Version0.9.4 
Summary0008095: reserve_batch_withdraw_ok: misleading comment?
DescriptionThis is in exchange/src/lib/exchange_api_batch_withdraw2.c:

The comment above the function says:

 89 /**
 90 * We got a 200 OK response for the /reserves/$RESERVE_PUB/batch-withdraw operation.
 91 * Extract the coin's signature and return it to the caller. The signature we
 92 * get from the exchange is for the blinded value. Thus, we first must
 93 * unblind it and then should verify its validity against our coin's hash.

The code itself looks like this:

123 json_array_foreach (ja, index, j)
124 {
125 struct GNUNET_JSON_Specification spec[] = {
126 TALER_JSON_spec_blinded_denom_sig ("ev_sig",
127 &blind_sigs[index]),
128 GNUNET_JSON_spec_end ()
129 };
130
131 if (GNUNET_OK !=
132 GNUNET_JSON_parse (j,
133 spec,
134 NULL, NULL))
135 {
136 GNUNET_break_op (0);
137 for (unsigned int i = 0; i<index; i++)
138 TALER_blinded_denom_sig_free (&blind_sigs[i]);
139 return GNUNET_SYSERR;
140 }
141 }
142
143 /* signature is valid, return it to the application */

We just extracted the signature from the json. How do we know it is valid?
I'm probably missing something here, but the code looks like it's not actually verifying anything about the signatures.

I followed TALER_JSON_spec_blinded_denom_sig to see whether the parser maybe implicitly validates the signature, but it does not appear to do that.

Where are the things done that the comment above the function promises?
Is that something the caller is expected to do?
Then I would recommend clarifying the comment in that respect.
TagsNo tags attached.

Relationships

child of 0008112 assignedfefe Merchant security review 

Activities

Christian Grothoff

2024-01-16 13:28

manager   ~0020888

Fixed in 4cf9e0000..6bfc96f4c. Also clarified in the external API call that withdraw2 cannot verify the signatures.

Issue History

Date Modified Username Field Change
2024-01-16 13:10 fefe New Issue
2024-01-16 13:10 fefe Status new => assigned
2024-01-16 13:10 fefe Assigned To => Christian Grothoff
2024-01-16 13:28 Christian Grothoff Status assigned => resolved
2024-01-16 13:28 Christian Grothoff Resolution open => fixed
2024-01-16 13:28 Christian Grothoff Fixed in Version => 0.9.4
2024-01-16 13:28 Christian Grothoff Note Added: 0020888
2024-01-16 13:28 Christian Grothoff Severity minor => text
2024-01-16 13:28 Christian Grothoff Product Version => git (master)
2024-01-16 13:28 Christian Grothoff Target Version => 0.9.4
2024-01-18 23:32 Christian Grothoff Relationship added child of 0008112
2024-03-07 20:47 Christian Grothoff Status resolved => closed