-
Notifications
You must be signed in to change notification settings - Fork 7
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
Make some keys immutable #65
Comments
Marking for discussion at an architecture call before we move to implementation |
Thoughts: With an immutable key (i.e. immutable=true in the metadata) it would be good to disable edits (i.e. put) but still allow deletion. In addition, require some sort of override/force flag to be set to true when deleting an immutable key. |
Idea: Add a re-authentication step to potentially harmful actions (e.g. mutatating keys that shouldn't be mutated). This would at least likely stop a bug from doing something it shouldn't. |
Picking this up in this sprint as it is required for atsign-foundation/noports#1780 Required PRs in at_libraries (at_commons), at_server (at_persistence_secondary_server, at_secondary_server), at_client_sdk (at_client) and at_protocol (protocol spec) 2SP because I've completed most of it this morning |
Is your feature request related to a problem? Please describe.
Currently it is possible for an authenticated client to make problematic updates. Currently we try to avoid client software doing these problematic things; however we need a mechanism to prevent these updates occurring.
Here are some of the keys whose values should not be permitted to be overwritten
public:publickey@alice
privatekey:at_pkam_publickey
shared_key.bob@alice
Describe the solution you'd like
For
public:publickey@alice
andprivatekey:at_pkam_publickey
we should prevent their value being modified by client updates (i.e. the update verb handler)For
shared_key.bob@alice
we should also prevent the value being modified by client updates.We should allow metadata to be updated. TBD whether there is some metadata which we should prevent being updated
Describe alternatives you've considered
As the concept of limiting updates to data after its initial creation may have broader applicability, we could introduce a new metadata field, 'immutable', which defaults to false
However we could also just start by putting guards around the three keys named above.
Additional context
No response
The text was updated successfully, but these errors were encountered: