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)
> >
>

Reply via email to