FAQ
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 general@incubator.apache.org if you
want to read it.

On 2/21/07, Roy T. Fielding 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.

Search Discussions

  • Michael Gentry at Feb 22, 2007 at 3:17 am
    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 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 general@incubator.apache.org if you
    want to read it.

    On 2/21/07, Roy T. Fielding 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.
  • Jean T. Anderson at Feb 22, 2007 at 3:31 am
    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 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 general@incubator.apache.org if you
    want to read it.

    On 2/21/07, Roy T. Fielding 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.
  • Michael Gentry at Feb 22, 2007 at 4:35 am
    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 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 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 general@incubator.apache.org if you
    want to read it.

    On 2/21/07, Roy T. Fielding 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.
  • Mike Kienenberger at Feb 22, 2007 at 4:54 am
    My limited understanding is that if you provide an api that enables
    encryption, then your product is subject to export controls. It
    looks like there might be an exception to encryption that only covers
    authentication.

    So it doesn't matter if you provide an actual encryption implemention.
    It only matters that you provide the ability to use encryption. As
    was mentioned earlier, if we start providing derby as a component of
    cayenne, then we are subject to the export regs.
    On 2/21/07, Michael Gentry wrote:
    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 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 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 general@incubator.apache.org if you
    want to read it.

    On 2/21/07, Roy T. Fielding 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.
  • Jean T. Anderson at Feb 22, 2007 at 5:19 am

    Mike Kienenberger wrote:
    ... if we start providing derby as a component of
    cayenne, then we are subject to the export regs.
    I just posted a question to legal-discuss asking if an Apache product
    includes any product listed at http://www.apache.org/licenses/exports/,
    does it need to also do the BIS notification.

    -jean
  • Mike Kienenberger at Feb 22, 2007 at 5:21 am
    Jean,

    Thank you for looking into this. I guess at some point I should join
    legal-discuss, but I already feel I'm overloaded with apache mailing
    lists :-)
    On 2/22/07, Jean T. Anderson wrote:
    Mike Kienenberger wrote:
    ... if we start providing derby as a component of
    cayenne, then we are subject to the export regs.
    I just posted a question to legal-discuss asking if an Apache product
    includes any product listed at http://www.apache.org/licenses/exports/,
    does it need to also do the BIS notification.

    -jean
  • Michael Gentry at Feb 22, 2007 at 1:46 pm
    I certainly don't mind having this cleared by legal and it is a good discussion.

    I've had a bit more sleep and caffeine now and went over to
    http://www.apache.org/dev/crypto.html and just read this bit:

    "The U.S. Government Department of Commerce, Bureau of Industry and
    Security (BIS), has classified this software as Export Commodity
    Control Number (ECCN) 5D002.C.1, which includes information security
    software using or performing cryptographic functions with asymmetric
    algorithms."

    ROT-13 and ROT-47 (the only ones we provide) are symmetrical
    algorithms. To quote the Wikipedia (yeah, I know some people don't
    feel it is definitive about anything):

    "An additional feature of the cipher is that it is symmetrical; that
    is, to undo ROT13, the same algorithm is applied, so the same code can
    be used for encoding and decoding. "

    This still feels like a non-issue to me, but worthy of discussion and
    perhaps feedback from Apache legal. And if anyone really feels ROT-13
    is secure, I know a 6-year old girl with a sheet of paper that can
    hack their system. (She uses it to send "secret" messages to her
    grandmother.) :-)

    Mike K. did raise an interesting point about if Cayenne Modeler starts
    using Derby instead of HSQL, what does that mean for us? Would we
    only need the BIS/etc if we run the preferences DB with encryption (I
    can't imagine we would -- no reason to)?

    Thanks again!

    /dev/mrg

    On 2/22/07, Mike Kienenberger wrote:
    Jean,

    Thank you for looking into this. I guess at some point I should join
    legal-discuss, but I already feel I'm overloaded with apache mailing
    lists :-)
    On 2/22/07, Jean T. Anderson wrote:
    Mike Kienenberger wrote:
    ... if we start providing derby as a component of
    cayenne, then we are subject to the export regs.
    I just posted a question to legal-discuss asking if an Apache product
    includes any product listed at http://www.apache.org/licenses/exports/,
    does it need to also do the BIS notification.

    -jean
  • Jean T. Anderson at Feb 22, 2007 at 3:10 pm
    Michael Gentry wrote:
    ...
    Mike K. did raise an interesting point about if Cayenne Modeler starts
    using Derby instead of HSQL, what does that mean for us? Would we
    only need the BIS/etc if we run the preferences DB with encryption (I
    can't imagine we would -- no reason to)?
    And the word from legal-discuss [1] is any project that includes derby
    (or any other Apache product listed at
    http://www.apache.org/licenses/exports/), must also do the BIS
    notification.

    It doesn't matter if you don't use derby's encryption capability -- the
    capability is still there in the derby jar Cayenne includes.

    fortunately doing the BIS notification itself turns out to actually be
    straight forward -- imho the hard part has been to understand if you
    need to do it or not. The steps to follow are outlined at
    http://www.apache.org/dev/crypto.html.

    -jean


    [1] http://tinyurl.com/yq75r6
    http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200702.mbox/%3cc5e632550702212131g17f051cr724f886bd972cd04@mail.gmail.com%3e
  • Andrus Adamchik at Feb 22, 2007 at 3:21 pm

    On Feb 22, 2007, at 5:09 PM, Jean T. Anderson wrote:

    And the word from legal-discuss [1] is any project that includes derby
    (or any other Apache product listed at
    http://www.apache.org/licenses/exports/), must also do the BIS
    notification.
    and if you are in US, don't forget to write your congressman to do
    something about terminating this bs legislation. Sorry - couldn't
    resist from commenting on this nonsense :-/ Let's all ensure that
    terrorists don't get access to ROT-13!!

    Andrus
  • Jean T. Anderson at Feb 22, 2007 at 4:07 pm

    Andrus Adamchik wrote:
    On Feb 22, 2007, at 5:09 PM, Jean T. Anderson wrote:

    And the word from legal-discuss [1] is any project that includes derby
    (or any other Apache product listed at
    http://www.apache.org/licenses/exports/), must also do the BIS
    notification.
    and if you are in US, don't forget to write your congressman to do
    something about terminating this bs legislation. Sorry - couldn't
    resist from commenting on this nonsense :-/ Let's all ensure that
    terrorists don't get access to ROT-13!!
    :-)

    I need to do more notifications for db subprojects that include derby,
    so I'm about to get the hang of specifically this case. :-) I'll let you
    know what I do, and with any luck streamline it for you.

    -jean
  • Jean T. Anderson at Feb 22, 2007 at 6:40 pm

    Jean T. Anderson wrote:
    Michael Gentry wrote:
    ...
    Mike K. did raise an interesting point about if Cayenne Modeler starts
    using Derby instead of HSQL, what does that mean for us? Would we
    only need the BIS/etc if we run the preferences DB with encryption (I
    can't imagine we would -- no reason to)?
    And the word from legal-discuss [1] is any project that includes derby
    (or any other Apache product listed at
    http://www.apache.org/licenses/exports/), must also do the BIS
    notification.
    and if you only use Derby and don't include source or jars, no
    notification is needed:

    http://tinyurl.com/2qu6eq
    http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200702.mbox/%3cc5e632550702220946i1b5b599cwd1dccfb79436fbae@mail.gmail.com%3e

    -jean

    It doesn't matter if you don't use derby's encryption capability -- the
    capability is still there in the derby jar Cayenne includes.

    fortunately doing the BIS notification itself turns out to actually be
    straight forward -- imho the hard part has been to understand if you
    need to do it or not. The steps to follow are outlined at
    http://www.apache.org/dev/crypto.html.

    -jean


    [1] http://tinyurl.com/yq75r6
    http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200702.mbox/%3cc5e632550702212131g17f051cr724f886bd972cd04@mail.gmail.com%3e
  • Michael Gentry at Feb 27, 2007 at 1:57 pm
    To re-hash -- but not ROT-13 :-) -- this subject again, did someone
    send anything to the legal mailing list? If not, I can subscribe, and
    send the question, along with a link to this thread.

    I did see that Jean said if we switch CM to use Derby instead of HSQL,
    we'll need the BIS, which is kind of interesting, too.

    Maybe when I'm too brain-dead at work today I can get something done
    here. (When having to do 20 pages of documentation for a 1 line
    configuration file change, my brain tends to want to go elsewhere...)

    Thanks,

    /dev/mrg
  • Mike Kienenberger at Feb 27, 2007 at 2:12 pm
    Michael,

    As the person who best understands the scope of what was done, I'd
    recommend you send a message to legal-discuss.
    On 2/27/07, Michael Gentry wrote:
    To re-hash -- but not ROT-13 :-) -- this subject again, did someone
    send anything to the legal mailing list? If not, I can subscribe, and
    send the question, along with a link to this thread.

    I did see that Jean said if we switch CM to use Derby instead of HSQL,
    we'll need the BIS, which is kind of interesting, too.

    Maybe when I'm too brain-dead at work today I can get something done
    here. (When having to do 20 pages of documentation for a 1 line
    configuration file change, my brain tends to want to go elsewhere...)

    Thanks,

    /dev/mrg
  • Jean T. Anderson at Feb 27, 2007 at 3:12 pm

    Michael Gentry wrote:
    To re-hash -- but not ROT-13 :-) -- this subject again, did someone
    send anything to the legal mailing list? If not, I can subscribe, and
    send the question, along with a link to this thread.

    I did see that Jean said if we switch CM to use Derby instead of HSQL,
    we'll need the BIS, which is kind of interesting, too.
    You only need to include derby in the bis notification if you commit
    derby source/jars to the svn repo or include derby source/jars in the
    release. If you just use derby -- instructing users to download and
    install it -- you don't need to include it in the bis notification.

    If you find that you need to include it in the bis notification, I'll be
    happy to help cayenne understand how to do that. It turns out to not be
    much of a big deal, just process to follow.

    -jean
    Maybe when I'm too brain-dead at work today I can get something done
    here. (When having to do 20 pages of documentation for a 1 line
    configuration file change, my brain tends to want to go elsewhere...)

    Thanks,

    /dev/mrg
  • Michael Gentry at Feb 27, 2007 at 3:23 pm
    Well, for Cayenne Modeler to run standalone using Derby (embedded,
    just like we use HSQL), we would need to include the Derby jar.

    Thanks,

    /dev/mrg

    On 2/27/07, Jean T. Anderson wrote:
    Michael Gentry wrote:
    To re-hash -- but not ROT-13 :-) -- this subject again, did someone
    send anything to the legal mailing list? If not, I can subscribe, and
    send the question, along with a link to this thread.

    I did see that Jean said if we switch CM to use Derby instead of HSQL,
    we'll need the BIS, which is kind of interesting, too.
    You only need to include derby in the bis notification if you commit
    derby source/jars to the svn repo or include derby source/jars in the
    release. If you just use derby -- instructing users to download and
    install it -- you don't need to include it in the bis notification.

    If you find that you need to include it in the bis notification, I'll be
    happy to help cayenne understand how to do that. It turns out to not be
    much of a big deal, just process to follow.

    -jean
    Maybe when I'm too brain-dead at work today I can get something done
    here. (When having to do 20 pages of documentation for a 1 line
    configuration file change, my brain tends to want to go elsewhere...)

    Thanks,

    /dev/mrg
  • Jean T. Anderson at Feb 27, 2007 at 3:51 pm

    Michael Gentry wrote:
    Well, for Cayenne Modeler to run standalone using Derby (embedded,
    just like we use HSQL), we would need to include the Derby jar.
    Ok. The bis notification isn't a big deal. I'm happy to help with it.

    -jean
    Thanks,

    /dev/mrg

    On 2/27/07, Jean T. Anderson wrote:

    Michael Gentry wrote:
    To re-hash -- but not ROT-13 :-) -- this subject again, did someone
    send anything to the legal mailing list? If not, I can subscribe, and
    send the question, along with a link to this thread.

    I did see that Jean said if we switch CM to use Derby instead of HSQL,
    we'll need the BIS, which is kind of interesting, too.
    You only need to include derby in the bis notification if you commit
    derby source/jars to the svn repo or include derby source/jars in the
    release. If you just use derby -- instructing users to download and
    install it -- you don't need to include it in the bis notification.

    If you find that you need to include it in the bis notification, I'll be
    happy to help cayenne understand how to do that. It turns out to not be
    much of a big deal, just process to follow.

    -jean
    Maybe when I'm too brain-dead at work today I can get something done
    here. (When having to do 20 pages of documentation for a 1 line
    configuration file change, my brain tends to want to go elsewhere...)

    Thanks,

    /dev/mrg
  • Mike Kienenberger at Feb 22, 2007 at 3:57 pm
    Michael,

    You're still missing the point. It's not the ROT-13 that would cause
    us to have to register. It's an api that allows for plugging in
    arbitrary encryption. However, my suspicion is that we're exempt
    because our "encryption" only deals with authentication.

    On 2/22/07, Michael Gentry wrote:
    I certainly don't mind having this cleared by legal and it is a good discussion.

    I've had a bit more sleep and caffeine now and went over to
    http://www.apache.org/dev/crypto.html and just read this bit:

    "The U.S. Government Department of Commerce, Bureau of Industry and
    Security (BIS), has classified this software as Export Commodity
    Control Number (ECCN) 5D002.C.1, which includes information security
    software using or performing cryptographic functions with asymmetric
    algorithms."

    ROT-13 and ROT-47 (the only ones we provide) are symmetrical
    algorithms. To quote the Wikipedia (yeah, I know some people don't
    feel it is definitive about anything):

    "An additional feature of the cipher is that it is symmetrical; that
    is, to undo ROT13, the same algorithm is applied, so the same code can
    be used for encoding and decoding. "

    This still feels like a non-issue to me, but worthy of discussion and
    perhaps feedback from Apache legal. And if anyone really feels ROT-13
    is secure, I know a 6-year old girl with a sheet of paper that can
    hack their system. (She uses it to send "secret" messages to her
    grandmother.) :-)

    Mike K. did raise an interesting point about if Cayenne Modeler starts
    using Derby instead of HSQL, what does that mean for us? Would we
    only need the BIS/etc if we run the preferences DB with encryption (I
    can't imagine we would -- no reason to)?

    Thanks again!

    /dev/mrg

    On 2/22/07, Mike Kienenberger wrote:
    Jean,

    Thank you for looking into this. I guess at some point I should join
    legal-discuss, but I already feel I'm overloaded with apache mailing
    lists :-)
    On 2/22/07, Jean T. Anderson wrote:
    Mike Kienenberger wrote:
    ... if we start providing derby as a component of
    cayenne, then we are subject to the export regs.
    I just posted a question to legal-discuss asking if an Apache product
    includes any product listed at http://www.apache.org/licenses/exports/,
    does it need to also do the BIS notification.

    -jean
  • Michael Gentry at Feb 22, 2007 at 4:18 pm
    I don't think I'm missing your point (at least I'm trying not to).
    I'm just arguing that if having an extension point in a product in
    which an end-user can write their own code separate of Apache (in our
    case, retrieving the DB password, but really any extension point), in
    which the end-uesr can incorporate encryption -- and thus require the
    BIS/etc, then that opens a huge can of worms for a lot of projects
    (like Ant). Even if you don't provide an extension point, the
    end-user could always unpack the jar, write their own substitute class
    (we provide the source to the classes as a good starting point), and
    put together a new jar that plugs encryption into the framework.

    I think I'm playing devil's advocate a bit on this one and it would
    still be good to get an official ruling from legal. I'm not at all
    opposed to that. However, we aren't providing any automatic hooks
    into any export-controlled cryptographic software. If an end-user
    wants to write their own code that does cryptography, it is up to them
    to obtain that software and legal comply with its restrictions. It
    isn't a ROT-13 question as much as our software is open and free and
    the user can do what they want with it -- I've just made it a tad
    easier to do something they might want and is perfectly legal. Just
    my opinion.

    Thanks,

    /dev/mrg

    On 2/22/07, Mike Kienenberger wrote:
    Michael,

    You're still missing the point. It's not the ROT-13 that would cause
    us to have to register. It's an api that allows for plugging in
    arbitrary encryption. However, my suspicion is that we're exempt
    because our "encryption" only deals with authentication.

    On 2/22/07, Michael Gentry wrote:
    I certainly don't mind having this cleared by legal and it is a good discussion.

    I've had a bit more sleep and caffeine now and went over to
    http://www.apache.org/dev/crypto.html and just read this bit:

    "The U.S. Government Department of Commerce, Bureau of Industry and
    Security (BIS), has classified this software as Export Commodity
    Control Number (ECCN) 5D002.C.1, which includes information security
    software using or performing cryptographic functions with asymmetric
    algorithms."

    ROT-13 and ROT-47 (the only ones we provide) are symmetrical
    algorithms. To quote the Wikipedia (yeah, I know some people don't
    feel it is definitive about anything):

    "An additional feature of the cipher is that it is symmetrical; that
    is, to undo ROT13, the same algorithm is applied, so the same code can
    be used for encoding and decoding. "

    This still feels like a non-issue to me, but worthy of discussion and
    perhaps feedback from Apache legal. And if anyone really feels ROT-13
    is secure, I know a 6-year old girl with a sheet of paper that can
    hack their system. (She uses it to send "secret" messages to her
    grandmother.) :-)

    Mike K. did raise an interesting point about if Cayenne Modeler starts
    using Derby instead of HSQL, what does that mean for us? Would we
    only need the BIS/etc if we run the preferences DB with encryption (I
    can't imagine we would -- no reason to)?

    Thanks again!

    /dev/mrg

    On 2/22/07, Mike Kienenberger wrote:
    Jean,

    Thank you for looking into this. I guess at some point I should join
    legal-discuss, but I already feel I'm overloaded with apache mailing
    lists :-)
    On 2/22/07, Jean T. Anderson wrote:
    Mike Kienenberger wrote:
    ... if we start providing derby as a component of
    cayenne, then we are subject to the export regs.
    I just posted a question to legal-discuss asking if an Apache product
    includes any product listed at http://www.apache.org/licenses/exports/,
    does it need to also do the BIS notification.

    -jean
  • Kevin Menard at Feb 22, 2007 at 6:20 pm
    Yay, now I get to chime in with my non-legal background :-)
    -----Original Message-----
    From: Michael Gentry
    Sent: Thursday, February 22, 2007 11:18 AM
    To: dev@cayenne.apache.org
    Subject: Re: podling BIS notifications (jars in svn & crypto)

    I don't think I'm missing your point (at least I'm trying not to).
    I'm just arguing that if having an extension point in a
    product in which an end-user can write their own code
    separate of Apache (in our case, retrieving the DB password,
    but really any extension point), in which the end-uesr can
    incorporate encryption -- and thus require the BIS/etc, then
    that opens a huge can of worms for a lot of projects (like
    Ant).
    Michael,

    I think I agreed with you when the thread started. I believe the point
    you're trying to make is that an end-user can incorporate encryption
    with any interface, particularly those just passing strings back and
    forth. After thinking about it a bit more though, I think the key
    difference is that your interface is ostensibly designed for the
    encryption of data. Between the method names and the salt argument,
    it'd be hard to argue it any other way. Whereas, at least where the
    other interfaces are concerned, the burden of proof is on someone else.
    If that truly be the case, then there may be no can of worms . . .

    --
    Kevin
  • Jean T. Anderson at Feb 22, 2007 at 4:59 am

    Michael Gentry wrote:
    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.
    As Mike K pointed out:
    On the other hand, Roy also wrote:
    ==============
    As far as timing goes, the notice should be sent as soon as
    it becomes clear that the product will eventually contain code
    that is designed for a given 5D002 product (i.e., anything that
    uses encryption for purposes other than mere authentication).
    ==============
    From the recent posts to general@i.a.o, it seems not needed.
    It still might be worth a post to legal-discuss for the definitive legal
    answer -- and provide fodder for an authentication/password faq at
    http://www.apache.org/dev/crypto.html#faq -- I think it could really use
    one.

    -jean
  • Mike Kienenberger at Feb 22, 2007 at 3:39 am

    On 2/21/07, Michael Gentry wrote:
    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
    From http://www.apache.org/licenses/exports/:
    ========================================
    Products classified as ECCN 5D002, are exported by the ASF under the
    TSU exception in EAR 740.13(e), which applies to software containing
    or designed for use with encryption software that is publicly
    available as open source.
    ========================================

    On the other hand, Roy also wrote:
    ==============
    As far as timing goes, the notice should be sent as soon as
    it becomes clear that the product will eventually contain code
    that is designed for a given 5D002 product (i.e., anything that
    uses encryption for purposes other than mere authentication).
    ==============

    So I think we need a ruling from ASF legal (probably either Roy or Cliff).
  • Mike Kienenberger at Feb 22, 2007 at 3:42 am
    http://www.access.gpo.gov/bis/ear/txt/ccl5-pt2.txt:

    --------------------------------
    a.1. Designed or modified to use
    "cryptography" employing digital techniques
    performing any cryptographic function other than
    authentication or digital signature having any of
    the following:
    --------------------------------

    Since it's only for authentication (isn't that the case?), are we ok?

    On 2/21/07, Mike Kienenberger wrote:
    On 2/21/07, Michael Gentry wrote:
    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
    From http://www.apache.org/licenses/exports/:
    ========================================
    Products classified as ECCN 5D002, are exported by the ASF under the
    TSU exception in EAR 740.13(e), which applies to software containing
    or designed for use with encryption software that is publicly
    available as open source.
    ========================================

    On the other hand, Roy also wrote:
    ==============
    As far as timing goes, the notice should be sent as soon as
    it becomes clear that the product will eventually contain code
    that is designed for a given 5D002 product (i.e., anything that
    uses encryption for purposes other than mere authentication).
    ==============

    So I think we need a ruling from ASF legal (probably either Roy or Cliff).
  • Jean T. Anderson at Feb 22, 2007 at 3:47 am

    Mike Kienenberger wrote:
    On 2/21/07, Michael Gentry wrote:

    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

    From http://www.apache.org/licenses/exports/:
    ========================================
    Products classified as ECCN 5D002, are exported by the ASF under the
    TSU exception in EAR 740.13(e), which applies to software containing
    or designed for use with encryption software that is publicly
    available as open source.
    ========================================

    On the other hand, Roy also wrote:
    ==============
    As far as timing goes, the notice should be sent as soon as
    it becomes clear that the product will eventually contain code
    that is designed for a given 5D002 product (i.e., anything that
    uses encryption for purposes other than mere authentication).
    ==============

    So I think we need a ruling from ASF legal (probably either Roy or Cliff).
    oh, sorry, I wasn't reading closely enough in my post a couple minutes
    ago. my bad.

    Cayenne *only* enables password encryption? I kinda doubt you need the
    bis notification, but a post to legal-discuss would remove all doubt.

    My comparison to derby doesn't fit -- it enables encryption of database
    data.

    -jean
  • Kevin Menard at Feb 22, 2007 at 4:17 am

    Cayenne *only* enables password encryption? I kinda doubt you
    need the bis notification, but a post to legal-discuss would
    remove all doubt.

    My comparison to derby doesn't fit -- it enables encryption
    of database data.
    Forgive my naitivity . . . Does that mean if we want to use derby rather
    than hsqldb as our embedded DB of choice that we then need to be
    certified or whatever?

    --
    Kevin
  • Jean T. Anderson at Feb 22, 2007 at 5:02 am

    Kevin Menard wrote:
    Cayenne *only* enables password encryption? I kinda doubt you
    need the bis notification, but a post to legal-discuss would
    remove all doubt.

    My comparison to derby doesn't fit -- it enables encryption
    of database data.
    Forgive my naitivity . . . Does that mean if we want to use derby rather
    than hsqldb as our embedded DB of choice that we then need to be
    certified or whatever?
    that's a really good question and I'll post it to legal-discuss.

    -jean

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedFeb 21, '07 at 5:47p
activeFeb 27, '07 at 3:51p
posts26
users5
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase