Thanks, Stian. I don't think I have the expertise to help with the taverna-mobile and taverna-databundle-viewer questions.
On Mon, Apr 25, 2016 at 4:17 PM Stian Soiland-Reyes <[email protected]> wrote: > On 25 April 2016 at 23:06, Gale Naylor <[email protected]> > wrote: > > You're draft submissions look good to me, Ian. > > I agree that Ian's draft look good, except: > > <ControlledSource href=" > > https://github.com/apache/incubator-taverna-engine/blob/master/taverna-credential-manager-impl/ > "> > > We should link to the apache.org hosted one as it would be Apache > Software Foundation exporting it, not GitHub. (They would re-export). > > Also it's enough to link to the high-level folder where we'll include > an Export note in the README, as under > http://www.apache.org/dev/crypto.html#inform > > (Example: https://github.com/apache/nifi#export-control ) > > > I tested with a newer Bouncy Castle > > <groupId>org.bouncycastle</groupId> > <artifactId>bcprov-jdk15on</artifactId> > <version>1.54</version> > > which works fine - so if we use that we can use the simpler Bouncy > Castle source links for the newer 1.54. > > > We will have to raise it with the incubator PMC which can do the XML > changes and email formally (who will become the "SUBMITTED BY"). > > > > What code and distributions have we reviewed so far? > > Looking at http://www.apache.org/licenses/exports/ > > .. then I think we might have to extend Ian's list.. > > taverna-engine is invoking Bouncy Castle, using JSSE, and uses Apache > Derby which itself is classified. Experimental > taverna-execution-hadoop links to Apache Hadoop which is also > classified. > taverna-common-activities is using Apache WSS4J which itself is classified. > taverna-commandline would bundle the JARs of the above, and so by > transitivity also be classified > taverna-workbench includes credential-manager-ui - so transitivity applies > here. > taverna-workbench-product as well would have transitivity > incubator-taverna-server as well by transitivity and using Bouncy > Castle and Apache CXF. > > puh! :) And then there's the external dependencies.. how do we know > if they themselves are export regulated or not? As you see above it > could be non-obvious because of transitivity. Perhaps the transitivity > stops when you don't use that particular feature? (I'll ask on > legal-discuss) > > > As for taverna-mobile and taverna-databundle-viewer I am not sure as > it's a different ecosystem for me.. but there could be something there > as well. Could someone help? > > > Reading this strictly I think even taverna-language seems to need to > be classified because it uses Jena which uses JsonLd-Java which uses > Apache HttpComponents which is classified - and indeed most JSON-LD > contexts are served over https. However Jena is not listed in that > page.. should it? > > > I'll try to construct a more complete XML in the wiki and check with > legal-discuss - hopefully we can shrink the list. > > > > I've also asked Jena if they might be classified -- sorry Andy :( > https://issues.apache.org/jira/browse/JENA-1169 > > > > > > Gale > > > > On Fri, Apr 8, 2016 at 10:33 AM Ian Dunlop <[email protected]> wrote: > > > >> Hello, > >> > >> Here is my attempt at the xml snippet for > >> > >> > https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml > >> > >> <Project href="http://taverna.incubator.apache.org/";> > >> <Name>Apache Taverna Project</Name> > >> <Contact><Name>Ian Dunlop</Name></Contact> > >> <Product> > >> <Name>Credential Manager</Name> > >> <Version> > >> <Names>3.1.0-incubating</Names> > >> <ECCN>5D002</ECCN> > >> <ControlledSource href=" > >> > >> > https://github.com/apache/incubator-taverna-engine/blob/master/taverna-credential-manager-impl/ > >> "> > >> <Manufacturer>ASF</Manufacturer> > >> <Why>designed for use with encryption library (bouncy > castle)</Why> > >> </ControlledSource> > >> <ControlledSource href=" > >> http://mvnrepository.com/artifact/org.bouncycastle/bcprov-jdk16/1.46";> > >> <Manufacturer>Bouncy Castle</Manufacturer> > >> <Why>General-purpose encryption library for Java 1.6</Why> > >> </ControlledSource> > >> </Version> > >> </Product> > >> </Project> > >> > >> None of the bouncy castle downloads for previous releases seem to work > so I > >> put the maven link in. Their ftp site ftp://ftp.bouncycastle.org/pub > >> linked > >> from https://www.bouncycastle.org/latest_releases.html is broken or > >> password protected. > >> > >> Before we add this snippet we have to send the notification to the US > Gvt, > >> something like: > >> > >> > >> SUBMISSION TYPE: TSU > >> > >> SUBMITTED BY: ianwdunlop-at-apache.org > >> > >> SUBMITTED FOR: Apache Software Foundation > >> > >> POINT OF CONTACT: Secretary, Apache Software Foundation > >> > >> FAX: +1-919-573-9199 > >> > >> MANUFACTURER(S) Apache Software Foundation. > >> > >> Bouncy Castle. > >> > >> PRODUCT NAME/MODEL #: Apache Taverna Credential Manager > >> > >> > >> ECCN: 5D002 > >> > >> NOTIFICATION: http://www.apache.org/licenses/exports/ > >> > >> > >> Then we also add the notice at > >> http://www.apache.org/dev/crypto.html#inform > >> to the README. > >> > >> Cheers, > >> > >> Ian > >> > >> > >> On 6 April 2016 at 14:09, Stian Soiland-Reyes <[email protected]> wrote: > >> > >> > Agree that it should be sufficient to say we use BouncyCastle like the > >> > other projects and link to our Git repositories. > >> > > >> > > >> > > >> > https://github.com/apache/incubator-taverna-engine/blob/master/taverna-credential-manager-impl/pom.xml > >> > > >> > > >> > https://github.com/apache/incubator-taverna-maven-parent/blob/master/pom.xml#L353 > >> > > >> > We use BouncyCastle version 1.46 - we should probably try to upgrade > it > >> for > >> > the next release if that is ancient, avoid too many security holes! > >> > (Although I think the US government would be happy if we used an > insecure > >> > older version ;) > >> > > >> > It should be sufficient to add the same property to > >> taverna-engine/pom.xml > >> > with newer version and see if unit tests pass. We are lucky in that > for > >> T3 > >> > we don't need to keep the keychain file compatible - although we might > >> want > >> > to check how the Taverna Server makes a keychain file as well.. Does > that > >> > also use BouncyCastle? > >> > On 6 Apr 2016 11:07, "Ian Dunlop" <[email protected]> wrote: > >> > > >> > > 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) > >> > > > > >> > > > >> > > >> > > > > -- > Stian Soiland-Reyes > Apache Taverna (incubating), Apache Commons RDF (incubating) > http://orcid.org/0000-0001-9842-9718 >
