Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
soledad
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container registry
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
This is an archived project. Repository and other project resources are read-only.
Show more breadcrumbs
leap
soledad
Commits
f770b876
There was a problem fetching the pipeline summary.
Commit
f770b876
authored
6 years ago
by
drebs
Browse files
Options
Downloads
Patches
Plain Diff
Clarify storage secrets use case and backups in documentation
parent
a23d564a
Branches
Branches containing commit
No related tags found
No related merge requests found
Pipeline
#
Changes
1
Pipelines
31
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
docs/reference/storage-secrets.rst
+35
-17
35 additions, 17 deletions
docs/reference/storage-secrets.rst
with
35 additions
and
17 deletions
docs/reference/storage-secrets.rst
+
35
−
17
View file @
f770b876
...
...
@@ -3,13 +3,39 @@
Storage secrets
===============
Soledad randomly generates secrets that are used to derive encryption keys for
protecting all data that is stored in the server and in the local storage.
These secrets are themselves encrypted using a key derived from the user’s
passphrase, and saved locally on disk.
All data stored locally and remotelly is encrypted using "storage secrets".
The encrypted secrets are stored in a local file in the user's in a JSON
structure that looks like this::
Storage secrets are backed up in the provider
---------------------------------------------
Storage secrets are currently backed up in the provider (encrypted with the
user's passphrase) for the case where the user looses or resets her device (see
:ref:`shared-database` for more information). There are plans to make this
feature optional, allowing for less trust in the provider while increasing the
responsibility of the user.
Because of that, whenever Soledad is initialized for the first time, it checks
for existence of storage secrets in local storage. If these are not found, then
it checks if there is an available backup in the provider. These steps are
currently mandatory because Soledad needs to make sure it will have any
previously used secrets in order to encrypt/decrypt previously synchronized
data accordingly. If the device is offline during the first initialization,
Soledad will raise an exception and fail to initialize.
For testing purposes, it is possible to initialize Soledad passing a `None`
value as server url, but offline mode is currently not supported and may lead
to unintended consequences.
If the user looses her passphrase, there is currently no way of recovering her
data.
Format of the secrets file
--------------------------
When created for the first time, storage secrets are themselves encrypted using
a key derived from the user’s passphrase, and saved locally on disk. The
encrypted secrets are stored in a local file in the user's in a JSON structure
that looks like this::
{
'version': 2,
...
...
@@ -23,15 +49,7 @@ structure that looks like this::
}
When a client application first wants to use Soledad, it must provide the
user’s password to unlock the storage secrets. Currently, the storage secrets
are shared among all devices with access to a particular user's Soledad
database.
user’s password to unlock the storage secrets.
The storage secrets are currently backed up in the provider (encrypted with the
user's passphrase) for the case where the user looses or resets her device (see
:ref:`shared-database` for more information). There are plans to make this
feature optional, allowing for less trust in the provider while increasing the
responsibility of the user.
If the user looses her passphrase, there is currently no way of recovering her
data.
Currently, the same storage secrets are shared among all devices with access to
a particular user's Soledad database.
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment