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 - 22:31:27 EST