Here are my thoughts ... Cayenne 3.0 Modeler doesn't support encryption out-of-the-box. It only provides hooks which an end-user can use (and I did this in my own test cases, which are NOT included in Subversion) in their own code to enable themselves to handle an encrypted database password (not encryption between Cayenne and the database, although i suppose something else could supply that).
So again, Cayenne Modeler does NOT provide encryption in the download from Apache and there are NO encryption (OpenSSL/etc) jars checked into Subversion (at least by me). The options provided in the base Cayenne Modeler are for the database password to be in plain text (old way), ROT-13, or ROT-47. ROT-13 and ROT-47 are not real encryption algorithms controlled by export laws. They are simple Caesar ciphers -- simple rotation algorithms and are easily broken, even by hand using a sheet of paper. I know 6-year olds that like to use ROT-13 -- it is great fun to them! :-) I hopefully documented the code and algorithms fairly clearly (it is all source code, no jars). I also include links to the Wikipedia documenting how they work. The inclusion of ROT-13 and ROT-47 is because they are simple obfuscators, they give an example to look at for maybe writing your own more powerful encoder, and might even be useful to someone in a less strict environment -- could use ROT-13/ROT-47 to obfuscate a password so if someone who didn't know the database password had a casual glance at it, they most likely wouldn't remember it later to decipher it (using a sheet of paper, the Unix commands which can do it, a 3rd party tool, or even the Cayenne main() test cases in each encoder). So, in my opinion, we aren't providing encryption. We are providing a hook for an end-user (like me) to add to the product (Cayenne) the ability to have a strongly encrypted database password if their environment (like a financial firm) requires it, but we (Apache/Cayenne) aren't giving them real encryption in the Apache/Cayenne source code or including jars which support export-controlled encryption. If someone needs stronger database password encryption, they'll have to add that code themselves in their own project. Other thoughts on this are more than welcome, of course. :-) Thanks, /dev/mrg (Yes, I should probably update wiki page i put together a while back ...) On 2/21/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
An FYI on one person's feelings about putting jars into svn, and consequences if those jars contain 5D002 software. Also, if we are now supporting encryption functionality in the modeler, we need to get listed on http://www.apache.org/licenses/exports/ by following the processes outlined at http://www.apache.org/dev/crypto.html There's a lot more detailed info on this topic in the "podling BIS notifications" thread running on [email protected] if you want to read it. On 2/21/07, Roy T. Fielding <[EMAIL PROTECTED]> wrote: > Note, however, that if anyone commits something like the OpenSSL > or Bouncy Castle source code and/or binaries, which are products > in and of themselves, to the subversion instance, then the PMC > must file an export notice for the subversion area even if no ASF > product has been released yet. That is because distributing > third-party products from a public web server is the same as > exporting them. Personally, I think it is wrong for projects to > commit code to subversion unless it is intended to be maintained > as source, but I know that some "real" projects at the ASF are too > lazy to write build scripts and instead use our subversion instance > as a binary distribution medium.
