Re: ECCN cryptography reporting?

[Stian Soiland-Reyes]

Thanks!

I think we need to work more on https://www.apache.org/dev/crypto.html
to add the kind of considerations to make to decide if some software
needs to be registered or not, perhaps suggest various "escape
hatches".

Now we can proceed with the Taverna RCs :)

On 21 May 2016 at 22:24, Ted Dunning  wrote:
> I just sent this notification. I added a small amount of language to the
> notification and added secretary@a.o as a cc and as a contact point.
>
> Thanks to the Taverna community for laying the groundwork so assiduously.
> This is a notoriously opaque area which you have illuminated nicely.
>
>
> On Thu, May 19, 2016 at 6:16 AM, Stian Soiland-Reyes 
> wrote:
>
>> Hi, Taverna is still waiting for the ECCN registration for Taverna to
>> be sent in from Ted before we can continue to prepare our next release
>> candiates.
>>
>>
>> Taverna's listing is now live on:
>> https://www.apache.org/licenses/exports/
>>
>> See draft email on
>>
>> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review#TavernaCryptographyreview-Draftregistrationemail
>>
>>
>> FYI: I added the ECCN "flowchart" considerations to
>>
>>
>> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
>>
>>
>>
>>
>> On 12 May 2016 at 14:20, Stian Soiland-Reyes  wrote:
>> > Ted & John,
>> >
>> >
>> > Should Taverna wait until the ECCN registration has been filed (or
>> > not) before we prepare our next release candidate for voting?
>> >
>> >
>> > On 9 May 2016 at 17:54, Stian Soiland-Reyes  wrote:
>> >> We documented it in https://issues.apache.org/jira/browse/TAVERNA-959
>> >> and on
>> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
>> >>
>> >> See also
>> https://issues.apache.org/jira/browse/LEGAL-250?focusedCommentId=15272500=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15272500
>> >>
>> >>
>> >>> Taverna Language (while primarily an API for designing workflows)
>> includes a component which functionality is data storage in a ZIP file -
>> the encryption functionality of HTTP Components is however not used, and so
>> Language should not be registered. (unless we make a binary distribution
>> that includes HTTP Components)
>> >>
>> >>> Taverna OSGi's Download API module is "Sending, receiving or storing
>> information" and so should be registered because it is using HTTP
>> Components and can do https.
>> >>
>> >>> Taverna Engine's Credential Manager module is doing "information
>> security" and should be registered.
>> >>
>> >>> Taverna Common Activities are "Sending, receiving or storing
>> information" (talking to web services) and should be registered.
>> >>
>> >>> Taverna Command Line is primarily running a workflow, and should NOT
>> be registered (unless you consider a workflow to be primarily
>> sending/receiving information) - however if we make a binary distribution
>> it would include Bouncy Castle, Derby, HTTPComponents as JARs, and at that
>> point needs to be registered.
>> >>
>> >>
>> >> The README notes show the findings in detail. See the individual repos.
>> >>
>> >>
>> >> We have not done a detailed review on the workbench* modules as we are
>> >> not yet releasing them - however our release of the above is currently
>> >> blocked on this ECCN registration.
>> >>
>> >>
>> >> On 5 May 2016 at 02:23, Ted Dunning  wrote:
>> >>> My guess is that this would fall to me.
>> >>>
>> >>> There is considerable analysis to be done to determine whether filing
>> is
>> >>> required.
>> >>>
>> >>> Are you guys documenting the decision points?
>> >>>
>> >>>
>> >>>
>> >>> On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes 
>> >>> wrote:
>> >>>
>>  On 2 May 2016 at 03:23, Stian Soiland-Reyes  wrote:
>> 
>>  > Formally - would it need to be the Incubator PMC chair sending the
>>  > ECCN encryption email?
>> 
>>  Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?
>> 
>>  --
>>  Stian Soiland-Reyes
>>  Apache Taverna (incubating), Apache Commons RDF (incubating)
>>  http://orcid.org/-0001-9842-9718
>> 
>>  -
>>  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>  For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 
>> >>
>> >>
>> >>
>> >> --
>> >> Stian Soiland-Reyes
>> >> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> >> http://orcid.org/-0001-9842-9718
>> >
>> >
>> >
>> > --
>> > Stian Soiland-Reyes
>> > Apache Taverna (incubating), Apache Commons RDF (incubating)
>> > http://orcid.org/-0001-9842-9718
>>
>>
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/-0001-9842-9718
>>
>> 

