[jira] [Commented] (LEGAL-250) US Export declaration of transitive dependencies?

["Stian Soiland-Reyes (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LEGAL-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15266048#comment-15266048 ] 

Stian Soiland-Reyes commented on LEGAL-250:
-------------------------------------------

Thanks for having a look, Alex!


None of them are distributed by ASF as of now, as we have not yet made any binary distributions with all dependencies for dist/ yet. (Mainly as we have not had time to generate the corresponding LICENSE and NOTICE for those).

So it's basically Maven <dependency> I'm talking about - so it would be Maven downloading it - does that mean "Designed for using" - or is it only with a tighter encryption-related integration that we need to declare?


However we have a command line and GUI which in the end would be distributed also as a binary, which would then include other dependencies like Derby and HttpComponents. I know Jena's binary distribution includes HttpComponent - so is the conclusion that if you include a library that can use HTTPS connection - and even if that is done through Java's built-in support, then it should be classified?  (Devil's advocate - that could mean anything supporting the use of java.net.URL).


I've updated out READMEs which probably explain in a bit more detail why it should (or shouldn't) be classified. These include cross-dependencies between Taverna components as they would be released separately.


In dependency order:

From https://github.com/apache/incubator-taverna-language/#export-restrictions

> The following provides more details on the included cryptographic software:

>     Apache Taverna Language depend on Apache Jena, which depend on Apache HttpComponents Client, which can initiate encrypted https:// connections using Java Secure Socket Extension (JSSE). Taverna Language does not use this facility, however after building, the shaded JAR of taverna-tavlang-tool include Apache HttpComponents Core and Client.


https://github.com/apache/incubator-taverna-osgi/#export-restrictions

>     taverna-download-impl depend on the Apache HttpComponents Client, which can initiate encrypted https:// connections using Java Secure Socket Extension (JSSE).


https://github.com/apache/incubator-taverna-engine/#export-restrictions

>     taverna-credential-manager-impl manages an encrypted keystore for username/passwords and client/server SSL certificates. It is designed to be used with Java Secure Socket Extension (JSSE), Java Cryptography Extension (JCE) and depends on the BouncyCastle bcprov encryption library. The JCE Unlimited Strength Jurisdiction Policy must be installed separately to use keystore passwords with 7 or more characters.
>    Apache Taverna Engine depend on Apache Taverna Language, Apache Taverna OSGi and Apache Jena, which depend on Apache HttpComponents Client, which can initiate encrypted https:// connections using Java Secure Socket Extension (JSSE).
>     taverna-database-configuration-impl and taverna-reference-impl depend on Apache Derby, which use the Java Cryptography Extension (JCE) API.


https://github.com/apache/incubator-taverna-common-activities/#export-restrictions

>     taverna-rest-activity depend on Apache HttpComponents Client, which can be configured to initiate https:// connections.
>     taverna-wsdl-generic and taverna-wsdl-activity uses Java Secure Socket Extension (JSSE) and depend on Apache WSS4J, Apache XML Security for Java for accessing secure SOAP Web Services.
>     Apache Taverna Common Activities depends on the Apache Taverna Engine Credential Manager API for management of username/password and client/server SSL certificates.
>     taverna-interaction-activity depend on Jetty, which includes UnixCrypt.java for one way cryptography, and can be configured for SSL encryption using Java Secure Socket Extension

(I've speculatively included Jetty here due to https://dev.eclipse.org/mhonarc/lists/jetty-users/msg05898.html - I can't see it declared elsewhere) 


https://github.com/apache/incubator-taverna-commandline/#export-restrictions

>     Apache Taverna Command Line depend on and interact with the Apache Taverna Engine, credential manager, which manages an encrypted keystore for username/passwords and client/server SSL certificates.
>     The JCE Unlimited Strength Jurisdiction Policy must be installed separately to use keystore passwords with 7 or more characters.
>     Apache Taverna Command Line depend on and interact with Apache Derby, and could be configured to do so over an SSL encrypted connection.
>     Apache Taverna Command Line depend on Apache Taverna Language, Apache Taverna OSGi, Apache Taverna Engine, and may be configured to check for updates using https:// connections.
>     After building, the taverna-commandline-product archive lib folder include BouncyCastle bcprov encryption library, Apache HttpComponents Core and Client, Apache Derby, Jetty, Apache WSS4J, Apache XML Security for Java, Open SAML Java, Apache Taverna Language, Apache Taverna OSGi, Apache Taverna Engine, and Apache Taverna Common Activities.


The last line is included to cover for future binary distribution - as this would basically assemble all of the above dependencies in its lib/ folder. So the transitive questions then comes to if even listing other Taverna products should be declared. Playing safe (if verbose) above - but as the ECCN classification is like a virus this doesn't feel too good to be too aggressive here.


I have not yet updated the README for the rest of the repositories listed in the XML - but as they basically depend on the above it would just be replicating pretty much the same.



I guess the only "true" encryption-related in Taverna is the Taverna Engine credential-manager - which have two parts:

a) Manage a passphrase-encrypted credentials keystore using BouncyCastle. (This is limited to 6 character long password unless the JCE "Strong Encryption" policy is installed)

