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

First version of Authz TLA+ #2

Merged
merged 29 commits into from
Sep 2, 2022
Merged

First version of Authz TLA+ #2

merged 29 commits into from
Sep 2, 2022

Conversation

hvanz
Copy link
Member

@hvanz hvanz commented Aug 16, 2022

Closes #1

@hvanz hvanz requested a review from ivan-gavran August 16, 2022 11:55
@ivan-gavran
Copy link
Contributor

I had a high-level look at the model. Let me write preliminary comments as the basis for the synchronous discussion tomorrow.

First thing to say, I am very impressed by how well structured and easy to read it is. It is also extremely modular.
One clarification question wrt to that is:
how does one check for different authorization logics (AuthzSend, AuthzStake...)? I can see that one could create e.g. AuthzSend_MC.[cfg, tla], but this then only allows checking for a single authorization logic (and not mixing between them)

I also notice that the model very much follows the code structure. I can see an advantage being that the developers of the implementation would have an easier time following along the model.
I can also see some disadvantages:

  • the model gets fairly complex
  • if it faithfully follows the implementation, then we should not expect to see mismatches between the code and the model
    Does this seem right?

Finally, a very high-level question: when you were looking at the existing model, what made you decide to start from scratch?
(Since I was working on the basis of it, this could be a useful feedback in model-writing for me.)

@hvanz hvanz marked this pull request as ready for review August 23, 2022 09:48
@hvanz hvanz self-assigned this Aug 23, 2022
@ivan-gavran ivan-gavran self-requested a review August 25, 2022 08:23
@ivan-gavran
Copy link
Contributor

ivan-gavran commented Aug 25, 2022

I just noticed one thing in the Cosmos-SDK codebase: they are also adding the allowList SendAuthorization. This is already merged in main, but is not part of any existing releases (check this PR). Bringing this up here so that we know what to expect when new releases come (I don't think we need to change our model yet).

models/authz/StakeAuthorization.tla Show resolved Hide resolved
[] auth.authorizationType \in Stake!MsgTypeUrls ->
Stake!MsgTypeURL(auth)

Accept(auth, msg) ==
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems that this way of modelling Accept prevents send or stake messages that rely on a generic authorization. Is that true?

Copy link
Member Author

@hvanz hvanz Aug 25, 2022

Choose a reason for hiding this comment

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

GenericAuthorization accepts any kind of message url, including send or delegate, for instance. The accepted messages are defined in the constant GenericAuthTypes. So one could instantiate this constant with any kind of message (I haven't tried it).

@hvanz
Copy link
Member Author

hvanz commented Aug 25, 2022

I just noticed one thing in the Cosmos-SDK codebase: they are also adding the allowList SendAuthorization. This is already merged in main, but is not part of any existing releases (check this PR). Bringing this up here so that we know what to expect when new releases come (I don't think we need to change our model yet).

If it's the same as in the Staking module, it should be easy to change. Good to know anyway.

@hvanz
Copy link
Member Author

hvanz commented Aug 29, 2022

I added to SendAuthorization an allowList field, which is implemented in cosmos-sdk since version 0.47.

Copy link
Contributor

@andrey-kuprianov andrey-kuprianov left a comment

Choose a reason for hiding this comment

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

The model is great! Very well structured, and logical. I have made some comments about potential improvements for using the model for test case generation, but those can be addressed separately later.

Comment on lines +169 to +170
/\ IsValid(g)
/\ ~ HasGrant(g) \/ IsExpired(g)
Copy link
Contributor

Choose a reason for hiding this comment

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

My feeling is that the way RequestGrant and other top-level operators from Next are too restrictive for testing purposes. In particular, we want to be able to test inputs where:

  • granter is the same as grantee
  • there is already a grant given, and it's not expired

So, in short, we should treat the inputs maximally non-deterministically, and ensure that the implementation fails for incorrect combinations of input parameters.

Comment on lines +186 to +187
/\ IsValid(g)
/\ HasGrant(g)
Copy link
Contributor

Choose a reason for hiding this comment

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

Same as RequestGrant above

Comment on lines +87 to +93
\* https://github.com/cosmos/cosmos-sdk/blob/c1b6ace7d542925b526cf3eef6df38a206eab8d8/x/authz/authz.pb.go#L74
\* @typeAlias: GRANT = [authorization: AUTH, expirationTime: EXPIRATION_TIME];
\* @type: Set(GRANT);
Grants == [
authorization: Authorization,
expirationTime: ExpirationTimes
]
Copy link
Contributor

Choose a reason for hiding this comment

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

Type AUTH is defined in each of Generic/Send/Stake Autohrization separately; and then it is used in Grants here. It is unclear which AUTH is used; in fact Apalache's type checker should have complained about having multiple type aliases with the same name

@andrey-kuprianov andrey-kuprianov merged commit fee85e9 into main Sep 2, 2022
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.

Create new TLA+ model for Authz
3 participants