refactor dojox.sql

[Adam Peller]

Filed new ticket for the dojox.storage dependency (see #8765)

Once that is taken care of, if only dojox.off depends on dojox.sql, I suggest we pull the code into the off subproject, since it does not seem to merit a standalone subproject nor is it drawing any activity or contributions.

[Adam Peller]

and if there's a CLA in place, do we really need a LICENSE file?

[Adam Peller]

(In [15313]) attempt at a README for dojox.sql. Refs #7704

[Adam Peller]

and shouldn't the crypto code live in dojox.encoding with Dojo's other crypto code?

[Adam Peller]

per discussion with brad and ttrenka, it looks like we should move the crypto code to dojox.encoding, remove the dojox.storage dependency on dojox.sql, and move the remaining module into dojox.off.

[dante]

lets give dojox some structure for 1.4 preparing for a breakout of cycle.

[Tom Trenka]

So in working on other AES implementations, I noticed that the implementation in dojox.sql will, in general, only work for itself; it uses a nonce for an initialization vector and includes that (with a "-" delimiter for ciphertext blocks) along with the ciphertext.

The problem with this is that it's highly non-standard (though a suggested security fix), and that means it will not play well with other implementations of AES. In addition, since there may or may not be existing local storages that already contain encrypted text based on this code, we really can't remove it or alter it at all.

Because of that, I'm closing out this ticket as "wontfix" :(

[Tom Trenka]

Sorry Adam...don't think we're coming back to this, and I doubt it will be included in the 2.x line of DTK. Reclosing as "wontfix".