-
Global state variable vulnerability exists in chaincode so is it language-specific or it’s related to every code that runs on hyperledger fabric including Daml Contracts?
-
Can anyone provide insight on the vulnerabilities listed below for Daml Contracts:
Security Patterns
● Non-deterministic behaviour (may prevent consensus)
○ Iteration over map
○ Blacklisted imports
○ Goroutines
● Inconsistent behaviour (may prevent consensus)
○ Global state variables
○ Field variables in the chaincode struct
● Unexpected execution
○ Read after Write
○ Phantom Read
○ Unhandled Error
○ Missing Input Validation
HI @Iqra_Mustafa1 , welcome to the Daml Forums. Any relation to @Iqra_Mustafa ?
Your questions all relate to an attached chain code security report that is about Fabric’s chain code. Thus the security patterns and vulnerabilities relate to Hyperledger Fabric.
Chain code is not deterministic - the developer has to make sure it is. That’s what the security patterns that say “may prevent consensus” are about. Daml is deterministic. None of these patterns are an issue in Daml. The chain code we use to run Daml on Fabric is carefully crafted by us to be deterministic so “Global state variable vulnerability” is not something you need to worry about as a Daml for Fabric user.
The main topic of the doc, “Read after Write” is highlighting a specific issue with chain code’s way of managing state that can confuse developers and lead to unexpected results. Again - not an issue in Daml. I don’t know what Phantonm Read is about but probably something similar.
Handling Errors and validating inputs is something you also need to do in Daml.