Hello, I think you are correct Gale. I don't think it's too difficult a process though. Seems that you need to update http://www.apache.org/licenses/exports/ with the links to source code and send some details to the US gvt http://www.apache.org/dev/crypto.html#notify. So it's an administrative pain but should not stop Apache Taverna including the crytpo code. The bouncy castle links seem to be a download that no longer exists, there are a bunch of releases on https://bouncycastle.org/latest_releases.html. I'm sure one of them will suffice.
Cheers, Ian On 4 April 2016 at 18:10, Gale Naylor (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/TAVERNA-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224530#comment-15224530 > ] > > Gale Naylor commented on TAVERNA-959: > ------------------------------------- > > Since we use BouncyCastle and it appears on the ASF Product Classification > List for other Apache products (http://www.apache.org/licenses/exports/), > doesn't that mean the reporting requirements apply to us? This FAQ ( > http://www.apache.org/dev/crypto.html#faq-public) seems to imply we need > to report now: "In other words, a project should send out a notification > email just after making the decision to include code that is specially > designed to work with crypto APIs but before actually committing such > code." Am I misunderstanding something? It doesn't look like we need to be > specific about exactly where it is used and can just say "development" > rather than a specific version. > > One thing: I did a spot check of the classification list ( > http://www.apache.org/licenses/exports/) and all the links I tried worked > except the ones for BouncyCastle: all the BouncyCastle links I tried were > broken. Seems strange. > > > 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) >
