Hello, I guess there must be some ssl dependencies in mobile. It uses Apache http libraries, are they in the export list?
Cheers, Ian On 26/04/16 01:02, Stian Soiland-Reyes wrote: > No, I think we should do a dependency review there anyway before we > can release them - e.g. > https://github.com/apache/incubator-taverna-databundle-viewer/blob/master/DEPENDENCY_LICENSES.md > lists the gem taverna-t2flow, a LGPL-licensed dependency - upstream > authors (e.g. myself and Rob) would need to change its license to be > ASF compatible. > > > On 26 April 2016 at 00:24, Gale Naylor <[email protected]> wrote: >> 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 >>> > >
signature.asc
Description: OpenPGP digital signature
