www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stian Soiland-Reyes (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LEGAL-250) US Export declaration of transitive dependencies?
Date Mon, 02 May 2016 01:50:12 GMT

    [ 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


Mime
View raw message