Re: ECCN cryptography reporting?

[Ted Dunning]

I just sent this notification. I added a small amount of language to the
notification and added secretary@a.o as a cc and as a contact point.

Thanks to the Taverna community for laying the groundwork so assiduously.
This is a notoriously opaque area which you have illuminated nicely.


On Thu, May 19, 2016 at 6:16 AM, Stian Soiland-Reyes 
wrote:

> Hi, Taverna is still waiting for the ECCN registration for Taverna to
> be sent in from Ted before we can continue to prepare our next release
> candiates.
>
>
> Taverna's listing is now live on:
> https://www.apache.org/licenses/exports/
>
> See draft email on
>
> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review#TavernaCryptographyreview-Draftregistrationemail
>
>
> FYI: I added the ECCN "flowchart" considerations to
>
>
> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
>
>
>
>
> On 12 May 2016 at 14:20, Stian Soiland-Reyes  wrote:
> > Ted & John,
> >
> >
> > Should Taverna wait until the ECCN registration has been filed (or
> > not) before we prepare our next release candidate for voting?
> >
> >
> > On 9 May 2016 at 17:54, Stian Soiland-Reyes  wrote:
> >> We documented it in https://issues.apache.org/jira/browse/TAVERNA-959
> >> and on
> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
> >>
> >> See also
> https://issues.apache.org/jira/browse/LEGAL-250?focusedCommentId=15272500=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15272500
> >>
> >>
> >>> Taverna Language (while primarily an API for designing workflows)
> includes a component which functionality is data storage in a ZIP file -
> the encryption functionality of HTTP Components is however not used, and so
> Language should not be registered. (unless we make a binary distribution
> that includes HTTP Components)
> >>
> >>> Taverna OSGi's Download API module is "Sending, receiving or storing
> information" and so should be registered because it is using HTTP
> Components and can do https.
> >>
> >>> Taverna Engine's Credential Manager module is doing "information
> security" and should be registered.
> >>
> >>> Taverna Common Activities are "Sending, receiving or storing
> information" (talking to web services) and should be registered.
> >>
> >>> Taverna Command Line is primarily running a workflow, and should NOT
> be registered (unless you consider a workflow to be primarily
> sending/receiving information) - however if we make a binary distribution
> it would include Bouncy Castle, Derby, HTTPComponents as JARs, and at that
> point needs to be registered.
> >>
> >>
> >> The README notes show the findings in detail. See the individual repos.
> >>
> >>
> >> We have not done a detailed review on the workbench* modules as we are
> >> not yet releasing them - however our release of the above is currently
> >> blocked on this ECCN registration.
> >>
> >>
> >> On 5 May 2016 at 02:23, Ted Dunning  wrote:
> >>> My guess is that this would fall to me.
> >>>
> >>> There is considerable analysis to be done to determine whether filing
> is
> >>> required.
> >>>
> >>> Are you guys documenting the decision points?
> >>>
> >>>
> >>>
> >>> On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes 
> >>> wrote:
> >>>
>  On 2 May 2016 at 03:23, Stian Soiland-Reyes  wrote:
> 
>  > Formally - would it need to be the Incubator PMC chair sending the
>  > ECCN encryption email?
> 
>  Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?
> 
>  --
>  Stian Soiland-Reyes
>  Apache Taverna (incubating), Apache Commons RDF (incubating)
>  http://orcid.org/-0001-9842-9718
> 
>  -
>  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>  For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 
> >>
> >>
> >>
> >> --
> >> Stian Soiland-Reyes
> >> Apache Taverna (incubating), Apache Commons RDF (incubating)
> >> http://orcid.org/-0001-9842-9718
> >
> >
> >
> > --
> > Stian Soiland-Reyes
> > Apache Taverna (incubating), Apache Commons RDF (incubating)
> > http://orcid.org/-0001-9842-9718
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/-0001-9842-9718
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: ECCN cryptography reporting?

[Stian Soiland-Reyes]

Hi, Taverna is still waiting for the ECCN registration for Taverna to
be sent in from Ted before we can continue to prepare our next release
candiates.


