You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To ensure that the currently installed dependency is not malicious, we need an authoritative mechanism to verify that the dependency files are legitimate and have not been tampered with.
One solution is to implement a smart contract stored on-chain. This smart contract would serve as a consortium that publishes checksums after each version of a dependency is released.
For example, when OpenZeppelin publishes version 5.3.0, a checksum would be generated and submitted on-chain. This checksum would then serve as the source of truth in the integrity check process.
Challenges:
Approval of Checksums: The teams responsible for maintaining the on-chain integrity must approve the checksums. Without their approval, we cannot ensure the checksums' authenticity.
Collaboration: Soldeer aims to build and maintain this system but requires collaboration from all relevant teams to approve the checksums. Without their cooperation, the checksums provided by Soldeer cannot be fully trusted.
By addressing these challenges, we can create a robust system for verifying dependency integrity, ensuring that installed dependencies are secure and unaltered.
The text was updated successfully, but these errors were encountered:
It would be great to find a way to check integrity of dependencies.
Feels like the first step is simply having signed checksums for popular libs as most don't do this afaik (?). The issue then becomes how teams manage key security but there are well known procedures for that.
Enhancing Dependency Integrity Verification
To ensure that the currently installed dependency is not malicious, we need an authoritative mechanism to verify that the dependency files are legitimate and have not been tampered with.
One solution is to implement a smart contract stored on-chain. This smart contract would serve as a consortium that publishes checksums after each version of a dependency is released.
For example, when OpenZeppelin publishes version 5.3.0, a checksum would be generated and submitted on-chain. This checksum would then serve as the source of truth in the integrity check process.
Challenges:
By addressing these challenges, we can create a robust system for verifying dependency integrity, ensuring that installed dependencies are secure and unaltered.
The text was updated successfully, but these errors were encountered: