View Issue Details

IDProjectCategoryView StatusLast Update
0008071Talerexchangepublic2024-03-07 20:47
Reporterfefe Assigned ToChristian Grothoff  
PrioritynormalSeveritytrivialReproducibilityhave not tried
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.9.4Fixed in Version0.9.4 
Summary0008071: TALER_denom_ewv_deep_copy does not actually do a deep copy
DescriptionThis is in exchange/src/util/denom.c:

254 void
255 TALER_denom_ewv_deep_copy (struct TALER_ExchangeWithdrawValues *bi_dst,
256 const struct TALER_ExchangeWithdrawValues *bi_src)
257 {
258 if (bi_src == TALER_denom_ewv_rsa_singleton ())
259 {
260 *bi_dst = *bi_src;
261 return;
262 }
263 bi_dst->blinding_inputs
264 = GNUNET_CRYPTO_blinding_input_values_incref (bi_src->blinding_inputs);
265 }

Not sure if this is of any significance in practice, but if the function is called deep_copy you might expect that it actually does a deep copy.
TagsNo tags attached.

Relationships

child of 0008112 assignedfefe Merchant security review 

Activities

fefe

2024-01-11 18:47

developer   ~0020864

Other deep_copy functions in the same file also don't do a deep copy.

Christian Grothoff

2024-01-11 18:51

manager   ~0020865

These are really read-only objects, so the bug is sure to have zero impact modulo code comprehension.
Using _incref instead of _deep_copy isn't exactly correct; I guess _copy might be OK, any better ideas?

fefe

2024-01-16 14:18

developer   ~0020891

I think both _incref and _copy would work better than _deep_copy.
Why would _incref not be correct?

Christian Grothoff

2024-01-16 14:19

manager   ~0020892

Well, it does an incref internally while copying into a new struct, but the outer struct we copy to doesn't have a reference counter. So incref on an object that doesn't have an RC itself seems, well, also confusing?

Christian Grothoff

2024-01-16 14:21

manager   ~0020893

Anyway, if _copy is fine for you, i'll kill the _deep and consider this done.

Christian Grothoff

2024-01-16 14:46

manager   ~0020894

exchange.git: fix in 6bfc96f4c..ec522a445
merchnat.git: fix in 4c1ed87d..537bb34b

Issue History

Date Modified Username Field Change
2024-01-11 18:46 fefe New Issue
2024-01-11 18:46 fefe Status new => assigned
2024-01-11 18:46 fefe Assigned To => Christian Grothoff
2024-01-11 18:47 fefe Note Added: 0020864
2024-01-11 18:51 Christian Grothoff Note Added: 0020865
2024-01-11 18:51 Christian Grothoff Severity minor => trivial
2024-01-11 18:51 Christian Grothoff Product Version => git (master)
2024-01-15 19:44 Florian Dold Target Version => 1.0
2024-01-16 13:33 Christian Grothoff Assigned To Christian Grothoff => fefe
2024-01-16 13:33 Christian Grothoff Status assigned => feedback
2024-01-16 14:18 fefe Note Added: 0020891
2024-01-16 14:19 Christian Grothoff Note Added: 0020892
2024-01-16 14:21 Christian Grothoff Note Added: 0020893
2024-01-16 14:46 Christian Grothoff Note Added: 0020894
2024-01-16 14:46 Christian Grothoff Status feedback => resolved
2024-01-16 14:46 Christian Grothoff Resolution open => fixed
2024-01-16 14:46 Christian Grothoff Fixed in Version => 0.9.4
2024-01-16 14:46 Christian Grothoff Assigned To fefe => Christian Grothoff
2024-01-16 14:46 Christian Grothoff Target Version 1.0 => 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