You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 16, 2023. It is now read-only.
Right now, it's easy to see that even sensitive data is being stored in an insecure way though sqlite. We haven't really come to a conclusion on how we're going to fix something like that. It's more secure than typing your password into a shareable notebook, but it's just about as secure as saving your passwords in a file on your machine.
we were thinking of adding a -s flag when setting a parameter, and encrypting the db, but that would also make it difficult to share scenes.
We were thinking of encrypting with gpg, to allow people to share public keys and access encrypted sqlite dbs.
The text was updated successfully, but these errors were encountered:
one possibility that could make scene sharing easier if we take the encryption route: we could add a "share scene" feature (or some equivalent that avoids "ss"), where a copy of the scene is decrypted except for secret-marked parameters, which are deleted ?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Right now, it's easy to see that even sensitive data is being stored in an insecure way though sqlite. We haven't really come to a conclusion on how we're going to fix something like that. It's more secure than typing your password into a shareable notebook, but it's just about as secure as saving your passwords in a file on your machine.
we were thinking of adding a -s flag when setting a parameter, and encrypting the db, but that would also make it difficult to share scenes.
We were thinking of encrypting with gpg, to allow people to share public keys and access encrypted sqlite dbs.
The text was updated successfully, but these errors were encountered: