I created a Cayenne-specific PasswordEncoding interface. There are no
hooks into any existing cryptography package. No automatic linkage of
any kind -- you can't drop OpenSSL/etc into the mix and tell Cayenne
to automatically use it.
The end-user must write there own class that implements the
encodePassword() and decodePasswrod() methods and those methods can do
whatever the end-user wants (reverse the text, change all the case,
strong encryption, whatever). They'll have to enter their custom
encoder class name into Cayenne Modeler and make sure their encoder
class is in the CLASSPATH and then Cayenne will instantiate it to
obtain the decoded password to use to connect to the database.
Encoders can be pretty simple. For plain text passwords, decoding is done by:
public String decodePassword(String encodedPassword, String salt)
{
return encodedPassword;
}
Encoding the password is equally trivial.
I really don't see this as requiring any extra documentation/etc. If
so, just about anything at Apache would require it. I could certainly
write a task for Ant that did encryption. Then Ant would call my
custom task and it uses encryption. Does the fact that Ant allows me
to augment the product require them to do the BIS notification?
Thanks,
/dev/mrg
On 2/21/07, Jean T. Anderson <jt..ristowhill.com> wrote:
> Derby followed a similar path: it doesn't provide encryption, doesn't
> include the jce, just provides hooks to use the jce. But those hooks
> that enable encryption required the BIS notification for just the Apache
> Derby product.
>
> In the case of OpenSSL, that's the "If my project ships a binary that
> provides bindings to OpenSSL, but does not include its source or
> binaries, what notifications must be made?" faq [1]. In this case, the
> BIS notification is required for just the Apache product (don't have to
> also include OpenSSL in the notification).
>
> -jean
>
> [1] http://www.apache.org/dev/crypto.html#faq
>
> Michael Gentry wrote:
> > 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 - 23:35:59 EST