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 <mkienen..mail.com> 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 genera..ncubator.apache.org if you
> want to read it.
>
>
> On 2/21/07, Roy T. Fielding <fieldin..biv.com> 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.
>
This archive was generated by hypermail 2.0.0 : Wed Feb 21 2007 - 22:17:21 EST