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
• Replace dapp-tools with foundry for compilation and deployment
• Extend checklists to enforce using stable foundry version and document used version / logs
• Add dockerfile + CI workflow to run tests using dapp-tools

[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.

[amusingaxl]

Going back to this after a while.

• Extend checklists to enforce using stable foundry version and document used version / logs

This one can be tricky. There's no "stability" in Foundry development yet, it follows the nightly releases approach, so it would be extremely hard to pinpoint a "safe" version.

• Add dockerfile + CI workflow to run tests using dapp-tools

This is also tricky because the current tests depend on Foundry and don't work on Dapp Tools anymore because we are using Foundry-specific features.

---

In the end of the day, I become more and more skeptical of the benefits that cross-checking brings. I am not aware of any other project in this industry that does that.

If we fear that supply chain attacks might occur, we can come up with a "dev manual" on how to deal with this (i.e.: only install Foundry from official sources), so we can minimize the risk.