Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add dependency audit contract #33

Merged
merged 7 commits into from
Jun 3, 2024

Conversation

janezpodhostnik
Copy link
Contributor

ref: onflow/flow-go#5858
ref: onflow/flow-core-contracts#430

Description

This is intended to work together with this FVM PR onflow/flow-go#5908 which is already deployed on testnet, so this can be deployed when it is ready. The contract is going to get called from the FlowServiceAccount. The PR for that is here: onflow/flow-core-contracts#430

This is only needed pre-1.0 and the checkDependencies function can (and will) be removed post-1.0. At that point the DependenciesAudit contract also becomes useless.

When deploying DependenciesAudit the service accounts (those containing service account contracts) will be listed as excluded addresses. More can be added later.

Open questions:

  • Is it ok to just have excludedAddresses or do we want to exclude specific contracts from the check?
  • Should we stage it? migrate it? or just let it expire, because we don't need it after 1.0 anyway

For contributor use:

  • Targeted PR against main branch
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the standards mentioned here.
  • Updated relevant documentation
  • Re-reviewed Files changed in the Github PR explorer
  • Added appropriate labels

@janezpodhostnik janezpodhostnik force-pushed the janez/dependency-audit branch from 013e2ad to 5e8737e Compare May 16, 2024 14:41
@janezpodhostnik janezpodhostnik marked this pull request as ready for review May 16, 2024 20:03
@janezpodhostnik janezpodhostnik requested a review from a team as a code owner May 16, 2024 20:03
Copy link
Member

@joshuahannan joshuahannan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

contracts/DependencyAudit.cdc Outdated Show resolved Hide resolved
contracts/DependencyAudit.cdc Outdated Show resolved Hide resolved
access(all) event PanicOnUnstagedDependenciesChanged(shouldPanic: Bool)

// checkDependencies is called from the FlowServiceAccount contract
access(self) fun checkDependencies(_ dependenciesAddresses: [Address], _ dependenciesNames: [String], _ authorizers: [Address]) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this param is unused, can this be removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is injected by the FVM. I added this incase we need to do some special handling according to authorizers.

contracts/DependencyAudit.cdc Outdated Show resolved Hide resolved
contracts/DependencyAudit.cdc Outdated Show resolved Hide resolved
contracts/DependencyAudit.cdc Outdated Show resolved Hide resolved
)
Test.expect(commitResult, Test.beFailed())
// not sure how to test this:
// Test.expect(commitResult.error!.message, Test.contain("panic: Found unstaged dependencies: A.0x0000000000000008.Foo") )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't able to find docs or prior art on how to implement and pass a custom handler to Test.expect, but I also validated locally that this is the reason the txn fails here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@sisyphusSmiling
Copy link
Contributor

sisyphusSmiling commented May 22, 2024

Is it ok to just have excludedAddresses or do we want to exclude specific contracts from the check?

I think excluding addresses is okay assuming excluded contracts will be core contracts in which case all contracts at those addresses would be excluded

Should we stage it? migrate it? or just let it expire, because we don't need it after 1.0 anyway

I guess that depends on

  1. What happens to contracts that fail to update - Are they removed from execution state automatically or would we be leaving garbage without collection?
  2. Do we expect all dependencies to migrate without dependency on this contract?

IMO if contracts that fail to update are simply removed from execution state and all dependencies migrate without dependency on this contract, it's probably not a problem to continue without staging. If however we're leaving garbage by not staging it and/or dependencies will fail their migration without staging this contract, we should stage this contract.

@janezpodhostnik
Copy link
Contributor Author

  1. What happens to contracts that fail to update - Are they removed from execution state automatically or would we be leaving garbage without collection?

They would be left as garbage.

  1. Do we expect all dependencies to migrate without dependency on this contract?

No-one should depend on this contract. The only contract that depends on this contract is the service account, but that dependency will be removed during the upgrade itself.

I think it might be best to still stage it, so that it is functional after the upgrade and can be gracefully cleaned up if needed. I will work on preparing and staging the contract.

@janezpodhostnik janezpodhostnik mentioned this pull request May 28, 2024
6 tasks
@janezpodhostnik
Copy link
Contributor Author

I opened #34 for cadence 1.0 port

@joshuahannan joshuahannan merged commit 1b212b9 into onflow:main Jun 3, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants