)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"63c48543a5c443b89a9ac0ed3346542c9c85a941","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"By default, disallow inbound X-Timestamp headers"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"With the X-Timestamp validation added in commit e619411, end users"},{"line_number":10,"context_line":"could upload objects with"},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    X-Timestamp: 9999999999.99999_ffffffffffffffff"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3a57f1b5_0fc70697","line":9,"updated":"2016-02-11 20:56:08.000000000","message":"so this exposure and risk of x-timestamp is somehow a new behavior or regression?  I though offset was reserved somehow internally - maybe we call *normalize* timestamp somewhere coming in?  I could be wrong...\n\nand I guess I am!\n\n    vagrant@saio:~$ swift upload test test -H \u0027x-timestamp: 1554981707.26651_000000000000000f\u0027\n    test\n    vagrant@saio:~$ find /srv/node*/sdb*/object* -name \\*.data\n    /srv/node1/sdb1/objects/645/35a/a161102fba1710ef912af194b8d4635a/1554981707.26651_000000000000000f.data\n\n^ yeah so is that new?  hrmm... doesn\u0027t look like it (tested on 2.4.0)","commit_id":"cc74d829a668ae95144e69cc551e9519f147ce68"},{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"0d91f2140b59664f2f19f2dca1373c0b732d743e","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"By default, disallow inbound X-Timestamp headers"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"With the X-Timestamp validation added in commit e619411, end users"},{"line_number":10,"context_line":"could upload objects with"},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    X-Timestamp: 9999999999.99999_ffffffffffffffff"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3a57f1b5_e5c3a955","line":9,"in_reply_to":"3a57f1b5_0aea94db","updated":"2016-02-11 21:43:01.000000000","message":"oic so we have sorta moved the risk from the realm of uncertainty to something that\u0027s more qualifiable.  Love it.  No time like the x-present for some value of \"now\"","commit_id":"cc74d829a668ae95144e69cc551e9519f147ce68"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"eba8683569a1af7eff66e5d932c237177f3b5206","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"By default, disallow inbound X-Timestamp headers"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"With the X-Timestamp validation added in commit e619411, end users"},{"line_number":10,"context_line":"could upload objects with"},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    X-Timestamp: 9999999999.99999_ffffffffffffffff"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3a57f1b5_0aea94db","line":9,"in_reply_to":"3a57f1b5_0fc70697","updated":"2016-02-11 21:11:36.000000000","message":"Even before, you could issue requests with far-future x-timestamps that would make trying to deal with that data difficult.\n\nThe complete inability to address such issues is new, however. Previously, you could push x-timestamp out to 1e11 (or higher); it just wasn\u0027t clear how well Swift would behave.","commit_id":"cc74d829a668ae95144e69cc551e9519f147ce68"},{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"63c48543a5c443b89a9ac0ed3346542c9c85a941","unresolved":false,"context_lines":[{"line_number":11,"context_line":""},{"line_number":12,"context_line":"    X-Timestamp: 9999999999.99999_ffffffffffffffff"},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"(the maximum value) and Swift would be unable to delete them."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"The primary reason to allow X-Timestamp before was to prevent"},{"line_number":17,"context_line":"Last-Modified changes for objects coming from either:"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3a57f1b5_2fdd226f","line":14,"updated":"2016-02-11 20:56:08.000000000","message":"boom!  there\u0027s your WORM storage policy support right there!  Hadn\u0027t even thought of that use case!","commit_id":"cc74d829a668ae95144e69cc551e9519f147ce68"},{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"63c48543a5c443b89a9ac0ed3346542c9c85a941","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Last-Modified changes for objects coming from either:"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"  * container_sync or"},{"line_number":20,"context_line":"  * a migration from another storage system."},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"To enable the former use-case, a new X-Container-Sync-Timestamp header"},{"line_number":23,"context_line":"is added. The container-sync daemon will emit both headers, allowing"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3a57f1b5_afc11256","line":20,"updated":"2016-02-11 20:56:08.000000000","message":"there\u0027s a third use-case that basically amounts to optimistic locking - i\u0027ve used it before on the client side to do some interesting-ish things when i worked on block storage backups/dedupe.","commit_id":"cc74d829a668ae95144e69cc551e9519f147ce68"},{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"63c48543a5c443b89a9ac0ed3346542c9c85a941","unresolved":false,"context_lines":[{"line_number":28,"context_line":""},{"line_number":29,"context_line":"    # disallow_inbound_x_timestamp \u003d true"},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"To enable the latter use-case, set this to false."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"Change-Id: I8799d5eb2ae9d795ba358bb422f69c70ee8ebd2c"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3a57f1b5_eff70a57","line":31,"updated":"2016-02-11 20:56:08.000000000","message":"....sure would be nice if there was a middle ground\n\nWhat if we limit x-timestamp to just some tolerable variance between \"now\" and \"a while ago\"?\n\nOr if we really just want to take x-timestamp away from clients in general (seems reasonable to me!) maybe we could provide some means to authorize it on a per-request basis - some role like reseller_admin might work; of something with the admin key that we use for /info?  or something new?  dunno.","commit_id":"cc74d829a668ae95144e69cc551e9519f147ce68"},{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"0d91f2140b59664f2f19f2dca1373c0b732d743e","unresolved":false,"context_lines":[{"line_number":28,"context_line":""},{"line_number":29,"context_line":"    # disallow_inbound_x_timestamp \u003d true"},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"To enable the latter use-case, set this to false."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"Change-Id: I8799d5eb2ae9d795ba358bb422f69c70ee8ebd2c"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3a57f1b5_a5c13156","line":31,"in_reply_to":"3a57f1b5_aaf020ff","updated":"2016-02-11 21:43:01.000000000","message":"I don\u0027t think you should be able to do things *now* (like real now) that change behaviors in the *far* future.  Server\u0027s return \"date\" headers - I think we could constrain the forward time to minutes (unless there\u0027s bs x-timestamp in the data already).\n\nGoing backwards it depends on the use-case - migrating data from old swift clusters might have x-timestamps that are many years old; perhaps that one is configurable if the clients co-ordinate with the cluster it might be reasonable to loose some history with some means to preserve the metadata in a different form on really old stuff sort of like importing a svn repo into a new git repository or something... again dunno ~*~magic~*~","commit_id":"cc74d829a668ae95144e69cc551e9519f147ce68"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"eba8683569a1af7eff66e5d932c237177f3b5206","unresolved":false,"context_lines":[{"line_number":28,"context_line":""},{"line_number":29,"context_line":"    # disallow_inbound_x_timestamp \u003d true"},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"To enable the latter use-case, set this to false."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"Change-Id: I8799d5eb2ae9d795ba358bb422f69c70ee8ebd2c"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3a57f1b5_aaf020ff","line":31,"in_reply_to":"3a57f1b5_eff70a57","updated":"2016-02-11 21:11:36.000000000","message":"\"A while ago\" or \"a while from now\"? Really, both ought to be constrained.\n\nWhat would be a \"reasonable\" amount of clock skew to allow? I was hoping for days; John seemed to be thinking more like decades.\n\nWhat about just turning on x-timestamp for a particular proxy (similar to what some deployments do with allow_account_management)?","commit_id":"cc74d829a668ae95144e69cc551e9519f147ce68"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"37f61dc9ec309bf95222afa50662c781a14e24d7","unresolved":false,"context_lines":[{"line_number":21,"context_line":""},{"line_number":22,"context_line":"To enable the former use-case, a new X-Container-Sync-Timestamp header"},{"line_number":23,"context_line":"is added. The container-sync daemon will emit both headers, allowing"},{"line_number":24,"context_line":"timestamps to be set for both new and old clusters. Eventaully, we"},{"line_number":25,"context_line":"should remove support for sending raw X-Timestamp headers."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Additionally, a new option is added to the gatekeeper filter config:"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3a57f1b5_5ea83977","line":24,"updated":"2016-02-12 09:51:44.000000000","message":"typo: Eventaully","commit_id":"db73eb3b2fbdc18854ff8b3e90edaf83dd032d83"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"b6e997720e4c91928bf4a7ff40f33d17fd2afeeb","unresolved":false,"context_lines":[{"line_number":21,"context_line":""},{"line_number":22,"context_line":"To enable the former use-case, a new X-Container-Sync-Timestamp header"},{"line_number":23,"context_line":"is added. The container-sync daemon will emit both headers, allowing"},{"line_number":24,"context_line":"timestamps to be set for both new and old clusters. Eventaully, we"},{"line_number":25,"context_line":"should remove support for sending raw X-Timestamp headers."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Additionally, a new option is added to the gatekeeper filter config:"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"bae84128_83ee6a20","line":24,"in_reply_to":"3a57f1b5_5ea83977","updated":"2016-02-20 08:05:04.000000000","message":"Now moot, but thanks.","commit_id":"db73eb3b2fbdc18854ff8b3e90edaf83dd032d83"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"37f61dc9ec309bf95222afa50662c781a14e24d7","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  * set `disallow_inbound_x_timestamp \u003d false` for the chosen cluster,"},{"line_number":46,"context_line":"  * upgrade the first cluster,"},{"line_number":47,"context_line":"  * upgrade the second cluster, and finally"},{"line_number":48,"context_line":"  * set `disallow_inbound_x_timestamp \u003d true` for the first cluster."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"If syncing is within a single cluster:"},{"line_number":51,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"3a57f1b5_c1f0ccff","line":48,"updated":"2016-02-12 09:51:44.000000000","message":"I\u0027d like wider discussion of these upgrade impacts before this lands, because this implies single operator has control over both clusters, or requires process coordination across two administrative domains.\n\nIf I understand it, this could mean that operator A cannot complete upgrade of their cluster (set `disallow_inbound_x_timestamp \u003d true`) until operator B (different organisation, different OpenStack distro, different upgrade schedule) upgrades.","commit_id":"db73eb3b2fbdc18854ff8b3e90edaf83dd032d83"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"b6e997720e4c91928bf4a7ff40f33d17fd2afeeb","unresolved":false,"context_lines":[{"line_number":45,"context_line":"  * set `disallow_inbound_x_timestamp \u003d false` for the chosen cluster,"},{"line_number":46,"context_line":"  * upgrade the first cluster,"},{"line_number":47,"context_line":"  * upgrade the second cluster, and finally"},{"line_number":48,"context_line":"  * set `disallow_inbound_x_timestamp \u003d true` for the first cluster."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"If syncing is within a single cluster:"},{"line_number":51,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"bae84128_83d5ca44","line":48,"in_reply_to":"3a57f1b5_c1f0ccff","updated":"2016-02-20 08:05:04.000000000","message":"Upgrade impact should now be much more tolerable.","commit_id":"db73eb3b2fbdc18854ff8b3e90edaf83dd032d83"}],"swift/common/middleware/container_sync.py":[{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"07b1cdb7cf258263f3622484251d316ff58eb89d","unresolved":false,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"    @wsgify"},{"line_number":69,"context_line":"    def __call__(self, req):"},{"line_number":70,"context_line":"        if not self.allow_full_urls:"},{"line_number":71,"context_line":"            sync_to \u003d req.headers.get(\u0027x-container-sync-to\u0027)"},{"line_number":72,"context_line":"            if sync_to and not sync_to.startswith(\u0027//\u0027):"},{"line_number":73,"context_line":"                raise HTTPBadRequest("}],"source_content_type":"text/x-python","patch_set":1,"id":"3a57f1b5_400dcbe6","line":70,"updated":"2016-02-11 22:12:52.000000000","message":"so this is the old style option that wouldn\u0027t work if x-timestamp was stripped at the gatekeeper - but I think allow_full_urls was left as the default for backwards compat","commit_id":"cc74d829a668ae95144e69cc551e9519f147ce68"},{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"07b1cdb7cf258263f3622484251d316ff58eb89d","unresolved":false,"context_lines":[{"line_number":84,"context_line":"                    \u0027cs:not-3-args\u0027)"},{"line_number":85,"context_line":"            else:"},{"line_number":86,"context_line":"                realm, nonce, sig \u003d auth"},{"line_number":87,"context_line":"                realm_key \u003d self.realms_conf.key(realm)"},{"line_number":88,"context_line":"                realm_key2 \u003d self.realms_conf.key2(realm)"},{"line_number":89,"context_line":"                if not realm_key:"},{"line_number":90,"context_line":"                    req.environ.setdefault(\u0027swift.log_info\u0027, []).append("}],"source_content_type":"text/x-python","patch_set":1,"id":"3a57f1b5_4024eb5e","line":87,"updated":"2016-02-11 22:12:52.000000000","message":"and this key here is a shared secret between co-ordinating clusters that is used to validate the signature on the request and would not be known to the end-user who setup the clusters to sync.  But it\u0027s only used for realms style requests - not old-style full urls","commit_id":"cc74d829a668ae95144e69cc551e9519f147ce68"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"37f61dc9ec309bf95222afa50662c781a14e24d7","unresolved":false,"context_lines":[{"line_number":100,"context_line":"                        # bare x-timestamp headers get dropped by gatekeeper"},{"line_number":101,"context_line":"                        if \u0027x-container-sync-timestamp\u0027 in req.headers:"},{"line_number":102,"context_line":"                            req.headers[\u0027x-timestamp\u0027] \u003d req.headers.pop("},{"line_number":103,"context_line":"                                \u0027x-container-sync-timestamp\u0027)"},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"                        expected \u003d self.realms_conf.get_sig("},{"line_number":106,"context_line":"                            req.method, req.path,"}],"source_content_type":"text/x-python","patch_set":2,"id":"3a57f1b5_6c8b0f69","line":103,"updated":"2016-02-12 09:51:44.000000000","message":"I guess my suggestion amounts to:\n\n  # x-timestamp headers get moved somewhere harmless by the gatekeeper\n  if \u0027x-backend-inbound-timestamp\u0027 in req.headers:\n      req.headers[\u0027x-timestamp\u0027] \u003d req.headers(\u0027x-backend-inbound-timestamp\u0027)","commit_id":"db73eb3b2fbdc18854ff8b3e90edaf83dd032d83"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"b6e997720e4c91928bf4a7ff40f33d17fd2afeeb","unresolved":false,"context_lines":[{"line_number":100,"context_line":"                        # bare x-timestamp headers get dropped by gatekeeper"},{"line_number":101,"context_line":"                        if \u0027x-container-sync-timestamp\u0027 in req.headers:"},{"line_number":102,"context_line":"                            req.headers[\u0027x-timestamp\u0027] \u003d req.headers.pop("},{"line_number":103,"context_line":"                                \u0027x-container-sync-timestamp\u0027)"},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"                        expected \u003d self.realms_conf.get_sig("},{"line_number":106,"context_line":"                            req.method, req.path,"}],"source_content_type":"text/x-python","patch_set":2,"id":"bae84128_6356c6d3","line":103,"in_reply_to":"3a57f1b5_6c8b0f69","updated":"2016-02-20 08:05:04.000000000","message":"The more I think about this, the more I like it. I think I prefer X-Backend-Inbound-X-Timestamp as it lets us shunt *any* header without fear of conflict, though.","commit_id":"db73eb3b2fbdc18854ff8b3e90edaf83dd032d83"}]}