Taverna's listing is now live on:
https://www.apache.org/licenses/exports/

See draft email on
https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review#TavernaCryptographyreview-Draftregistrationemail


FYI: I added the ECCN "flowchart" considerations to

https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review




On 12 May 2016 at 14:20, Stian Soiland-Reyes  wrote:
> Ted & John,
>
>
> Should Taverna wait until the ECCN registration has been filed (or
> not) before we prepare our next release candidate for voting?
>
>
> On 9 May 2016 at 17:54, Stian Soiland-Reyes  wrote:
>> We documented it in https://issues.apache.org/jira/browse/TAVERNA-959
>> and on 
>> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
>>
>> See also 
>> https://issues.apache.org/jira/browse/LEGAL-250?focusedCommentId=15272500=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15272500
>>
>>
>>> Taverna Language (while primarily an API for designing workflows) includes 
>>> a component which functionality is data storage in a ZIP file - the 
>>> encryption functionality of HTTP Components is however not used, and so 
>>> Language should not be registered. (unless we make a binary distribution 
>>> that includes HTTP Components)
>>
>>> Taverna OSGi's Download API module is "Sending, receiving or storing 
>>> information" and so should be registered because it is using HTTP 
>>> Components and can do https.
>>
>>> Taverna Engine's Credential Manager module is doing "information security" 
>>> and should be registered.
>>
>>> Taverna Common Activities are "Sending, receiving or storing information" 
>>> (talking to web services) and should be registered.
>>
>>> Taverna Command Line is primarily running a workflow, and should NOT be 
>>> registered (unless you consider a workflow to be primarily 
>>> sending/receiving information) - however if we make a binary distribution 
>>> it would include Bouncy Castle, Derby, HTTPComponents as JARs, and at that 
>>> point needs to be registered.
>>
>>
>> The README notes show the findings in detail. See the individual repos.
>>
>>
>> We have not done a detailed review on the workbench* modules as we are
>> not yet releasing them - however our release of the above is currently
>> blocked on this ECCN registration.
>>
>>
>> On 5 May 2016 at 02:23, Ted Dunning  wrote:
>>> My guess is that this would fall to me.
>>>
>>> There is considerable analysis to be done to determine whether filing is
>>> required.
>>>
>>> Are you guys documenting the decision points?
>>>
>>>
>>>
>>> On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes 
>>> wrote:
>>>
 On 2 May 2016 at 03:23, Stian Soiland-Reyes  wrote:

 > Formally - would it need to be the Incubator PMC chair sending the
 > ECCN encryption email?

 Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?

 --
 Stian Soiland-Reyes
 Apache Taverna (incubating), Apache Commons RDF (incubating)
 http://orcid.org/-0001-9842-9718

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


>>
>>
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/-0001-9842-9718
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/-0001-9842-9718



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: ECCN cryptography reporting?

[Stian Soiland-Reyes]

We documented it in https://issues.apache.org/jira/browse/TAVERNA-959
and on 
https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review

See also 
https://issues.apache.org/jira/browse/LEGAL-250?focusedCommentId=15272500=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15272500


> Taverna Language (while primarily an API for designing workflows) includes a 
> component which functionality is data storage in a ZIP file - the encryption 
> functionality of HTTP Components is however not used, and so Language should 
> not be registered. (unless we make a binary distribution that includes HTTP 
> Components)

> Taverna OSGi's Download API module is "Sending, receiving or storing 
> information" and so should be registered because it is using HTTP Components 
> and can do https.

> Taverna Engine's Credential Manager module is doing "information security" 
> and should be registered.

> Taverna Common Activities are "Sending, receiving or storing information" 
> (talking to web services) and should be registered.

> Taverna Command Line is primarily running a workflow, and should NOT be 
> registered (unless you consider a workflow to be primarily sending/receiving 
> information) - however if we make a binary distribution it would include 
> Bouncy Castle, Derby, HTTPComponents as JARs, and at that point needs to be 
> registered.


The README notes show the findings in detail. See the individual repos.


We have not done a detailed review on the workbench* modules as we are
not yet releasing them - however our release of the above is currently
blocked on this ECCN registration.


