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
