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.

Sign up for GitHub

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

Jump to bottom

[Neo Core Fix] Check params at Calling Contract #3438

Open
wants to merge 9 commits into
base: HF_Echidna
Choose a base branch
from
Open

[Neo Core Fix] Check params at Calling Contract #3438

wants to merge 9 commits into from

Conversation

Jim8y
Copy link
Contributor

@Jim8y Jim8y commented Jul 25, 2024 •
edited
Loading

Description

Neo core does not check the type of vales being passed to the contract, and this can cause problems.

for example: neo-project/neo-devpack-dotnet#863

Fixes # #1891 neo-project/neo-devpack-dotnet#863

Type of change

  • Optimization (the change is only an optimization)
  • Style (the change is only a code style for better maintenance or standard purpose)
  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

  • Runtime_GetNotifications_Test
  • Check_BalanceOfTransferAndBurn

Test Configuration:

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

@Jim8y Jim8y added Waiting for Review Blocked This issue can't be worked at the moment Waiting-Hardfork labels Jul 25, 2024
@Jim8y Jim8y requested review from cschuchardt88 and shargon July 25, 2024 18:53
@roman-khimov
Copy link
Contributor

Wait, wait, wait a minute! As much as I love this change you can't just roll it out with the nearest hardfork. Remember all the pain of #2810. We need to:

  • pre-announce it
  • make adjustments to compilers if needed
  • add some checks/logs to the node for developers to be aware
  • wait for them to update their contracts and have ~0 warnings in logs for current blocks
  • schedule the update

@lock9
Copy link
Contributor

lock9 commented Jul 26, 2024

Will this affect calls between contracts?

@Jim8y
Copy link
Contributor Author

Jim8y commented Jul 26, 2024

Wait, wait, wait a minute! As much as I love this change you can't just roll it out with the nearest hardfork. Remember all the pain of #2810. We need to:

  • pre-announce it
  • make adjustments to compilers if needed
  • add some checks/logs to the node for developers to be aware
  • wait for them to update their contracts and have ~0 warnings in logs for current blocks
  • schedule the update

Exactly, this pr is marked as blocked, so will not be merged without careful review and discussion.

@Jim8y
Copy link
Contributor Author

Jim8y commented Jul 26, 2024

Will this affect calls between contracts?

Yes, it will. That is why this pr may only take effect to contracts that are depolyed or updated after the next hardfork,,,,,, will be discussed.

shargon
shargon reviewed Jul 27, 2024
View reviewed changes
Copy link
Member

@shargon shargon left a comment

Choose a reason for hiding this comment

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

It's hard to know if this will break some contracts, because we can alter the type in some operations and the opcodes are compatible with multiple types..

@Jim8y Jim8y mentioned this pull request Aug 7, 2024
Draft
10 tasks
@Jim8y Jim8y changed the base branch from master to HF_Echidna August 7, 2024 16:29
AnnaShaleva
AnnaShaleva reviewed Aug 7, 2024
View reviewed changes
src/Neo/SmartContract/ApplicationEngine.Runtime.cs
@@ -449,6 +449,7 @@ protected internal Signer[] GetCurrentSigners()
private static bool CheckItemType(StackItem item, ContractParameterType type)
{
StackItemType aType = item.Type;
if (aType == StackItemType.Any) return true;
Copy link
Member

Choose a reason for hiding this comment

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

I don't think it's correct for VM-compatible SC types, because for example, if you require stackitem to be Boolean, then Any just doesn't match this requirement.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see what you mean, will update.

src/Neo/SmartContract/ApplicationEngine.cs
@@ -319,7 +319,11 @@ private ExecutionContext CallContractInternal(ContractState contract, ContractMe
state.CallingContext = currentContext;

for (int i = args.Count - 1; i >= 0; i--)
{
if (!CheckItemType(args[i], method.Parameters[i].Type))
throw new InvalidOperationException($"The type of the argument `{args[i]}` does not match the formal parameter.");
Copy link
Member

@AnnaShaleva AnnaShaleva Aug 7, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

It may be too harsh for mainnet contracts (even if enabled with hardfrok), this change may break some of them and even prevent them from update. What do you think about using the same approach as it was done for SC Events parameters check (#2810 (comment)): in next release we firstly enable a warning log in case of parameters mismatch, and then in the subsequent release we convert the log to an exception.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It may be too harsh for mainnet contracts (even if enabled with hardfrok), this change may break some of them and even prevent them from update. What do you think about using the same approach as it was done for SC Events parameters check (#2810 (comment)): in next release we firstly enable a warning log in case of parameters mismatch, and then in the subsequent release we convert the log to an exception.

We have discussed this in the last meeting, check will only happen for newly deployed or updated contracts, this pr will be updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@AnnaShaleva AnnaShaleva AnnaShaleva left review comments

@shargon shargon shargon left review comments

@cschuchardt88 cschuchardt88 Awaiting requested review from cschuchardt88

Assignees
No one assigned
Labels
Blocked This issue can't be worked at the moment Hardfork Waiting for Review
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@Jim8y @roman-khimov @lock9 @shargon @AnnaShaleva