On 5 May 2016 at 02:23, Ted Dunning  wrote:
> My guess is that this would fall to me.
>
> There is considerable analysis to be done to determine whether filing is
> required.
>
> Are you guys documenting the decision points?
>
>
>
> On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes 
> wrote:
>
>> On 2 May 2016 at 03:23, Stian Soiland-Reyes  wrote:
>>
>> > Formally - would it need to be the Incubator PMC chair sending the
>> > ECCN encryption email?
>>
>> Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/-0001-9842-9718
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: ECCN cryptography reporting?

[Stian Soiland-Reyes]

I would be happy if Taverna doesn't meet the ECCN registration criteria :)


I think we are not exempt overall from the 2010 decontrolling:

https://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#Three

because we do a lot of "sending and receiving information" - or at
least most Taverna workflows do that.


I would think our Credential Manager is  "designed to use encryption
functionality" - We register handlers with JSSE, in particular to
manage user-accepted client/server certificates (as in the browser).
We don't require JCE Strong Encryption, but recommend you do  (as
otherwise your passphrase is limited to 6 characters!) - we also use
Bouncy Castle (ECCN classified) APIs directly for managing the
keychain.

https://github.com/apache/incubator-taverna-engine/#export-restrictions


Our web service integration use WSS4J and XML Security (also ECCN
classified), and of course the REST service can make https connections
using the above certificate handling.

https://github.com/apache/incubator-taverna-common-activities/#export-restrictions


While the immediate release won't include a binary distribution for
dist.apache.org, we plan that for later releases, and they would
include JARs like Bouncy Castle, HTTPComponent and WSS4J - so while it
could be unclear right now what "use" means - there will be "include"
later.


Likewise some of our Maven Central JARs could include shading of say
Apache HTTPComponents, which is EECN-classified.

On 5 May 2016 at 18:48, John D. Ament  wrote:
> Ted,
>
> I think that's my point.  It sounds like taverna doesn't meet the criteria.
>
> John
> On May 5, 2016 13:07, "Ted Dunning"  wrote:
>
>> John,
>>
>> I love what you do and respect what you say, but do you have a citation for
>> that registration requirement?  Taverna isn't distributing JSSE and it
>> allows weak encryption.
>>
>>
>>
>> On Wed, May 4, 2016 at 7:36 PM, John D. Ament 
>> wrote:
>>
>> > That's the thing, JSSE is an add-on encryption component in Java.  If the
>> > product requires it, you have to register it.
>> >
>> > Ideally the product shouldn't require it and make it an optional feature
>> to
>> > enable.
>> >
>> > The latter is just my $0.02
>> >
>> > John
>> > On May 4, 2016 21:30, "Ted Dunning"  wrote:
>> >
>> > I am pretty dubious that simply building a credential store using
>> standard
>> > JSSE requires registration. Same for HTTPS support.
>> >
>> >
>> >
>> > On Wed, May 4, 2016 at 6:23 PM, Ted Dunning 
>> wrote:
>> >
>> > >
>> > > My guess is that this would fall to me.
>> > >
>> > > There is considerable analysis to be done to determine whether filing
>> is
>> > > required.
>> > >
>> > > Are you guys documenting the decision points?
>> > >
>> > >
>> > >
>> > > On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes 
>> > > wrote:
>> > >
>> > >> On 2 May 2016 at 03:23, Stian Soiland-Reyes  wrote:
>> > >>
>> > >> > Formally - would it need to be the Incubator PMC chair sending the
>> > >> > ECCN encryption email?
>> > >>
>> > >> Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?
>> > >>
>> > >> --
>> > >> Stian Soiland-Reyes
>> > >> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> > >> http://orcid.org/-0001-9842-9718
>> > >>
>> > >> -
>> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > >> For additional commands, e-mail: general-h...@incubator.apache.org
>> > >>
>> > >>
>> > >
>> >
>>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: ECCN cryptography reporting?

[John D. Ament]

Ted,

I think that's my point.  It sounds like taverna doesn't meet the criteria.

John
On May 5, 2016 13:07, "Ted Dunning"  wrote:

