`MintedValue` shouldn't be allowed to be compared for security reasons
KristianBalaj opened this issue · comments
When comparing Values with the == operator, the behaviour is correct since the internal representation is aiken/dict which has ordering invariant in place and additionally the Value has an invariant that 0 amount asset can't be in the dict.
However, comparing MintedValue poses a threat of vulnerability. Then e.g. comparing transaction.mint to some expected value that's converted to MintedValue using the to_minted_value can cause a problem.
Since the MintedValue doesn't have any invariants and can change over time as Ledger specifies it's items. Also, 0 lovelaces entry can be there.
Because of this, I'm proposing to not allow comparison of MintedValue types with the == operator. T
I think the easiest solution would be to remove the to_minted_value function and since the MintedValue type is opaque it would resolve this.
Actually, this should be fine. What shouldn't be allowed is to construct MintedValue.
Possibly constructing one from Value might be allow for testing purpose but then, we should enforce the invariant at that point to make comparison safe. That's arguably a bug that it doesn't happen now.
I think we won't need MintedValue anymore anyways once PlutusV3 drops. I think the zero ADA thing will go away?
I wish but i am not even sure of that. Plus, V3 is still likely months ahead so, we need to ensure what we have now works fine.