b) Hook into Java's JSSE layer to use the above keystore for additional client and server SSL certificates (for browser-like "Accept this certificate" dialogues), and for java.net.URL handler to ask the credential manager for URL username/passwords (e.g. on HTTP Basic Auth).


taverna-wsdl-generic / taverna-wsdl-activity can also do WSS4J and encrypted SOAP message authentication (e.g. with Globus 4) - so perhaps that is also a solid classification.


The rest boils down to "Can do https client connections" - do that alone mean classification? I would think that would involve many more ASF projects.


> US Export declaration of transitive dependencies?
> -------------------------------------------------
>
>                 Key: LEGAL-250
>                 URL: https://issues.apache.org/jira/browse/LEGAL-250
>             Project: Legal Discuss
>          Issue Type: Question
>            Reporter: Stian Soiland-Reyes
>
> Hi,
> I'm preparing the changes to eccnmatrix.xml for Apache Taverna (TAVERNA-959) - my current draft is at
> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Crypto+draft+XML
> Would you be able to help me review this? I was hoping to make it a bit shorter..
> I assume formally it would need to be the Incubator PMC who sends the email registration?
> At first we thought we would only need to declare our use of the Bouncy Castle encryption library (as used by Taverna Engine's Credential Manager to store a keychain) - however now I wonder if we need to also list any Apache dependencies that themselves are also listed on http://www.apache.org/licenses/exports/ (e.g. CXF, HTTP Components, WSS4J, XML Security) - or if they are exempt if you are not specifically using the encryption functionality?
> That is - a dependency like Apache HTTP Components have code to deal with SSL and JSSE - and is therefore classified. We use Apache Jena which rely on JSONLD-JAva which rely on HTTP Component just for network access (potentially loading from https://) - but we don't use that network access from Taverna code. Do we still list HTTP Component (and potentially Jena and JSONLD-Java) as classified?
> Does it make a difference if a classified item is used as a <dependency> in a source release, or if the JAR of the classified item is included in a binary distribution for dist?
> This would affect loads of projects - e.g. Jena binaries redistribute Apache HTTP Components (JENA-1169) - but doesn't do anything particular with encryption (except supporting RDF files hosted at https://) -- 
> Complicating matters is that Taverna have multiple git repositories - so if interpreted strictly all Taverna components that somehow depend on the classified Taverna component also become affected (even if they don't actually import taverna-credential-manager-impl) - do we need to list them all?   There is a lot of repetition - so I added just a single <Version> for all the "development" - even though each git repository has a different versioning scheme.  
> But do I still need to transitively expand the <Why> from its dependencies' dependencies, or is it enough to list what the item directly uses?  (e.g. taverna-plugin-bioinformatics just needs to list "use with Apache Taverna Engine" which then implies the other Taverna modules and JSSE, JCE, BouncyCastle  and HTTP Components?)
> I assume an indirection to http://taverna.incubator.apache.org/download/code/ is not valid and I need to list each of our git repositories? 
> I see for dist it's common practice to just link to the top-level tree which simplifies the release <Version> - however I was unable to give it a single version number so I just called it "All releases" - see https://archive.apache.org/dist/incubator/taverna/source/  
> Sorry for the long email.. I've been pondering on this all night long :)
> It sounds to me like we need some kind of Maven support for this.. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org