> John,
>
> I love what you do and respect what you say, but do you have a citation for
> that registration requirement?  Taverna isn't distributing JSSE and it
> allows weak encryption.
>
>
>
> On Wed, May 4, 2016 at 7:36 PM, John D. Ament 
> wrote:
>
> > That's the thing, JSSE is an add-on encryption component in Java.  If the
> > product requires it, you have to register it.
> >
> > Ideally the product shouldn't require it and make it an optional feature
> to
> > enable.
> >
> > The latter is just my $0.02
> >
> > John
> > On May 4, 2016 21:30, "Ted Dunning"  wrote:
> >
> > I am pretty dubious that simply building a credential store using
> standard
> > JSSE requires registration. Same for HTTPS support.
> >
> >
> >
> > On Wed, May 4, 2016 at 6:23 PM, Ted Dunning 
> wrote:
> >
> > >
> > > My guess is that this would fall to me.
> > >
> > > There is considerable analysis to be done to determine whether filing
> is
> > > required.
> > >
> > > Are you guys documenting the decision points?
> > >
> > >
> > >
> > > On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes 
> > > wrote:
> > >
> > >> On 2 May 2016 at 03:23, Stian Soiland-Reyes  wrote:
> > >>
> > >> > Formally - would it need to be the Incubator PMC chair sending the
> > >> > ECCN encryption email?
> > >>
> > >> Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?
> > >>
> > >> --
> > >> Stian Soiland-Reyes
> > >> Apache Taverna (incubating), Apache Commons RDF (incubating)
> > >> http://orcid.org/-0001-9842-9718
> > >>
> > >> -
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >>
> > >
> >
>

Re: ECCN cryptography reporting?

[Ted Dunning]

John,

I love what you do and respect what you say, but do you have a citation for
that registration requirement?  Taverna isn't distributing JSSE and it
allows weak encryption.



On Wed, May 4, 2016 at 7:36 PM, John D. Ament  wrote:

> That's the thing, JSSE is an add-on encryption component in Java.  If the
> product requires it, you have to register it.
>
> Ideally the product shouldn't require it and make it an optional feature to
> enable.
>
> The latter is just my $0.02
>
> John
> On May 4, 2016 21:30, "Ted Dunning"  wrote:
>
> I am pretty dubious that simply building a credential store using standard
> JSSE requires registration. Same for HTTPS support.
>
>
>
> On Wed, May 4, 2016 at 6:23 PM, Ted Dunning  wrote:
>
> >
> > My guess is that this would fall to me.
> >
> > There is considerable analysis to be done to determine whether filing is
> > required.
> >
> > Are you guys documenting the decision points?
> >
> >
> >
> > On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes 
> > wrote:
> >
> >> On 2 May 2016 at 03:23, Stian Soiland-Reyes  wrote:
> >>
> >> > Formally - would it need to be the Incubator PMC chair sending the
> >> > ECCN encryption email?
> >>
> >> Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?
> >>
> >> --
> >> Stian Soiland-Reyes
> >> Apache Taverna (incubating), Apache Commons RDF (incubating)
> >> http://orcid.org/-0001-9842-9718
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> >
>

Re: ECCN cryptography reporting?

[John D. Ament]

That's the thing, JSSE is an add-on encryption component in Java.  If the
product requires it, you have to register it.

Ideally the product shouldn't require it and make it an optional feature to
enable.

The latter is just my $0.02

John
On May 4, 2016 21:30, "Ted Dunning"  wrote:

I am pretty dubious that simply building a credential store using standard
JSSE requires registration. Same for HTTPS support.



On Wed, May 4, 2016 at 6:23 PM, Ted Dunning  wrote:

>
> My guess is that this would fall to me.
>
> There is considerable analysis to be done to determine whether filing is
> required.
>
> Are you guys documenting the decision points?
>
>
>
> On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes 
> wrote:
>
>> On 2 May 2016 at 03:23, Stian Soiland-Reyes  wrote:
>>
>> > Formally - would it need to be the Incubator PMC chair sending the
>> > ECCN encryption email?
>>
>> Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/-0001-9842-9718
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>

Re: ECCN cryptography reporting?

[Ted Dunning]

My guess is that this would fall to me.

There is considerable analysis to be done to determine whether filing is
required.

Are you guys documenting the decision points?



On Wed, May 4, 2016 at 4:45 AM, Stian Soiland-Reyes 
wrote:

> On 2 May 2016 at 03:23, Stian Soiland-Reyes  wrote:
>
> > Formally - would it need to be the Incubator PMC chair sending the
> > ECCN encryption email?
>
> Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/-0001-9842-9718
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: ECCN cryptography reporting?

