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

Remove module overriding #458

Merged
merged 1 commit into from
Jan 30, 2024
Merged

Remove module overriding #458

merged 1 commit into from
Jan 30, 2024

Conversation

Cameron-Low
Copy link
Contributor

As a fix for #380, disallow all ways of overriding a module when cloning a theory.
Note: this will most likely break some existing proofs.

@fdupress
Copy link
Member

No issue with SHA3 (as expected). Kyber, Dilithium, XMSS remain to be checked—I expect XMSS to be edgy.

Coming up with generic fixes to proofs that did (hopefully soundly) rely on module merging is going to take a bit, so we might not want to wait. Anyone worried about this can stay on release 2023.09 until we have a recipe, IMO.

@mbbarbosa
Copy link
Contributor

I have just fixed Kyber. I found that the code changes would be minimal, if we maintained the syntax for overriding modules with the different interpretation that you override types and operators and keep all copies of the things you can't override lying around. Could this be a less intrusive fix?

@fdupress
Copy link
Member

@Cameron-Low what are your thoughts on Manuel's proposal from the point of view of "how hard is this going to be to implement correctly?" (Or its dual "how easy is this going to be to mess up?")

@Cameron-Low
Copy link
Contributor Author

@mbbarbosa can you check the most recent commit and see if this is the behaviour you were after. (sorry for the delay)

@Cameron-Low Cameron-Low force-pushed the remove-module-cloning branch from d6d54ed to a3258c5 Compare January 29, 2024 15:52
@Cameron-Low
Copy link
Contributor Author

@mbbarbosa, revisiting this topic. After taking another look at how the implementation of your desired behaviour would go, there are quite a few areas that would need careful thought and overhaul. As a result of this, and some discussions with @fdupress and @strub, sticking with the original plan and outright removing module cloning seems to be the simplest/safest option at present.

src/ecParser.mly Show resolved Hide resolved
@fdupress
Copy link
Member

As a supportive side note, we (@MM45, Charlotte and I) now have some evidence that (some of) the valid but edgy behaviours of module overriding can be recovered using the variant of Hoare conseq that transfers invariants through an equiv. (That is, you have an invariant on module M, but you would really like to have it on module M' which is a clone of M. conseq equiv_M_M' (: inv ==> inv) allows you to do that if safe, and in particular if M and M' are truly equivalent.)

I will attempt to document a transition recipe ahead of release.

@Cameron-Low Cameron-Low merged commit f7992e1 into main Jan 30, 2024
14 checks passed
@Cameron-Low Cameron-Low deleted the remove-module-cloning branch January 30, 2024 16:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants