[
https://issues.apache.org/jira/browse/TAVERNA-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15266051#comment-15266051
]
Stian Soiland-Reyes commented on TAVERNA-959:
---------------------------------------------
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
"encryption software".
I'm checking with LEGAL-250 if the above list can be shrunk - I would hope that
being able to do https:// connection is not enough.
I've not updated the remaining READMEs - they would basically be a variation of
taverna-commandline with references to the other Taverna components they use.
> Crypto review and reporting
> ---------------------------
>
> Key: TAVERNA-959
> URL: https://issues.apache.org/jira/browse/TAVERNA-959
> Project: Apache Taverna
> Issue Type: Task
> Components: Taverna Common Activities, Taverna Engine
> Reporter: Stian Soiland-Reyes
> Priority: Critical
> Labels: security
> Fix For: engine 3.1.0, common activities 2.1.0
>
>
> while stumbling over http://www.apache.org/dev/crypto.html
> I come to think about our Credential Manager:
> https://github.com/apache/incubator-taverna-engine/tree/master/taverna-credential-manager
> https://github.com/apache/incubator-taverna-engine/tree/master/taverna-credential-manager-impl
> and the WSDL SSL support in
> https://github.com/apache/incubator-taverna-common-activities/tree/master/taverna-wsdl-activity/src/main/java/org/apache/taverna/activities/wsdl/security
> While we don't have our own encryption code (puh!) we certainly have a fair
> share of plumbing that uses it.
> Credential Manager uses BouncyCastle to keep an encrypted user/password and
> certificate store in the Taverna user home directory - based on a password
> the user provides.
> Obviously we also generally support https:// through Java's normal SSL
> support - the Credential Manager has UI support for managing additional
> client and server certificates and for asking for username/password on
> connections.
> The WSDL activity has support for using WS Security authentication and also
> works with https.
> Looking over the policy at http://www.apache.org/dev/crypto.html I realize
> now that when we distribute the Taverna Command Line (and Workbench) binary
> distribution it would be bundling and using the Bouncy Castle library - which
> would be covered by US Export restrictions.
> Thus this task to review what of our code and distributions would be covered
> by US Export restrictions - if any - and perform the required reporting if
> needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
