Stian Soiland-Reyes created TAVERNA-959:
-------------------------------------------
Summary: 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
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/if we distribute the Taverna Command Line (and Workbench) 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)
