Agree on deprecating dapp tools

[SidestreamColdMelon]

Discuss strategy of dapp tools deprecation and if we want to do it.

One counter argument: having dapp tools and foundry cross checking the output binary is better than having a single tool to circumvent supply chain attacks. In this case, we can make foundry the main development+deployment tool and use dapp-tools for crosschecking (and not the way around).

[SidestreamColdMelon]

Based on the above, the following would be a proposed plan to migrate from dapp-tools:

• Remove dependency on dapp-tools for flattening the source code
  • Implemented here Refactor: replace dapp-tools with foundry for spell flattening #391
• Replace all occurrences of seth and hevm commands with alternatives (foundry/python/node-based)
• Remove dependency on ./out/dapp.sol.json file
• Add dockerfile + CI workflow to run tests using dapp-tools
• Extend checklists to enforce using stable foundry version and document used version / logs
• Replace dapp-tools with foundry for compilation and deployment

[amusingaxl]

I agree with the changes.
The only potentially challenging part would be setting up dapp tools in CI for cross-checking.

With that said, dapp tools being basically abandonware nowadays adds more risks than benefits.

Supply chain attacks would most likely be very hard to catch, since MakerDAO is probably the only relevant org that keeps using it. If we do not very thoroughly check the sources from which we pull the executables every single time, it would be very hard to catch a problem. However, this seems like a huge operational burden.

An alternative would be to port the "immutable" part of the flow (i.e.: base tests) to another tool that is still under active maintenance, such as Hardhat, and perform the cross-checks with it.

[SidestreamColdMelon]

dapp tools being basically abandonware nowadays adds more risks than benefits.

I don't think it adds any risks if it's executed within a CI / docker environment and is no longer used for deployment (or otherwise have access to private keys) – this way, dapp-tools would only get access to the spell code which is already available to everyone. The only thing approach adds:

• Overhead for the one-time setup of the environment (creating a docker file + CI config)
• Overhead for keeping test configuration compatible with both tools (this is kind of what we are doing already by running tests with foundry and deploying with dapp tools)

This approach removes the risk of either foundry or dapp-tools going rogue, but not saving us from other supply chain attacks (eg patched solc compiler) – but that wouldn't be achievable even with the proposed Hardhat-based tests.

An alternative would be to port the "immutable" part of the flow (i.e.: base tests) to another tool that is still under active maintenance, such as Hardhat, and perform the cross-checks with it.

I see that this brings a huge overhead on keeping two source codes written in different languages in sync. I can also imagine that hardhat-based tests would be a lot slower.