Hi Adam, I can follow your reasoning. And it seems reasonable. But I would like to suggest to you to create a JIRA for this where patches are uploaded and can be tested in a separate ofbiz instantiation. This would then help with the creation of implementation procedures and documentation prior to uploading it to trunk.
Regards, Pierre Op 20 april 2012 16:41 schreef Adam Heath <doo...@brainfood.com> het volgende: > On 04/20/2012 12:53 AM, Pierre Smits wrote: > >> Hi Adam, >> >> How would that be? That would be one per tenant in a multi-tenant setup? I >> can imagine in a multi-tenant setup with the db backend not on derby (as >> we >> all recommend) the upgrade/migration aspect can be enormous. Even more so >> in a HAFO-setup. >> > > Moving EntityKeyStore to a separate database would not be hard, no code > changes at all. Just a new entitygroup mapping, and updating > entityengine.xml(or TenantDataSource) to point it at a different database. > This would then mean running pg_dump(or whatever) would not see the keys. > > I currently have the new crypto storage done. It uses base64 to store the > hashed keyname, the key value, and the encrypted column values scattered > around the database. A random-length(0-15) random-value salt is pre-pended > to each value during encryption, so if you continually set the same value, > you'll get different encrypted values. > > I do not yet have key-encrypting-key(KEK) support working. I'm currently > thinking there would be one 'master' KEK. This is what EntityCrypto would > use by default. In sub-tenant delegators, the sub EntityCrypto would fetch > a key from it's parent delegator. The parent delegator would be using the > master KEK to encode it's keys. The sub-delegator would be using a unique > KEK stored in the base delegator. The base delegator has it's own > EntityCrypto. > > So, the master KEK could be stored in entityengine.xml(base64 encoded, I > can provide a cmdline tool to generate it), or some other file. >
