janisslsmandcodex
28826af88d
Use SQLite for persistence and generate Rust protobuf bindings at build time. Add Docker image support for containerized deployment. Co-Authored-By: codex <[email protected]>
37 lines
1.3 KiB
Protocol Buffer
37 lines
1.3 KiB
Protocol Buffer
// Copyright 2012 The Chromium Authors
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
// found in the LICENSE file.
|
|
//
|
|
// Common sync protocol for encrypted data.
|
|
|
|
// If you change or add any fields in this file, update proto_visitors.h and
|
|
// potentially proto_enum_conversions.{h, cc}.
|
|
|
|
syntax = "proto2";
|
|
|
|
option go_package = "./sync_pb";
|
|
|
|
option java_multiple_files = true;
|
|
option java_package = "org.chromium.components.sync.protocol";
|
|
|
|
option optimize_for = LITE_RUNTIME;
|
|
|
|
package sync_pb;
|
|
|
|
// Encrypted sync data consists of two parts: a key name and a blob. Key name is
|
|
// the name of the key that was used to encrypt blob and blob is encrypted data
|
|
// itself.
|
|
//
|
|
// The reason we need to keep track of the key name is that a sync user can
|
|
// change their passphrase (and thus their encryption key) at any time. When
|
|
// that happens, we make a best effort to reencrypt all nodes with the new
|
|
// passphrase, but since we don't have transactions on the server-side, we
|
|
// cannot guarantee that every node will be reencrypted. As a workaround, we
|
|
// keep track of all keys, assign each key a name (by using that key to encrypt
|
|
// a well known string) and keep track of which key was used to encrypt each
|
|
// node.
|
|
message EncryptedData {
|
|
optional string key_name = 1;
|
|
optional string blob = 2; // base64-encoded.
|
|
}
|