[Stian Soiland-Reyes]

On 2 May 2016 at 03:23, Stian Soiland-Reyes  wrote:

> Formally - would it need to be the Incubator PMC chair sending the
> ECCN encryption email?

Could anyone from IPMC (e.g. our mentors) do it, or just Ted Dunning?

-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: ECCN cryptography reporting?

[Martin Gainty]

MG>hopefully quick answer

> From: st...@apache.org
> Date: Mon, 2 May 2016 17:45:12 +0100
> Subject: Re: ECCN cryptography reporting?
> To: general@incubator.apache.org
> 
> Thanks!
> 
> We did a dependency clean-up (but not upgrade) as part of license
> review. We want to delay some of the upgrades (e.g. to OSGI 5) until
> after getting the first full command line release out as this is what
> pulls together everything in its lib/.
> 
> (Thus this is also why we need to do the encryption review now).
> 
> 
> I used
> 
> mvn dependency:tree -DoutputFile=`pwd`/target/tree.txt -DappendOutput=true
> 
> to check what dependencies we are using across modules - obviously all
> the Apache ones are easy to check against
> http://www.apache.org/licenses/exports/
> 
> but it's harder to check if any of the others are classified or not
> beyond heavy googling - e.g.
> Jetty is apparantly classified according to
> https://dev.eclipse.org/mhonarc/lists/jetty-users/msg05898.html
MG>you can use 
RAT-REPORTMG>http://creadur.apache.org/rat/apache-rat-plugin/rat-mojo.html
> 
> 
> I wonder if Apache Whisker folks would have any thoughts on how
> generating/checking for encryption export dependencies should be
> simplified - you would think something like a
> META-INF/EXPORT-RESTRICTED in the dependency JARs would work.
> (Although some projects put their encryption classification in NOTICE
> - I understand this is discouraged?)
> 
> 
> Emma seems a bit abandoned (e.g. no Maven 2 plugin) - I know Commons
> now use Cobertura and/or JaCoCo - but perhaps those are better to
> check coverage of your own code rather than the dependencies.
MG>when I first started build/release management 14 years ago I was using Ant 
so  Clover was the only code-coverage 
utilityhttps://confluence.atlassian.com/display/CLOVER/Clover-for-Maven+2+and+3+User's+Guide
MG>emma gained a foothold about 10 years ago when I switched to maven but I 
also wanted code-coverage for Aspectj
MG>I asked the contributors how to add AspectJ but i have yet to hear 
back..MG>this is sad when the author abandons the project and wont let anyone 
else update the codehttp://emma.sourceforge.net/maven-emma-plugin/team-list.html
MG>Cobertura has been mentioned continuously by maven devs so I think this is 
the most implemented used code-coverage plugin 
http://cobertura.github.io/cobertura/
> 
> 
> On 2 May 2016 at 11:22, Martin Gainty <mgai...@hotmail.com> wrote:
> > with other apache products to reduce code bloat and reduce deprecated 
> > packages you might want to run
> > maven dependency:treemvn dependency:tree -Dverbose 
> > https://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html
> > compare delta(s) with
> > emma code coveragehttp://emma.sourceforge.net/
> > as I have some spare cycles let me know if I can be of any assistance
> > Thanks Stian
> > Martin
> >
> >
> >
> >> From: st...@apache.org
> >> Date: Mon, 2 May 2016 03:23:42 +0100
> >> Subject: ECCN cryptography reporting?
> >> To: general@incubator.apache.org
> >>
> >> Hi,
> >>
> >> Taverna is preparing its cryptography registration for US Export purposes:
> >>
> >> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
> >>
> >>
> >> We want to have this sorted before we make the next release candidate
> >> - but we're awaiting LEGAL-250 to see if we can reduce the list of
> >> transitive dependencies in this list - it feels excessive if "anything
> >> that can do https" needs to be listed (that would presumably affect
> >> many more projects)
> >>
> >>
> >> See also http://www.apache.org/dev/crypto.html and already classified
> >> ASF products on http://www.apache.org/licenses/exports/
> >>
> >>
> >>
> >> Formally - would it need to be the Incubator PMC chair sending the
> >> ECCN encryption email?
> >>
> >> I'll let you know when it's ready to send.
> >>
> >> --
> >> Stian Soiland-Reyes
> >> Apache Taverna (incubating), Apache Commons RDF (incubating)
> >> http://orcid.org/-0001-9842-9718
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >
> 
> 
> 
> -- 
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/-0001-9842-9718
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
  

