12d50ebb99
What: this change makes sure the count of segments is not encrypted. Why: having the segment count encrypted just makes things hard for no reason - a satellite operator can figure out how many segments an object has by looking at the other segments in the database. but if a user has access but has lost their encryption key, they now can't clean up or delete old segments because they can't know how many there are without just guessing until they get errors. :( Backwards compatibility: clients will still understand old pointers and will still write old pointers. at some point in the future perhaps we can do a migration for remaining old pointers so we can delete the old code. Please describe the tests: covered by existing tests Please describe the performance impact: none
28 lines
579 B
Protocol Buffer
28 lines
579 B
Protocol Buffer
// Copyright (C) 2019 Storj Labs, Inc.
|
|
// See LICENSE for copying information.
|
|
|
|
syntax = "proto3";
|
|
option go_package = "pb";
|
|
|
|
package streams;
|
|
|
|
message SegmentMeta {
|
|
bytes encrypted_key = 1;
|
|
bytes key_nonce = 2;
|
|
}
|
|
|
|
message StreamInfo {
|
|
int64 deprecated_number_of_segments = 1;
|
|
int64 segments_size = 2;
|
|
int64 last_segment_size = 3;
|
|
bytes metadata = 4;
|
|
}
|
|
|
|
message StreamMeta {
|
|
bytes encrypted_stream_info = 1;
|
|
int32 encryption_type = 2;
|
|
int32 encryption_block_size = 3;
|
|
SegmentMeta last_segment_meta = 4;
|
|
int64 number_of_segments = 5;
|
|
}
|