I guess Taverna Mobile would support https:// for the Server connection. I could not find out about export restrictions for the Android SDK. On Android you don't have JRE - so SSL is done differently I guess?
It depends if it's HTTPComponents 4 (yes) or Apache Commons HTTP 3.x (no) See http://www.apache.org/licenses/exports/ (I don't know of any equivalent list for non-ASF software - this is similar to license restrictions isn't it, so I think ideally it should me in META-INF/ for propagation) On 28 April 2016 at 11:49, Ian Dunlop <[email protected]> wrote: > 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 >>>> >> >> > > -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
