Drop all container-update overrides on COPY, as that seems more
consistent than selecting just a couple overrides to drop.
Check that all `actual` headers are also `retained_headers` in
test_purge_crypto_sysmeta_headers.
Check that we really did purge the crypto meta in test_GET_success and
test_HEAD_success. GETs were already getting verified over in
test_encrypter_decrypter.py, but they would fail in a less-obvious way.
Change-Id: I7c17fdc02a9895495a1737d4040e868482bb9e98
We do not need to test the contaiher listing etag length before
decrypting - if it has crypto-meta it will be decrypted. The Etag
value in a response to a ranged GET should be the Etag of the whole
object.
Change-Id: Ib713a899b5d65d979d51db36cbca809998e87847
Remove all crypto related (transient-) sysmeta from responses so that
they are not inadvertantly copied to another object. If a COPY is to
an unencrypted destination then the source crypto meta would not apply
and could result in corrupted data when reading the destination.
Also remove container update override headers when copying an object
and the source etag is not trusted (e.g. Range copy or large object
copy).
Drive-by change to stop FakeSwift updating request headers with etag
and content-length that were not in the actual PUT request. That
change was made earlier on this branch to support tests that have now
been deleted.
Change-Id: Ib7cf7676a2f62f79b067f93aa1d2cae64c393fe9
Move some lines in footers_callback. Re-use the
already calculated encrypted-plaintext-etag for container
update override for efficiency rather than re-calculating,
since this is probably the common case.
Drive-by fix for some formatting in test_encrypter.
Change-Id: I2c881e98577a9f2c826b977f766398c29f63e565
Currently the key id saved in X-Object-Sysmeta-Crypto-Id is only set
during a PUT request. The sysmeta cannot be set by a POST request. The
key id value is the path used to derive keys and is currently used by
the keymaster to determine what keys should be for decrypter to use in
the GET path. So if we have an object that was PUT without crypto and
then POSTed to with crypto, we have no X-Object-Sysmeta-Crypto-Id
value to derive keys from and cannot therefore decrypt the POSTed
metadata.
We do not actually need to use X-Object-Sysmeta-Crypto-Id to derive
keys - objects do not change location. So in this patch we stop using
it for key derivation in the GET and HEAD paths and instead just use
the path of the GET/HEAD request.
The key id may prove useful in the future if for example an object
were ever relocated, or a keymaster chose a different key with
different id for a POST vs the original PUT. If that were to happen
then we could use the persisted key id to inform the keymaster as to
which key is required for decryption.
For such future-proofing this patch changes the location for
persisting the key id to the crypto_meta dicts for each encrypted
item, and no longer uses the X-Object-Sysmeta-Crypto-Id header. That
way, if ever a different key id were used by a keymaster for a POST vs a
PUT then we'd have the right value stored with the metadata
crypto-meta vs the data crypto-meta.
To enable that, the keymaster now includes the key id in the dict of
results returned from fetch_crypto_keys, so that the encrypter can
embed the key id in crypto meta. The key id is also changed to be a
dict that contains the key derivation path and also a version number
for the keymaster. This is purely for future-proofing - we now persist
sufficient information in crypto-meta to determine which keymaster
version was used and how it derived the keys.
This changes also allows some simplification of the keymaster, and now
the keymaster only calculates keys when they are asked for by a call
to fetch_keys.
In addition, the keymaster will never set the 'swift.crypto.override'
flag anymore. There are still encrypter and decrypter unit tests to
handle the case where somebody uses such a keymaster, but this one
will not make use of that flag.
Change-Id: Icb368305a15e1bbe32483f2e2bbb98a1441a4dad
Added content-disposition header to HEAD tempurl request.
As per HTTP docs[1] HEAD response must be identical to GET
except return message-body response.
[1]https://tools.ietf.org/html/rfc2616#section-9.4
Change-Id: Ie60a6fb632613055da5279db5b128ce5ee5172ae
Closes-Bug:#1539805
Every time we call start_server, check is True.
Every time we call check_server, we use the default timeout.
Change-Id: Id38182f15bcbfbb145b57cee179a8fd47ec8e2b7
Make it a requirement that root_encryption_secret is
a minimum of 44 base64 encoded characters i.e. a minimum
of 32 bytes encoded to base 64.
This patch still has a default root_secret in the proxy
config. This is just as temporary as the proxy config
having encryption middleware in the pipeline. Without this,
functests would fail since devstack has no root secret defined.
Change-Id: I82d183f0b89bfd730578bb64623928bcbfaf657c
adds a test for other middlewares setting override headers,
verifying that container listing is correctly updated.
Drive-by fix to a doc string, and adding etag to test PUT requests.
Change-Id: Id096bd5bece339e2bcd32f4c545fb3aa7aa2b659
...and move crypto_utils.py to swift/common/middleware
Also delete unused method and remove some unnecessary
mocking from test_decrypter.py
Change-Id: Ia4a2699db53eb4753c7f73db18fc86c84535b344
The version part is NOT included in the hash path for an object,
and should similarly not be included in the path used for a
derived IV, so that if/when the API version changes,
the derived IV would not change.
Change-Id: Idc527f9f056adb5b3c8c01135bb993b05b2c242b
If you have 2 swift regions served by the same keystone,
then the client cannot get the correct URL for the swift endpoint
without specifying a region_name.
Closes-Bug: 1587088
Change-Id: Iaab883386e125c3ca6b9554389e63df17267a135