This is the second of two bugs split-out of bug 903232. From that bug:
"This sounds like an issue that would be triggered in client tools that do not escape characters, not in Swift. Do you confirm ? If yes, then I agree with John that it sounds like an optional additional layer of security rather than a vulnerability in Swift."
I mostly agree that this should be an optional addition to Swift, and that in itself it is not a vulnerability within Swift. However, there are other circumstances where blacklisting certain characters or character ranges may be needed. For example, currently Swift allows any character for the name of an object or container, including control characters such as 0x01. When Swift outputs a container listing in XML it does so as XML 1.0 and prints out the literal character for 0x01 (start of heading). This will break nearly all XML 1.0 parsers because most control characters are not allowed in XML 1.0. See Character Ranges: http://www.w3.org/TR/REC-xml/#charsets In this example the problem isn't caused by the client but rather the output from Swift that will cause the error in the XML parser on the client. Additionally there could also be other ranges that a Swift provider may not wish to support due to back end systems or Python not being able to handler certain Unicode ranges.
From Thierry Carrez:
@Jason: thanks for the precisions. I'd agree that some minimal filtering (including control characters) would be a good default. We could have three settings: "all" (CloudFiles current deployment), "safe" (all but a few problematic characters) and "paranoid" (base64 or something), with default to "safe".
That doesn't really address the migration issue -- though a conservatively-
From John Dickinson:
2) We are also looking in to ways to address the XML response. There are a few options. We'd like to return a 1.0 version but with the 1.1 encoding of characters (like S3, at least the last time we tested it). However, any number of solutions can be provided with middleware on a particular deployment. I do not want to encourage a fracturing of functionality in the codebase that prevents different deployments from working together (eg filtering would prevent HP and Rackspace deployments from using container sync between the clusters). If a particular deployer needs to have specific restrictions, those things should be managed in their own middleware and not included in the swift codebase.