1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
//! Issuer contract and values for presigned direct transfers, in both
//! directions: the create-only writes `direct_put` authorizes, and the
//! reads `direct_get` authorizes.
use crateResult;
use ;
use BTreeMap;
use ;
/// Describes one immutable create-only write to authorize for a client.
/// Describes one read of an existing content object to authorize for a client.
///
/// There is nothing to bind but the key. A write has to carry the digest
/// and the create-only precondition into the signature because the bytes do
/// not exist yet and the provider is the only party that can refuse them; a
/// read is of bytes this deployment already verified, and the reader checks
/// what arrives against the reference it was handed.
/// Describes one part of an open multipart upload to authorize for a client.
/// Carries a short-lived HTTP capability and every request header covered by its signature.
/// Issues short-lived transfer capabilities in both directions, and in
/// doing so carries the write-time enforcement contract the rest of the
/// system leans on:
///
/// - The signed request must make the provider verify that the uploaded
/// body hashes to the content ref's digest and reject anything else
/// (S3-family: a signed `x-amz-checksum-sha256` header).
/// - The signed request must be create-only, so an existing object is never
/// replaced through a transfer capability (S3-family: a signed
/// `if-none-match: *` header).
/// - Both requirements ride the signature: a client cannot drop or alter
/// them without invalidating the capability.
///
/// Because every issuer guarantees this, `direct_put` completion proves an
/// upload by existence and size alone — it never reads content back. A
/// provider that cannot enforce digest verification and create-only
/// preconditions in a presigned request must not implement this trait; the
/// deployment then reports `direct_put` as unsupported instead of falling
/// back to weaker verification.
///
/// Reads ride the same trait for a plainer reason: a deployment that lets a
/// client write an object directly must be able to hand that object back,
/// and it can only do that where it can sign a read of it. So the two
/// directions are offered together or not at all, and a store with no
/// issuer proxies both.