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

test(GHW): Run Java Examples for PR CI #749

Merged
merged 10 commits into from
Sep 21, 2024
Merged

Conversation

texastony
Copy link
Contributor

Issue #, if available:

Description of changes:

Squash/merge commit message, if applicable:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@texastony texastony merged commit c4adb79 into rc-1.7.0 Sep 21, 2024
67 of 70 checks passed
@texastony texastony deleted the tony/ci-java-examples branch September 21, 2024 03:13

```
├── ..
└── Hierarchy: Examples for manging the Hierarchical Keyring's Key Store
Copy link
Contributor

Choose a reason for hiding this comment

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

s/manging/managing

Copy link
Contributor

@josecorella josecorella left a comment

Choose a reason for hiding this comment

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

is a good show yes 🫡

texastony added a commit that referenced this pull request Nov 15, 2024
texastony added a commit that referenced this pull request Nov 15, 2024
texastony added a commit that referenced this pull request Nov 15, 2024
Explicitly:
- Change InitializeMutationFlag from a union to an enum for ToString reasons
- Model `DoNotVersion` flag for Initialize Mutation
- Refactor Describe Mutation output to detail Input so resume can be done
- Refactor System Key to be optional, detailing that TrustStorage is the default
- More errors
- Smithy changes from PR feedback on #854
- Correction of spelling mistakes
- Mutation Token's UUID is required

Why change the flag to an enum?

Dafny/Smithy-Dafny's support for Union's results in structures that do not print well.
The intention of the  `InitializeMutationFlag` is to inform customers
about the result of their request.

Such information may,
possibly even should,
be logged.

Initialize Mutation and Apply Mutation MUST
ensure that the UUID of the Index and Commitment agree.
Apply MUST ensure that the UUID of the Commitment and Token agree.
The Mutation Token's UUID is REQUIRED.
It is how we track a mutation,
much like how CFN tracks a change set.

Fixed bug where UUID is a reserved word in DDB.

Refactored some of the error messages.
Utilize Java Example to demonstrate resume and restart.
Finally, addressed some of the feedback on PR #854.

feat(Mutations): Idempotent Resume (#854)

Refactor Storage:
- Rename Mutation Lock to Mutation Commitment
- Introduce Mutation Index to describe what items of a Branch Key have been mutated
- Add Input field to Mutation Commitment
- Add Ciphertext field to Mutation Commitment
- When Mutating an item, always write with an optimistic lock
- Allow Initialize Mutation to over write a Version, instead of only creating a version
- When Overwriting a Mutation Index, ensure it has not changed
- Whenever writing for Mutation, ensure the Mutation Commitment's ENC is as expected (along with original and terminal)

Refactor Storage to contain operations that:
1. Allow for Atomic Mutations (maybe cut later)
2. Allow for Deleting a Mutation
3. Allow for Creating a Mutation Index

Refactor KeyStoreAdmin:
- Support a System Key for Mutations
- Stub out the System Key
- Logic for handling Mutation Index

Refactor Initialize Mutation:
- If Commitment & Index already exist and match Input, write nothing and return token
- If Commitment already exists and matches input, write index, and return token
- If Commitment already exists and does not match input, fail
- If no commitment, Initialize Mutation

Refactor Apply Mutation:
- Write an update Page Index.

fix: Dafny intendation formatting

chore: fix Java test examples

chore: more fomratting for CI

feat(Mutations): Native test for Loose access in-flight

feat(Mutations): Example In Flight Mutation Scanner

feat(Mutations-TODO): Some Terminal KMS Exceptions (#795)

If the KMS Call, for mutating the Beacon, fails,
it MAY indicate the MPL Consumer does not have access to the
terminal KMS Key.

If the KMS call for verifying a terminal version fails,
it MAY indicate the MPL Consumer does not have access to the
terminal KMS Key.

Also fix some Dafny tests failing verification.

feat(KS+): More modeled errors (#754)

* refactor(Storage): Use TransactGet instead of BatchGet for GetInitMut (#753)

This resolves feedback from both @seebees  and @josecorella
on Mutations branch.

* chore(Mutations): address #754\#discussion_r1775676091

#754 (comment)

* chore(Mutations): Address feedback from #750

See #750

* chore(Mutations): address feedback on #742

See #742

refactor(Storage): Use TransactGet instead of BatchGet for GetInitMut (#753)

This resolves feedback from both @seebees  and @josecorella
on Mutations branch.

Verification failure is due to (just like in #751 ):
1. Key Store Admin's Index.dfy not proving Fresh, which has been a long standing issue with the Admin
2. In `AwsCryptographyKeyStore/test/Storage/TestGetItemsForInitializeMutation.dfy`, the test assumes `type` is in the Encryption Context. It is, but Structure.dfy does not prove that, so it must be proven else where.

A .NET MPL job failed due to .NET 48 Sig V4 Auth bug.

test(Mutations): additional testing for Mutations

feat(Mutations): more clean up

feat(Mutations): log statements for ApplyMutation

fix(Storage): typo

fix(Storage): ensure KmsArn is valid

chore(Mutations): respond to comments on PR #720

test(GHW): Run Java Examples for PR CI (#749)

chore(Java): Examples for Mutations (#742)

chore(Mutations): comment out non-GA Mutations (#750)

Crypto Tools, at this time, intends to release Branch Key Mutations
without some operations useful for recovering a dropped Mutation Token
or dealing with the disagreement of a Mutation Token and a Mutation Lock.

Additionally,
we intend to release the Key Store Admin with only support for
one Key Management Strategy.

All checks are green except for Verification.
Verification is failing for the Key Store Admin's Index.dfy.

Verification for the Key Store Admin's Index.dfy
has been failing for a long time.

feat: Mutations BETA (#720)

Beta build of Mutations with several substantial gaps
texastony added a commit that referenced this pull request Nov 20, 2024
Explicitly:
- Change InitializeMutationFlag from a union to an enum for ToString reasons
- Model `DoNotVersion` flag for Initialize Mutation
- Refactor Describe Mutation output to detail Input so resume can be done
- Refactor System Key to be optional, detailing that TrustStorage is the default
- More errors
- Smithy changes from PR feedback on #854
- Correction of spelling mistakes
- Mutation Token's UUID is required

Why change the flag to an enum?

Dafny/Smithy-Dafny's support for Union's results in structures that do not print well.
The intention of the  `InitializeMutationFlag` is to inform customers
about the result of their request.

Such information may,
possibly even should,
be logged.

Initialize Mutation and Apply Mutation MUST
ensure that the UUID of the Index and Commitment agree.
Apply MUST ensure that the UUID of the Commitment and Token agree.
The Mutation Token's UUID is REQUIRED.
It is how we track a mutation,
much like how CFN tracks a change set.

Fixed bug where UUID is a reserved word in DDB.

Refactored some of the error messages.
Utilize Java Example to demonstrate resume and restart.
Finally, addressed some of the feedback on PR #854.

feat(Mutations): Idempotent Resume (#854)

Refactor Storage:
- Rename Mutation Lock to Mutation Commitment
- Introduce Mutation Index to describe what items of a Branch Key have been mutated
- Add Input field to Mutation Commitment
- Add Ciphertext field to Mutation Commitment
- When Mutating an item, always write with an optimistic lock
- Allow Initialize Mutation to over write a Version, instead of only creating a version
- When Overwriting a Mutation Index, ensure it has not changed
- Whenever writing for Mutation, ensure the Mutation Commitment's ENC is as expected (along with original and terminal)

Refactor Storage to contain operations that:
1. Allow for Atomic Mutations (maybe cut later)
2. Allow for Deleting a Mutation
3. Allow for Creating a Mutation Index

Refactor KeyStoreAdmin:
- Support a System Key for Mutations
- Stub out the System Key
- Logic for handling Mutation Index

Refactor Initialize Mutation:
- If Commitment & Index already exist and match Input, write nothing and return token
- If Commitment already exists and matches input, write index, and return token
- If Commitment already exists and does not match input, fail
- If no commitment, Initialize Mutation

Refactor Apply Mutation:
- Write an update Page Index.

fix: Dafny intendation formatting

chore: fix Java test examples

chore: more fomratting for CI

feat(Mutations): Native test for Loose access in-flight

feat(Mutations): Example In Flight Mutation Scanner

feat(Mutations-TODO): Some Terminal KMS Exceptions (#795)

If the KMS Call, for mutating the Beacon, fails,
it MAY indicate the MPL Consumer does not have access to the
terminal KMS Key.

If the KMS call for verifying a terminal version fails,
it MAY indicate the MPL Consumer does not have access to the
terminal KMS Key.

Also fix some Dafny tests failing verification.

feat(KS+): More modeled errors (#754)

* refactor(Storage): Use TransactGet instead of BatchGet for GetInitMut (#753)

This resolves feedback from both @seebees  and @josecorella
on Mutations branch.

* chore(Mutations): address #754\#discussion_r1775676091

#754 (comment)

* chore(Mutations): Address feedback from #750

See #750

* chore(Mutations): address feedback on #742

See #742

refactor(Storage): Use TransactGet instead of BatchGet for GetInitMut (#753)

This resolves feedback from both @seebees  and @josecorella
on Mutations branch.

Verification failure is due to (just like in #751 ):
1. Key Store Admin's Index.dfy not proving Fresh, which has been a long standing issue with the Admin
2. In `AwsCryptographyKeyStore/test/Storage/TestGetItemsForInitializeMutation.dfy`, the test assumes `type` is in the Encryption Context. It is, but Structure.dfy does not prove that, so it must be proven else where.

A .NET MPL job failed due to .NET 48 Sig V4 Auth bug.

test(Mutations): additional testing for Mutations

feat(Mutations): more clean up

feat(Mutations): log statements for ApplyMutation

fix(Storage): typo

fix(Storage): ensure KmsArn is valid

chore(Mutations): respond to comments on PR #720

test(GHW): Run Java Examples for PR CI (#749)

chore(Java): Examples for Mutations (#742)

chore(Mutations): comment out non-GA Mutations (#750)

Crypto Tools, at this time, intends to release Branch Key Mutations
without some operations useful for recovering a dropped Mutation Token
or dealing with the disagreement of a Mutation Token and a Mutation Lock.

Additionally,
we intend to release the Key Store Admin with only support for
one Key Management Strategy.

All checks are green except for Verification.
Verification is failing for the Key Store Admin's Index.dfy.

Verification for the Key Store Admin's Index.dfy
has been failing for a long time.

feat: Mutations BETA (#720)

Beta build of Mutations with several substantial gaps
texastony added a commit that referenced this pull request Nov 20, 2024
Explicitly:
- Change InitializeMutationFlag from a union to an enum for ToString reasons
- Model `DoNotVersion` flag for Initialize Mutation
- Refactor Describe Mutation output to detail Input so resume can be done
- Refactor System Key to be optional, detailing that TrustStorage is the default
- More errors
- Smithy changes from PR feedback on #854
- Correction of spelling mistakes
- Mutation Token's UUID is required

Why change the flag to an enum?

Dafny/Smithy-Dafny's support for Union's results in structures that do not print well.
The intention of the  `InitializeMutationFlag` is to inform customers
about the result of their request.

Such information may,
possibly even should,
be logged.

Initialize Mutation and Apply Mutation MUST
ensure that the UUID of the Index and Commitment agree.
Apply MUST ensure that the UUID of the Commitment and Token agree.
The Mutation Token's UUID is REQUIRED.
It is how we track a mutation,
much like how CFN tracks a change set.

Fixed bug where UUID is a reserved word in DDB.

Refactored some of the error messages.
Utilize Java Example to demonstrate resume and restart.
Finally, addressed some of the feedback on PR #854.

feat(Mutations): Idempotent Resume (#854)

Refactor Storage:
- Rename Mutation Lock to Mutation Commitment
- Introduce Mutation Index to describe what items of a Branch Key have been mutated
- Add Input field to Mutation Commitment
- Add Ciphertext field to Mutation Commitment
- When Mutating an item, always write with an optimistic lock
- Allow Initialize Mutation to over write a Version, instead of only creating a version
- When Overwriting a Mutation Index, ensure it has not changed
- Whenever writing for Mutation, ensure the Mutation Commitment's ENC is as expected (along with original and terminal)

Refactor Storage to contain operations that:
1. Allow for Atomic Mutations (maybe cut later)
2. Allow for Deleting a Mutation
3. Allow for Creating a Mutation Index

Refactor KeyStoreAdmin:
- Support a System Key for Mutations
- Stub out the System Key
- Logic for handling Mutation Index

Refactor Initialize Mutation:
- If Commitment & Index already exist and match Input, write nothing and return token
- If Commitment already exists and matches input, write index, and return token
- If Commitment already exists and does not match input, fail
- If no commitment, Initialize Mutation

Refactor Apply Mutation:
- Write an update Page Index.

fix: Dafny intendation formatting

chore: fix Java test examples

chore: more fomratting for CI

feat(Mutations): Native test for Loose access in-flight

feat(Mutations): Example In Flight Mutation Scanner

feat(Mutations-TODO): Some Terminal KMS Exceptions (#795)

If the KMS Call, for mutating the Beacon, fails,
it MAY indicate the MPL Consumer does not have access to the
terminal KMS Key.

If the KMS call for verifying a terminal version fails,
it MAY indicate the MPL Consumer does not have access to the
terminal KMS Key.

Also fix some Dafny tests failing verification.

feat(KS+): More modeled errors (#754)

* refactor(Storage): Use TransactGet instead of BatchGet for GetInitMut (#753)

This resolves feedback from both @seebees  and @josecorella
on Mutations branch.

* chore(Mutations): address #754\#discussion_r1775676091

#754 (comment)

* chore(Mutations): Address feedback from #750

See #750

* chore(Mutations): address feedback on #742

See #742

refactor(Storage): Use TransactGet instead of BatchGet for GetInitMut (#753)

This resolves feedback from both @seebees  and @josecorella
on Mutations branch.

Verification failure is due to (just like in #751 ):
1. Key Store Admin's Index.dfy not proving Fresh, which has been a long standing issue with the Admin
2. In `AwsCryptographyKeyStore/test/Storage/TestGetItemsForInitializeMutation.dfy`, the test assumes `type` is in the Encryption Context. It is, but Structure.dfy does not prove that, so it must be proven else where.

A .NET MPL job failed due to .NET 48 Sig V4 Auth bug.

test(Mutations): additional testing for Mutations

feat(Mutations): more clean up

feat(Mutations): log statements for ApplyMutation

fix(Storage): typo

fix(Storage): ensure KmsArn is valid

chore(Mutations): respond to comments on PR #720

test(GHW): Run Java Examples for PR CI (#749)

chore(Java): Examples for Mutations (#742)

chore(Mutations): comment out non-GA Mutations (#750)

Crypto Tools, at this time, intends to release Branch Key Mutations
without some operations useful for recovering a dropped Mutation Token
or dealing with the disagreement of a Mutation Token and a Mutation Lock.

Additionally,
we intend to release the Key Store Admin with only support for
one Key Management Strategy.

All checks are green except for Verification.
Verification is failing for the Key Store Admin's Index.dfy.

Verification for the Key Store Admin's Index.dfy
has been failing for a long time.

feat: Mutations BETA (#720)

Beta build of Mutations with several substantial gaps
texastony added a commit that referenced this pull request Nov 20, 2024
Explicitly:
- Change InitializeMutationFlag from a union to an enum for ToString reasons
- Model `DoNotVersion` flag for Initialize Mutation
- Refactor Describe Mutation output to detail Input so resume can be done
- Refactor System Key to be optional, detailing that TrustStorage is the default
- More errors
- Smithy changes from PR feedback on #854
- Correction of spelling mistakes
- Mutation Token's UUID is required

Why change the flag to an enum?

Dafny/Smithy-Dafny's support for Union's results in structures that do not print well.
The intention of the  `InitializeMutationFlag` is to inform customers
about the result of their request.

Such information may,
possibly even should,
be logged.

Initialize Mutation and Apply Mutation MUST
ensure that the UUID of the Index and Commitment agree.
Apply MUST ensure that the UUID of the Commitment and Token agree.
The Mutation Token's UUID is REQUIRED.
It is how we track a mutation,
much like how CFN tracks a change set.

Fixed bug where UUID is a reserved word in DDB.

Refactored some of the error messages.
Utilize Java Example to demonstrate resume and restart.
Finally, addressed some of the feedback on PR #854.

feat(Mutations): Idempotent Resume (#854)

Refactor Storage:
- Rename Mutation Lock to Mutation Commitment
- Introduce Mutation Index to describe what items of a Branch Key have been mutated
- Add Input field to Mutation Commitment
- Add Ciphertext field to Mutation Commitment
- When Mutating an item, always write with an optimistic lock
- Allow Initialize Mutation to over write a Version, instead of only creating a version
- When Overwriting a Mutation Index, ensure it has not changed
- Whenever writing for Mutation, ensure the Mutation Commitment's ENC is as expected (along with original and terminal)

Refactor Storage to contain operations that:
1. Allow for Atomic Mutations (maybe cut later)
2. Allow for Deleting a Mutation
3. Allow for Creating a Mutation Index

Refactor KeyStoreAdmin:
- Support a System Key for Mutations
- Stub out the System Key
- Logic for handling Mutation Index

Refactor Initialize Mutation:
- If Commitment & Index already exist and match Input, write nothing and return token
- If Commitment already exists and matches input, write index, and return token
- If Commitment already exists and does not match input, fail
- If no commitment, Initialize Mutation

Refactor Apply Mutation:
- Write an update Page Index.

fix: Dafny intendation formatting

chore: fix Java test examples

chore: more fomratting for CI

feat(Mutations): Native test for Loose access in-flight

feat(Mutations): Example In Flight Mutation Scanner

feat(Mutations-TODO): Some Terminal KMS Exceptions (#795)

If the KMS Call, for mutating the Beacon, fails,
it MAY indicate the MPL Consumer does not have access to the
terminal KMS Key.

If the KMS call for verifying a terminal version fails,
it MAY indicate the MPL Consumer does not have access to the
terminal KMS Key.

Also fix some Dafny tests failing verification.

feat(KS+): More modeled errors (#754)

* refactor(Storage): Use TransactGet instead of BatchGet for GetInitMut (#753)

This resolves feedback from both @seebees  and @josecorella
on Mutations branch.

* chore(Mutations): address #754\#discussion_r1775676091

#754 (comment)

* chore(Mutations): Address feedback from #750

See #750

* chore(Mutations): address feedback on #742

See #742

refactor(Storage): Use TransactGet instead of BatchGet for GetInitMut (#753)

This resolves feedback from both @seebees  and @josecorella
on Mutations branch.

Verification failure is due to (just like in #751 ):
1. Key Store Admin's Index.dfy not proving Fresh, which has been a long standing issue with the Admin
2. In `AwsCryptographyKeyStore/test/Storage/TestGetItemsForInitializeMutation.dfy`, the test assumes `type` is in the Encryption Context. It is, but Structure.dfy does not prove that, so it must be proven else where.

A .NET MPL job failed due to .NET 48 Sig V4 Auth bug.

test(Mutations): additional testing for Mutations

feat(Mutations): more clean up

feat(Mutations): log statements for ApplyMutation

fix(Storage): typo

fix(Storage): ensure KmsArn is valid

chore(Mutations): respond to comments on PR #720

test(GHW): Run Java Examples for PR CI (#749)

chore(Java): Examples for Mutations (#742)

chore(Mutations): comment out non-GA Mutations (#750)

Crypto Tools, at this time, intends to release Branch Key Mutations
without some operations useful for recovering a dropped Mutation Token
or dealing with the disagreement of a Mutation Token and a Mutation Lock.

Additionally,
we intend to release the Key Store Admin with only support for
one Key Management Strategy.

All checks are green except for Verification.
Verification is failing for the Key Store Admin's Index.dfy.

Verification for the Key Store Admin's Index.dfy
has been failing for a long time.

feat: Mutations BETA (#720)

Beta build of Mutations with several substantial gaps
texastony added a commit that referenced this pull request Nov 20, 2024
Explicitly:
- Change InitializeMutationFlag from a union to an enum for ToString reasons
- Model `DoNotVersion` flag for Initialize Mutation
- Refactor Describe Mutation output to detail Input so resume can be done
- Refactor System Key to be optional, detailing that TrustStorage is the default
- More errors
- Smithy changes from PR feedback on #854
- Correction of spelling mistakes
- Mutation Token's UUID is required

Why change the flag to an enum?

Dafny/Smithy-Dafny's support for Union's results in structures that do not print well.
The intention of the  `InitializeMutationFlag` is to inform customers
about the result of their request.

Such information may,
possibly even should,
be logged.

Initialize Mutation and Apply Mutation MUST
ensure that the UUID of the Index and Commitment agree.
Apply MUST ensure that the UUID of the Commitment and Token agree.
The Mutation Token's UUID is REQUIRED.
It is how we track a mutation,
much like how CFN tracks a change set.

Fixed bug where UUID is a reserved word in DDB.

Refactored some of the error messages.
Utilize Java Example to demonstrate resume and restart.
Finally, addressed some of the feedback on PR #854.

feat(Mutations): Idempotent Resume (#854)

Refactor Storage:
- Rename Mutation Lock to Mutation Commitment
- Introduce Mutation Index to describe what items of a Branch Key have been mutated
- Add Input field to Mutation Commitment
- Add Ciphertext field to Mutation Commitment
- When Mutating an item, always write with an optimistic lock
- Allow Initialize Mutation to over write a Version, instead of only creating a version
- When Overwriting a Mutation Index, ensure it has not changed
- Whenever writing for Mutation, ensure the Mutation Commitment's ENC is as expected (along with original and terminal)

Refactor Storage to contain operations that:
1. Allow for Atomic Mutations (maybe cut later)
2. Allow for Deleting a Mutation
3. Allow for Creating a Mutation Index

Refactor KeyStoreAdmin:
- Support a System Key for Mutations
- Stub out the System Key
- Logic for handling Mutation Index

Refactor Initialize Mutation:
- If Commitment & Index already exist and match Input, write nothing and return token
- If Commitment already exists and matches input, write index, and return token
- If Commitment already exists and does not match input, fail
- If no commitment, Initialize Mutation

Refactor Apply Mutation:
- Write an update Page Index.

fix: Dafny intendation formatting

chore: fix Java test examples

chore: more fomratting for CI

feat(Mutations): Native test for Loose access in-flight

feat(Mutations): Example In Flight Mutation Scanner

feat(Mutations-TODO): Some Terminal KMS Exceptions (#795)

If the KMS Call, for mutating the Beacon, fails,
it MAY indicate the MPL Consumer does not have access to the
terminal KMS Key.

If the KMS call for verifying a terminal version fails,
it MAY indicate the MPL Consumer does not have access to the
terminal KMS Key.

Also fix some Dafny tests failing verification.

feat(KS+): More modeled errors (#754)

* refactor(Storage): Use TransactGet instead of BatchGet for GetInitMut (#753)

This resolves feedback from both @seebees  and @josecorella
on Mutations branch.

* chore(Mutations): address #754\#discussion_r1775676091

#754 (comment)

* chore(Mutations): Address feedback from #750

See #750

* chore(Mutations): address feedback on #742

See #742

refactor(Storage): Use TransactGet instead of BatchGet for GetInitMut (#753)

This resolves feedback from both @seebees  and @josecorella
on Mutations branch.

Verification failure is due to (just like in #751 ):
1. Key Store Admin's Index.dfy not proving Fresh, which has been a long standing issue with the Admin
2. In `AwsCryptographyKeyStore/test/Storage/TestGetItemsForInitializeMutation.dfy`, the test assumes `type` is in the Encryption Context. It is, but Structure.dfy does not prove that, so it must be proven else where.

A .NET MPL job failed due to .NET 48 Sig V4 Auth bug.

test(Mutations): additional testing for Mutations

feat(Mutations): more clean up

feat(Mutations): log statements for ApplyMutation

fix(Storage): typo

fix(Storage): ensure KmsArn is valid

chore(Mutations): respond to comments on PR #720

test(GHW): Run Java Examples for PR CI (#749)

chore(Java): Examples for Mutations (#742)

chore(Mutations): comment out non-GA Mutations (#750)

Crypto Tools, at this time, intends to release Branch Key Mutations
without some operations useful for recovering a dropped Mutation Token
or dealing with the disagreement of a Mutation Token and a Mutation Lock.

Additionally,
we intend to release the Key Store Admin with only support for
one Key Management Strategy.

All checks are green except for Verification.
Verification is failing for the Key Store Admin's Index.dfy.

Verification for the Key Store Admin's Index.dfy
has been failing for a long time.

feat: Mutations BETA (#720)

Beta build of Mutations with several substantial gaps
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.

2 participants