Comment 1 for bug 926048

Revision history for this message
Eamonn O'Toole (eamonn-otoole) wrote : Re: Security issue: character encoding

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-crafted "safe" mode should be mostly compatible with "all". It might be better to not have a "paranoid" mode, in order to encourage data portability.

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.