Skip to content

Attempt to modify a remote vault throws an error instead of creating a clone #365

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

Open
aryanjassal opened this issue Feb 3, 2025 · 5 comments
Assignees
Labels
bug Something isn't working

Comments

@aryanjassal
Copy link
Member

Describe the bug

Polykey's design disallows modification of remote vaults. The intended usage in this case is to clone the vault, then modify it with the relevant secrets. This way, both vaults will maintain their separate histories and not interfere with each other. However, this is not the current behaviour. If the vault is a remote vault, then any modification operation will throw an error and exit the command instead of creating a clone.

To Reproduce

  1. Create a vault on N1
  2. Pull the vault on N2
  3. Attempt to modify the vault contents on N2
  4. Observe error

Expected behavior

The vault should create a clone of itself and perform the changes in the cloned vault instead.

Additional context

Notify maintainers

@aryanjassal

@aryanjassal aryanjassal added the bug Something isn't working label Feb 3, 2025
@aryanjassal aryanjassal self-assigned this Feb 3, 2025
Copy link

linear bot commented Feb 3, 2025

ENG-524

@aryanjassal
Copy link
Member Author

The authority of modifying the vault shouldn't belong to a single node, but should belong to a gestalt. I have not tested this behaviour, but in @CMCDragonkai's experience, only the node which created the vault has authority to write secrets. The authority should be granted to all nodes within a gestalt without the need to fork the vault to modify its contents instead.

@CMCDragonkai
Copy link
Member

No we don't want all nodes to be able to write to the vault. At any moment in time, any of the nodes can take the write lock of the vault. But that means it has to broadcast that across to the rest of the nodes in the gestalt as part of gestalt synchronisation. We need the gossip-like protocol to repeat for nodes that are temporarily offline.

@aryanjassal
Copy link
Member Author

How will we create a gossip-like protocol for this when we are using a decentralised system? Apps like whatsapp can temporarily buffer messages on their server until it is received. How can we do that? A gestalt might go completely offline at a point, so we cannot rely on other nodes in a gestalt storing this 'gossip' for buffering.

@CMCDragonkai
Copy link
Member

How will we create a gossip-like protocol for this when we are using a decentralised system? Apps like whatsapp can temporarily buffer messages on their server until it is received. How can we do that? A gestalt might go completely offline at a point, so we cannot rely on other nodes in a gestalt storing this 'gossip' for buffering.

Let's ignore the case of an entire gestalt going offline. Gossip is for config sync. And technically it's not entirely fully consistent. We actually need a sort of inbetween that ensures complete consistency for online only nodes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Development

No branches or pull requests

2 participants