Re: ECCN cryptography reporting?

[Stian Soiland-Reyes]

Thanks!

We did a dependency clean-up (but not upgrade) as part of license
review. We want to delay some of the upgrades (e.g. to OSGI 5) until
after getting the first full command line release out as this is what
pulls together everything in its lib/.

(Thus this is also why we need to do the encryption review now).


I used

mvn dependency:tree -DoutputFile=`pwd`/target/tree.txt -DappendOutput=true

to check what dependencies we are using across modules - obviously all
the Apache ones are easy to check against
http://www.apache.org/licenses/exports/

but it's harder to check if any of the others are classified or not
beyond heavy googling - e.g.
Jetty is apparantly classified according to
https://dev.eclipse.org/mhonarc/lists/jetty-users/msg05898.html


I wonder if Apache Whisker folks would have any thoughts on how
generating/checking for encryption export dependencies should be
simplified - you would think something like a
META-INF/EXPORT-RESTRICTED in the dependency JARs would work.
(Although some projects put their encryption classification in NOTICE
- I understand this is discouraged?)


Emma seems a bit abandoned (e.g. no Maven 2 plugin) - I know Commons
now use Cobertura and/or JaCoCo - but perhaps those are better to
check coverage of your own code rather than the dependencies.



On 2 May 2016 at 11:22, Martin Gainty  wrote:
> with other apache products to reduce code bloat and reduce deprecated 
> packages you might want to run
> maven dependency:treemvn dependency:tree -Dverbose 
> https://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html
> compare delta(s) with
> emma code coveragehttp://emma.sourceforge.net/
> as I have some spare cycles let me know if I can be of any assistance
> Thanks Stian
> Martin
>
>
>
>> From: st...@apache.org
>> Date: Mon, 2 May 2016 03:23:42 +0100
>> Subject: ECCN cryptography reporting?
>> To: general@incubator.apache.org
>>
>> Hi,
>>
>> Taverna is preparing its cryptography registration for US Export purposes:
>>
>> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
>>
>>
>> We want to have this sorted before we make the next release candidate
>> - but we're awaiting LEGAL-250 to see if we can reduce the list of
>> transitive dependencies in this list - it feels excessive if "anything
>> that can do https" needs to be listed (that would presumably affect
>> many more projects)
>>
>>
>> See also http://www.apache.org/dev/crypto.html and already classified
>> ASF products on http://www.apache.org/licenses/exports/
>>
>>
>>
>> Formally - would it need to be the Incubator PMC chair sending the
>> ECCN encryption email?
>>
>> I'll let you know when it's ready to send.
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/-0001-9842-9718
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

RE: ECCN cryptography reporting?

[Martin Gainty]

with other apache products to reduce code bloat and reduce deprecated packages 
you might want to run
maven dependency:treemvn dependency:tree -Dverbose 
https://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html
compare delta(s) with
emma code coveragehttp://emma.sourceforge.net/
as I have some spare cycles let me know if I can be of any assistance
Thanks Stian
Martin 



> From: st...@apache.org
> Date: Mon, 2 May 2016 03:23:42 +0100
> Subject: ECCN cryptography reporting?
> To: general@incubator.apache.org
> 
> Hi,
> 
> Taverna is preparing its cryptography registration for US Export purposes:
> 
> https://cwiki.apache.org/confluence/display/TAVERNADEV/Taverna+Cryptography+review
> 
> 
> We want to have this sorted before we make the next release candidate
> - but we're awaiting LEGAL-250 to see if we can reduce the list of
> transitive dependencies in this list - it feels excessive if "anything
> that can do https" needs to be listed (that would presumably affect
> many more projects)
> 
> 
> See also http://www.apache.org/dev/crypto.html and already classified
> ASF products on http://www.apache.org/licenses/exports/
> 
> 
> 
> Formally - would it need to be the Incubator PMC chair sending the
> ECCN encryption email?
> 
> I'll let you know when it's ready to send.
> 
> -- 
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/-0001-9842-9718
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>