Date   

Re: Proposed release of the Iroha audit report

Olson, Kelly M <kelly.m.olson@...>
 

+1 from me.

Thanks,
Kelly

-----Original Message-----
From: tsc@... [mailto:tsc@...] On Behalf Of David Huseby
Sent: Wednesday, January 2, 2019 6:49 AM
To: Dan Middleton <dan.hyperledger@...>
Cc: Arnaud Le Hors <lehors@...>; Baohua Yang <yangbaohua@...>; Hart Montgomery <hmontgomery@...>; Hyperledger List <tsc@...>; Mark Wagner <mwagner@...>; hyperledger-tsc <hyperledger-tsc@...>
Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit report

By my count I've got yes votes from:
Mark, Arnoud, Hart, Baohua, Dan and Nathan

I'm waiting on:
Binh, Chris, Kelly, Mic, and Silas

Thanks,
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...

On Wed, Jan 2, 2019 at 5:19 AM David Huseby <dhuseby@...> wrote:

So is it officially approved?

Dave

On Fri, Dec 21, 2018 at 8:41 AM Dan Middleton <dan.hyperledger@...> wrote:

+1

On Fri, Dec 14, 2018 at 2:26 PM Baohua Yang <yangbaohua@...> wrote:

LGTM!
Thanks!

On Fri, Dec 14, 2018 at 3:41 PM hmontgomery@... <hmontgomery@...> wrote:

Yeah, I’m pretty much always in favor of releasing security audits if the bugs have been fixed.



Thanks,

Hart



From: tsc@... [mailto:tsc@...]
On Behalf Of mark wagner
Sent: Friday, December 14, 2018 5:30 AM
To: Arnaud Le Hors <lehors@...>
Cc: dhuseby@...; hyperledger-tsc
<hyperledger-tsc@...>; Hyperledger List
<tsc@...>
Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit
report



Does anyone else on the TSC have an opinion on this ?



If we want to streamline TSC calls and do online voting, we actually need to pay attention to the emails...



-mark



On Tue, Dec 11, 2018 at 8:44 AM Arnaud Le Hors <lehors@...> wrote:

SGTM.
--
Arnaud Le Hors - Senior Technical Staff Member, Web & Blockchain
Open Technologies - IBM




From: "mark wagner" <mwagner@...>
To: dhuseby@...
Cc: hyperledger-tsc <hyperledger-tsc@...>
Date: 12/06/2018 07:39 PM
Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit report
Sent by: tsc@...

________________________________




Thanks for the great writeup Dave

As you mentioned that all four issues have been resolved I would
currently vote to release the report. <insert weasel words here> Of
course if others come up with an objection that I had not
considered I may need to factor that into my decision. </weasel
words>

What do others think ?
-mark

On Thu, Dec 6, 2018 at 8:56 AM David Huseby <dhuseby@...> wrote:
Hello TSC,

As part of my visit to the Iroha team, I finalized the Iroha audit
checks with the team and I think that it is time to publish the
Iroha audit report and I would like the TSC's approval to do so. I
recommend that the report be published.

The Iroha audit found four security issues, including one that was
critical enough to require us to issue our first CVE (
https://www.cvedetails.com/cve/CVE-2018-3756/) All four issues
were tracked using our JIRA and resolved earlier this year.

Memory leak in Irohad ( https://jira.hyperledger.org/browse/IR-1)
Nettitude found a memory leak associated with processing a remote
request that creates a very slow potential denial of service.

Multi-signatory transactions can potentially be authorised by
single user ( https://jira.hyperledger.org/browse/IR-2)
This bug exploited some errors in the signature storage and
validation to bypass the transaction signature validation. This is
similar to bug #3 bellow. A malicious user could bypass the
transaction signature checking by signing it multiple times with a
non-deterministic signature scheme.

Vote early, Vote often ( https://jira.hyperledger.org/browse/IR-3)
This is the issue that required a CVE. Nettitude found that by
modifying the ed25519 signature library to use random nonces
instead of message hashes, the signature checking code could be
exploited to accept multiple signatures produced with the same
keypair. This allowed a single malicious node to sign the
malicious transaction multiple times and the other nodes would view
the signatures as unique and valid. This completely bypasses one
part of the byzantine fault tolerance of the blockchain.

IP addresses can be made permanently unusable using the add peer
command ( https://jira.hyperledger.org/browse/IR-4)
This was a small error that is resolved by using DNS names and is
not really a problem to hold up the release.

Cheers!
Dave



---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...





--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc




--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc


--
Best wishes!

Baohua Yang
--
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Re: Proposed release of the Iroha audit report

David Huseby <dhuseby@...>
 

that's actually a good idea.
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...

On Wed, Jan 2, 2019 at 7:52 AM Mark Wagner <mwagner114@...> wrote:

Sounds like we a blockchain based voting app for the TSC. Is there a new lab in our future?

On Wed, Jan 2, 2019, 09:49 David Huseby <dhuseby@...> wrote:

By my count I've got yes votes from:
Mark, Arnoud, Hart, Baohua, Dan and Nathan

I'm waiting on:
Binh, Chris, Kelly, Mic, and Silas

Thanks,
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...

On Wed, Jan 2, 2019 at 5:19 AM David Huseby <dhuseby@...> wrote:

So is it officially approved?

Dave

On Fri, Dec 21, 2018 at 8:41 AM Dan Middleton <dan.hyperledger@...> wrote:

+1

On Fri, Dec 14, 2018 at 2:26 PM Baohua Yang <yangbaohua@...> wrote:

LGTM!
Thanks!

On Fri, Dec 14, 2018 at 3:41 PM hmontgomery@... <hmontgomery@...> wrote:

Yeah, I’m pretty much always in favor of releasing security audits if the bugs have been fixed.



Thanks,

Hart



From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Friday, December 14, 2018 5:30 AM
To: Arnaud Le Hors <lehors@...>
Cc: dhuseby@...; hyperledger-tsc <hyperledger-tsc@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit report



Does anyone else on the TSC have an opinion on this ?



If we want to streamline TSC calls and do online voting, we actually need to pay attention to the emails...



-mark



On Tue, Dec 11, 2018 at 8:44 AM Arnaud Le Hors <lehors@...> wrote:

SGTM.
--
Arnaud Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




From: "mark wagner" <mwagner@...>
To: dhuseby@...
Cc: hyperledger-tsc <hyperledger-tsc@...>
Date: 12/06/2018 07:39 PM
Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit report
Sent by: tsc@...

________________________________




Thanks for the great writeup Dave

As you mentioned that all four issues have been resolved I would currently vote to release the report. <insert weasel words here> Of course if others come up with an objection that I had not considered I may need to factor that into my decision. </weasel words>

What do others think ?
-mark

On Thu, Dec 6, 2018 at 8:56 AM David Huseby <dhuseby@...> wrote:
Hello TSC,

As part of my visit to the Iroha team, I finalized the Iroha audit
checks with the team and I think that it is time to publish the Iroha
audit report and I would like the TSC's approval to do so. I
recommend that the report be published.

The Iroha audit found four security issues, including one that was
critical enough to require us to issue our first CVE (
https://www.cvedetails.com/cve/CVE-2018-3756/) All four issues were
tracked using our JIRA and resolved earlier this year.

Memory leak in Irohad ( https://jira.hyperledger.org/browse/IR-1)
Nettitude found a memory leak associated with processing a remote
request that creates a very slow potential denial of service.

Multi-signatory transactions can potentially be authorised by single
user ( https://jira.hyperledger.org/browse/IR-2)
This bug exploited some errors in the signature storage and validation
to bypass the transaction signature validation. This is similar to
bug #3 bellow. A malicious user could bypass the transaction
signature checking by signing it multiple times with a
non-deterministic signature scheme.

Vote early, Vote often ( https://jira.hyperledger.org/browse/IR-3)
This is the issue that required a CVE. Nettitude found that by
modifying the ed25519 signature library to use random nonces instead
of message hashes, the signature checking code could be exploited to
accept multiple signatures produced with the same keypair. This
allowed a single malicious node to sign the malicious transaction
multiple times and the other nodes would view the signatures as unique
and valid. This completely bypasses one part of the byzantine fault
tolerance of the blockchain.

IP addresses can be made permanently unusable using the add peer
command ( https://jira.hyperledger.org/browse/IR-4)
This was a small error that is resolved by using DNS names and is not
really a problem to hold up the release.

Cheers!
Dave



---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...





--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc




--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc


--
Best wishes!

Baohua Yang
--
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Re: Proposed release of the Iroha audit report

Mark Wagner
 

Sounds like we a blockchain based voting app for the TSC. Is there a new lab in our future?


On Wed, Jan 2, 2019, 09:49 David Huseby <dhuseby@...> wrote:
By my count I've got yes votes from:
Mark, Arnoud, Hart, Baohua, Dan and Nathan

I'm waiting on:
Binh, Chris, Kelly, Mic, and Silas

Thanks,
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...

On Wed, Jan 2, 2019 at 5:19 AM David Huseby <dhuseby@...> wrote:
>
> So is it officially approved?
>
> Dave
>
> On Fri, Dec 21, 2018 at 8:41 AM Dan Middleton <dan.hyperledger@...> wrote:
>>
>> +1
>>
>> On Fri, Dec 14, 2018 at 2:26 PM Baohua Yang <yangbaohua@...> wrote:
>>>
>>> LGTM!
>>> Thanks!
>>>
>>> On Fri, Dec 14, 2018 at 3:41 PM hmontgomery@... <hmontgomery@...> wrote:
>>>>
>>>> Yeah, I’m pretty much always in favor of releasing security audits if the bugs have been fixed.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Hart
>>>>
>>>>
>>>>
>>>> From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
>>>> Sent: Friday, December 14, 2018 5:30 AM
>>>> To: Arnaud Le Hors <lehors@...>
>>>> Cc: dhuseby@...; hyperledger-tsc <hyperledger-tsc@...>; Hyperledger List <tsc@...>
>>>> Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit report
>>>>
>>>>
>>>>
>>>> Does anyone else on the TSC have an opinion on this ?
>>>>
>>>>
>>>>
>>>> If we want to streamline TSC calls and do online voting, we actually need to pay attention to the emails...
>>>>
>>>>
>>>>
>>>> -mark
>>>>
>>>>
>>>>
>>>> On Tue, Dec 11, 2018 at 8:44 AM Arnaud Le Hors <lehors@...> wrote:
>>>>
>>>> SGTM.
>>>> --
>>>> Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM
>>>>
>>>>
>>>>
>>>>
>>>> From:        "mark wagner" <mwagner@...>
>>>> To:        dhuseby@...
>>>> Cc:        hyperledger-tsc <hyperledger-tsc@...>
>>>> Date:        12/06/2018 07:39 PM
>>>> Subject:        Re: [Hyperledger TSC] Proposed release of the Iroha audit report
>>>> Sent by:        tsc@...
>>>>
>>>> ________________________________
>>>>
>>>>
>>>>
>>>>
>>>> Thanks for the great writeup Dave
>>>>
>>>> As you mentioned that all four issues have been resolved I would currently vote to release the report. <insert weasel words here> Of course if others come up with an objection that I had not considered I may need to factor that into my decision. </weasel words>
>>>>
>>>> What do others think ?
>>>> -mark
>>>>
>>>> On Thu, Dec 6, 2018 at 8:56 AM David Huseby <dhuseby@...> wrote:
>>>> Hello TSC,
>>>>
>>>> As part of my visit to the Iroha team, I finalized the Iroha audit
>>>> checks with the team and I think that it is time to publish the Iroha
>>>> audit report and I would like the TSC's approval to do so.  I
>>>> recommend that the report be published.
>>>>
>>>> The Iroha audit found four security issues, including one that was
>>>> critical enough to require us to issue our first CVE (
>>>> https://www.cvedetails.com/cve/CVE-2018-3756/)  All four issues were
>>>> tracked using our JIRA and resolved earlier this year.
>>>>
>>>> Memory leak in Irohad ( https://jira.hyperledger.org/browse/IR-1)
>>>> Nettitude found a memory leak associated with processing a remote
>>>> request that creates a very slow potential denial of service.
>>>>
>>>> Multi-signatory transactions can potentially be authorised by single
>>>> user ( https://jira.hyperledger.org/browse/IR-2)
>>>> This bug exploited some errors in the signature storage and validation
>>>> to bypass the transaction signature validation.  This is similar to
>>>> bug #3 bellow.  A malicious user could bypass the transaction
>>>> signature checking by signing it multiple times with a
>>>> non-deterministic signature scheme.
>>>>
>>>> Vote early, Vote often ( https://jira.hyperledger.org/browse/IR-3)
>>>> This is the issue that required a CVE.  Nettitude found that by
>>>> modifying the ed25519 signature library to use random nonces instead
>>>> of message hashes, the signature checking code could be exploited to
>>>> accept multiple signatures produced with the same keypair.  This
>>>> allowed a single malicious node to sign the malicious transaction
>>>> multiple times and the other nodes would view the signatures as unique
>>>> and valid.  This completely bypasses one part of the byzantine fault
>>>> tolerance of the blockchain.
>>>>
>>>> IP addresses can be made permanently unusable using the add peer
>>>> command ( https://jira.hyperledger.org/browse/IR-4)
>>>> This was a small error that is resolved by using DNS names and is not
>>>> really a problem to hold up the release.
>>>>
>>>> Cheers!
>>>> Dave
>>>>
>>>>
>>>>
>>>> ---
>>>> David Huseby
>>>> Security Maven, Hyperledger
>>>> The Linux Foundation
>>>> +1-206-234-2392
>>>> dhuseby@...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Mark Wagner
>>>> Senior Principal Software Engineer
>>>> Performance and Scalability
>>>> Red Hat, Inc
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Mark Wagner
>>>>
>>>> Senior Principal Software Engineer
>>>>
>>>> Performance and Scalability
>>>>
>>>> Red Hat, Inc
>>>
>>>
>>>
>>> --
>>> Best wishes!
>>>
>>> Baohua Yang
>>>
>
> --
> ---
> David Huseby
> Security Maven, Hyperledger
> The Linux Foundation
> +1-206-234-2392
> dhuseby@...




Re: Proposed release of the Iroha audit report

David Huseby <dhuseby@...>
 

By my count I've got yes votes from:
Mark, Arnoud, Hart, Baohua, Dan and Nathan

I'm waiting on:
Binh, Chris, Kelly, Mic, and Silas

Thanks,
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...

On Wed, Jan 2, 2019 at 5:19 AM David Huseby <dhuseby@...> wrote:

So is it officially approved?

Dave

On Fri, Dec 21, 2018 at 8:41 AM Dan Middleton <dan.hyperledger@...> wrote:

+1

On Fri, Dec 14, 2018 at 2:26 PM Baohua Yang <yangbaohua@...> wrote:

LGTM!
Thanks!

On Fri, Dec 14, 2018 at 3:41 PM hmontgomery@... <hmontgomery@...> wrote:

Yeah, I’m pretty much always in favor of releasing security audits if the bugs have been fixed.



Thanks,

Hart



From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Friday, December 14, 2018 5:30 AM
To: Arnaud Le Hors <lehors@...>
Cc: dhuseby@...; hyperledger-tsc <hyperledger-tsc@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit report



Does anyone else on the TSC have an opinion on this ?



If we want to streamline TSC calls and do online voting, we actually need to pay attention to the emails...



-mark



On Tue, Dec 11, 2018 at 8:44 AM Arnaud Le Hors <lehors@...> wrote:

SGTM.
--
Arnaud Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




From: "mark wagner" <mwagner@...>
To: dhuseby@...
Cc: hyperledger-tsc <hyperledger-tsc@...>
Date: 12/06/2018 07:39 PM
Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit report
Sent by: tsc@...

________________________________




Thanks for the great writeup Dave

As you mentioned that all four issues have been resolved I would currently vote to release the report. <insert weasel words here> Of course if others come up with an objection that I had not considered I may need to factor that into my decision. </weasel words>

What do others think ?
-mark

On Thu, Dec 6, 2018 at 8:56 AM David Huseby <dhuseby@...> wrote:
Hello TSC,

As part of my visit to the Iroha team, I finalized the Iroha audit
checks with the team and I think that it is time to publish the Iroha
audit report and I would like the TSC's approval to do so. I
recommend that the report be published.

The Iroha audit found four security issues, including one that was
critical enough to require us to issue our first CVE (
https://www.cvedetails.com/cve/CVE-2018-3756/) All four issues were
tracked using our JIRA and resolved earlier this year.

Memory leak in Irohad ( https://jira.hyperledger.org/browse/IR-1)
Nettitude found a memory leak associated with processing a remote
request that creates a very slow potential denial of service.

Multi-signatory transactions can potentially be authorised by single
user ( https://jira.hyperledger.org/browse/IR-2)
This bug exploited some errors in the signature storage and validation
to bypass the transaction signature validation. This is similar to
bug #3 bellow. A malicious user could bypass the transaction
signature checking by signing it multiple times with a
non-deterministic signature scheme.

Vote early, Vote often ( https://jira.hyperledger.org/browse/IR-3)
This is the issue that required a CVE. Nettitude found that by
modifying the ed25519 signature library to use random nonces instead
of message hashes, the signature checking code could be exploited to
accept multiple signatures produced with the same keypair. This
allowed a single malicious node to sign the malicious transaction
multiple times and the other nodes would view the signatures as unique
and valid. This completely bypasses one part of the byzantine fault
tolerance of the blockchain.

IP addresses can be made permanently unusable using the add peer
command ( https://jira.hyperledger.org/browse/IR-4)
This was a small error that is resolved by using DNS names and is not
really a problem to hold up the release.

Cheers!
Dave



---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...





--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc




--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc


--
Best wishes!

Baohua Yang
--
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Re: Proposed release of the Iroha audit report

David Huseby <dhuseby@...>
 

So is it officially approved?

Dave

On Fri, Dec 21, 2018 at 8:41 AM Dan Middleton <dan.hyperledger@...> wrote:
+1

On Fri, Dec 14, 2018 at 2:26 PM Baohua Yang <yangbaohua@...> wrote:
LGTM!
Thanks!

On Fri, Dec 14, 2018 at 3:41 PM hmontgomery@... <hmontgomery@...> wrote:

Yeah, I’m pretty much always in favor of releasing security audits if the bugs have been fixed.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Friday, December 14, 2018 5:30 AM
To: Arnaud Le Hors <lehors@...>
Cc: dhuseby@...; hyperledger-tsc <hyperledger-tsc@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit report

 

Does anyone else on the TSC have an opinion on this ?

 

If we want to streamline TSC calls and do online voting, we actually need to pay attention to the emails...

 

-mark

 

On Tue, Dec 11, 2018 at 8:44 AM Arnaud Le Hors <lehors@...> wrote:

SGTM.
--
Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




From:        "mark wagner" <mwagner@...>
To:        dhuseby@...
Cc:        hyperledger-tsc <hyperledger-tsc@...>
Date:        12/06/2018 07:39 PM
Subject:        Re: [Hyperledger TSC] Proposed release of the Iroha audit report
Sent by:        tsc@...





Thanks for the great writeup Dave

As you mentioned that all four issues have been resolved I would currently vote to release the report. <insert weasel words here> Of course if others come up with an objection that I had not considered I may need to factor that into my decision. </weasel words>

What do others think ?
-mark

On Thu, Dec 6, 2018 at 8:56 AM David Huseby <dhuseby@...> wrote:
Hello TSC,

As part of my visit to the Iroha team, I finalized the Iroha audit
checks with the team and I think that it is time to publish the Iroha
audit report and I would like the TSC's approval to do so.  I
recommend that the report be published.

The Iroha audit found four security issues, including one that was
critical enough to require us to issue our first CVE (
https://www.cvedetails.com/cve/CVE-2018-3756/)  All four issues were
tracked using our JIRA and resolved earlier this year.

Memory leak in Irohad ( https://jira.hyperledger.org/browse/IR-1)
Nettitude found a memory leak associated with processing a remote
request that creates a very slow potential denial of service.

Multi-signatory transactions can potentially be authorised by single
user ( https://jira.hyperledger.org/browse/IR-2)
This bug exploited some errors in the signature storage and validation
to bypass the transaction signature validation.  This is similar to
bug #3 bellow.  A malicious user could bypass the transaction
signature checking by signing it multiple times with a
non-deterministic signature scheme.

Vote early, Vote often ( https://jira.hyperledger.org/browse/IR-3)
This is the issue that required a CVE.  Nettitude found that by
modifying the ed25519 signature library to use random nonces instead
of message hashes, the signature checking code could be exploited to
accept multiple signatures produced with the same keypair.  This
allowed a single malicious node to sign the malicious transaction
multiple times and the other nodes would view the signatures as unique
and valid.  This completely bypasses one part of the byzantine fault
tolerance of the blockchain.

IP addresses can be made permanently unusable using the add peer
command ( https://jira.hyperledger.org/browse/IR-4)
This was a small error that is resolved by using DNS names and is not
really a problem to hold up the release.

Cheers!
Dave



---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...





--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc




--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc



--
Best wishes!

Baohua Yang

--
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


Re: [Hyperledger Architecture WG] [Hyperledger Performance and Scale WG] [Hyperledger Identity WG] [Hyperledger TSC] How can we improve diversity in the Hyperledger technical community?

Bob Summerwill <bob@...>
 

Hey David,

As I work through my mailbox I realized that I had still never replied to this mail of yours and just wanted to commend you.

These are some deep observations!

Are there now recurring meetings on community health?


On Wed, Oct 31, 2018 at 12:52 PM David Boswell <dboswell@...> wrote:
I've been looking into the topic of diversity in open source communities and wanted to share some interesting articles and a specific proposal for something our community can do.

To start, here are some important points made by three different articles:

* The basic structure of open, meritocratic and welcoming communities puts more hurdles in place for some people than others.  There's a great article that looks at how the essay 'The Tyranny of Structurelessness', an article about power structures in the feminist movement, applies to open source communities.  I think the most important line in that article is: “First, we need to recognize that while we all strive to be meritocratic when engaging and involving people we are often predisposed to those who act, talk and think like us.”


* Building on that point, open source projects are biased in favor of contributors who show up with an itch to scratch (they already have a thing in mind they want to do).  Sumana Harihareswara has a great article that points out that not everyone has an itch to scratch when they come to a community and we are sending the message that those people aren't real contributors.  But just like people have different learning styles, if we want to have a more diverse group of contributors we need to recognize that there are different contribution styles as well -- otherwise we keep limiting our contributions to the subset of people who participate in the one way we've promoted as 'the right way to contribute'.


* So we need to put new structures in place for new contributors that don't have an itch to scratch the moment they show up in the community.  Many people are interested in Hyperledger and want to get involved but don't know what to do.  We can match those new people with contribution opportunities and with existing contributors to help them.  And data shows that matching people with mentors does increase diversity -- see this recent Economist article that compares effectiveness of different diversity policies.

https://www.economist.com/united-states/2018/09/29/anti-discrimination-statements-by-employers

The proposal then is to create a formal mentoring program in the community where existing contributors share their knowledge with new contributors and connect them with tasks that the projects need help with that fit their interests and skills.  And there are models out there for how to do this in an open source community.  Mozilla had a mentoring effort that scaled to a large size by having a small group of mentors level up a group of people who then mentored others who then leveled up more people.  The attached image of their mentoring structure shows how this scales up quickly.

Thoughts?

Thanks,
David



Re: Big Data, AI and Blockchain

Cupid Chan <cchan@...>
 

Hello Jay:

Thanks for your quick reply! The next step for us to do now is to identify a use case. My inner geek screams to add IoT as well but I am not sure if incorporating more may help or pull back the progress since adding AI and Blockchain to Big Data is already a big jump. With that being said, I am not opposing that at all. Just want to share my thought so that we are all aware. 

Before we jump on a call to discuss further, do you have some material that we can read and prepare?

Regards,

Cupid Chan
CTO, Index Analytics
www.index-analytics.com
3700 Koppers Street, Suite 535
Baltimore, MD, 21227
Cell: 571-357-2426
cchan@...
SBA 8(a) | SBA HUBZone | GSA Schedule 70 | CMMI Level 3


On Dec 20, 2018, at 12:18 PM, Jay Chugh <jay.chugh@...> wrote:

Cupid, 

It is a good initiative to consider. Among my responsibilities at Oracle, I am also responsible for AI and Blockchain Go-to-market initiatives, and would be interested in what you are doing. 
There could be a number of interesting use cases that are enabled by combining AI and Blockchain, both of which require access to data. There are also synergies of AI, Blockchain with IoT in case you were interested to include IoT as well.

Look forward to connecting more on this in the new year.  

Jay Chugh | Senior Director, Product GTM - Blockchain, AI, and IoT Cloud Platforms
Office +1.650.506.0677 | Mobile +1.408.489.9200 
600 Oracle Parkway, M/S 6OP863, Redwood Shores, CA 94065





On Dec 20, 2018, at 6:54 AM, Cupid Chan <cchan@...> wrote:

Hello Hyperledger TSC:

My name is Cupid Chan and I am TSC from Linux Foundation ODPi and also the Champion for BI & AI project in that group. We are planning out our 2019 initiative and one idea I have is to combine AI and Blockchain on top of Big Data. I have connected with Acumos group and got some interested there. I would like to see if you are also interested and/or have already got some material in place so that we don’t need to start from scratch. 

Looking forward to your reply.

Regards,

Cupid Chan
CTO, Index Analytics
www.index-analytics.com
3700 Koppers Street, Suite 535
Baltimore, MD, 21227
Cell: 571-357-2426
cchan@...
SBA 8(a) | SBA HUBZone | GSA Schedule 70 | CMMI Level 3

<Email Footer.png>

The content of this message is confidential. If you have received it by mistake, please inform us by an email reply and then delete the message. It is forbidden to copy, forward, or in any way reveal the contents of this message to anyone. The integrity and security of this email cannot be guaranteed over the Internet. Therefore, the sender will not be held liable for any damage caused by the message - Index Analytics LLC


The content of this message is confidential. If you have received it by mistake, please inform us by an email reply and then delete the message. It is forbidden to copy, forward, or in any way reveal the contents of this message to anyone. The integrity and security of this email cannot be guaranteed over the Internet. Therefore, the sender will not be held liable for any damage caused by the message - Index Analytics LLC


Re: Proposed release of the Iroha audit report

Dan Hyperledger
 

+1


On Fri, Dec 14, 2018 at 2:26 PM Baohua Yang <yangbaohua@...> wrote:
LGTM!
Thanks!

On Fri, Dec 14, 2018 at 3:41 PM hmontgomery@... <hmontgomery@...> wrote:

Yeah, I’m pretty much always in favor of releasing security audits if the bugs have been fixed.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Friday, December 14, 2018 5:30 AM
To: Arnaud Le Hors <lehors@...>
Cc: dhuseby@...; hyperledger-tsc <hyperledger-tsc@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit report

 

Does anyone else on the TSC have an opinion on this ?

 

If we want to streamline TSC calls and do online voting, we actually need to pay attention to the emails...

 

-mark

 

On Tue, Dec 11, 2018 at 8:44 AM Arnaud Le Hors <lehors@...> wrote:

SGTM.
--
Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




From:        "mark wagner" <mwagner@...>
To:        dhuseby@...
Cc:        hyperledger-tsc <hyperledger-tsc@...>
Date:        12/06/2018 07:39 PM
Subject:        Re: [Hyperledger TSC] Proposed release of the Iroha audit report
Sent by:        tsc@...





Thanks for the great writeup Dave

As you mentioned that all four issues have been resolved I would currently vote to release the report. <insert weasel words here> Of course if others come up with an objection that I had not considered I may need to factor that into my decision. </weasel words>

What do others think ?
-mark

On Thu, Dec 6, 2018 at 8:56 AM David Huseby <dhuseby@...> wrote:
Hello TSC,

As part of my visit to the Iroha team, I finalized the Iroha audit
checks with the team and I think that it is time to publish the Iroha
audit report and I would like the TSC's approval to do so.  I
recommend that the report be published.

The Iroha audit found four security issues, including one that was
critical enough to require us to issue our first CVE (
https://www.cvedetails.com/cve/CVE-2018-3756/)  All four issues were
tracked using our JIRA and resolved earlier this year.

Memory leak in Irohad ( https://jira.hyperledger.org/browse/IR-1)
Nettitude found a memory leak associated with processing a remote
request that creates a very slow potential denial of service.

Multi-signatory transactions can potentially be authorised by single
user ( https://jira.hyperledger.org/browse/IR-2)
This bug exploited some errors in the signature storage and validation
to bypass the transaction signature validation.  This is similar to
bug #3 bellow.  A malicious user could bypass the transaction
signature checking by signing it multiple times with a
non-deterministic signature scheme.

Vote early, Vote often ( https://jira.hyperledger.org/browse/IR-3)
This is the issue that required a CVE.  Nettitude found that by
modifying the ed25519 signature library to use random nonces instead
of message hashes, the signature checking code could be exploited to
accept multiple signatures produced with the same keypair.  This
allowed a single malicious node to sign the malicious transaction
multiple times and the other nodes would view the signatures as unique
and valid.  This completely bypasses one part of the byzantine fault
tolerance of the blockchain.

IP addresses can be made permanently unusable using the add peer
command ( https://jira.hyperledger.org/browse/IR-4)
This was a small error that is resolved by using DNS names and is not
really a problem to hold up the release.

Cheers!
Dave



---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...





--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc




--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc



--
Best wishes!

Baohua Yang


Re: Big Data, AI and Blockchain

jay.chugh@...
 

Cupid, 

It is a good initiative to consider. Among my responsibilities at Oracle, I am also responsible for AI and Blockchain Go-to-market initiatives, and would be interested in what you are doing. 
There could be a number of interesting use cases that are enabled by combining AI and Blockchain, both of which require access to data. There are also synergies of AI, Blockchain with IoT in case you were interested to include IoT as well.

Look forward to connecting more on this in the new year.  

Jay Chugh | Senior Director, Product GTM - Blockchain, AI, and IoT Cloud Platforms
Office +1.650.506.0677 | Mobile +1.408.489.9200 
600 Oracle Parkway, M/S 6OP863, Redwood Shores, CA 94065





On Dec 20, 2018, at 6:54 AM, Cupid Chan <cchan@...> wrote:

Hello Hyperledger TSC:

My name is Cupid Chan and I am TSC from Linux Foundation ODPi and also the Champion for BI & AI project in that group. We are planning out our 2019 initiative and one idea I have is to combine AI and Blockchain on top of Big Data. I have connected with Acumos group and got some interested there. I would like to see if you are also interested and/or have already got some material in place so that we don’t need to start from scratch. 

Looking forward to your reply.

Regards,

Cupid Chan
CTO, Index Analytics
www.index-analytics.com
3700 Koppers Street, Suite 535
Baltimore, MD, 21227
Cell: 571-357-2426
cchan@...
SBA 8(a) | SBA HUBZone | GSA Schedule 70 | CMMI Level 3

<Email Footer.png>

The content of this message is confidential. If you have received it by mistake, please inform us by an email reply and then delete the message. It is forbidden to copy, forward, or in any way reveal the contents of this message to anyone. The integrity and security of this email cannot be guaranteed over the Internet. Therefore, the sender will not be held liable for any damage caused by the message - Index Analytics LLC


Big Data, AI and Blockchain

Cupid Chan <cchan@...>
 

Hello Hyperledger TSC:

My name is Cupid Chan and I am TSC from Linux Foundation ODPi and also the Champion for BI & AI project in that group. We are planning out our 2019 initiative and one idea I have is to combine AI and Blockchain on top of Big Data. I have connected with Acumos group and got some interested there. I would like to see if you are also interested and/or have already got some material in place so that we don’t need to start from scratch. 

Looking forward to your reply.

Regards,

Cupid Chan
CTO, Index Analytics
www.index-analytics.com
3700 Koppers Street, Suite 535
Baltimore, MD, 21227
Cell: 571-357-2426
cchan@...
SBA 8(a) | SBA HUBZone | GSA Schedule 70 | CMMI Level 3


The content of this message is confidential. If you have received it by mistake, please inform us by an email reply and then delete the message. It is forbidden to copy, forward, or in any way reveal the contents of this message to anyone. The integrity and security of this email cannot be guaranteed over the Internet. Therefore, the sender will not be held liable for any damage caused by the message - Index Analytics LLC


Re: Scope Clarification Framework from the GB to the TSC

Duncan Johnston-Watt
 

Ian

It follows from this GB guidance that top level Tools projects also need to be seen to support multiple Frameworks rather than being overly focused on one. 

Best 
--
Duncan Johnston-Watt
CEO, Blockchain Technology Partners
+44 777 190 2653 | @duncanjw


On 17 Dec 2018, at 21:37, Middleton, Dan <dan.middleton@...> wrote:

Hi Ian,

All of the TSC votes are public (at the meeting and recorded in our minutes):
https://lists.hyperledger.org/g/tsc/message/1889

In this case we had one abstention and one absent.

 

Hyperledger labs are modeled after the Apache Project’s labs

http://labs.apache.org/

It’s meant to be an easy place for the community to hack stuff together either on a path to becoming a project or for other technical exploratory reasons.

 

This is a top level project and (as soon as we have a name for it) it will join the other 10 projects in the greenhouse visible on our landing page:

https://www.hyperledger.org/

 

As a top level project it enters the formal project lifecycle and receives the Hyperledger support (community outreach, marketing, security review, etc.) which goes along with that responsibility.

https://wiki.hyperledger.org/community/project-lifecycle

 

 

Regards,

Dan

 

From: <tsc@...> on behalf of Ian Allison <ian@...>
Date: Monday, December 17, 2018 at 1:07 PM
To: "Bowman, Mic" <mic.bowman@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Scope Clarification Framework from the GB to the TSC

 

hi Guys,

Can I ask - How many votes were there in total, for and against sawtooth supply chain? And when did the vote take place? Also, what is the name of the top tier Sawtooth got elevated to, and what does it mean to get put there versus the lab?

 

This is not for quoting but background for a story - many thanks Ian 

 

On Mon, Dec 17, 2018 at 5:17 PM Mic Bowman <mic.bowman@...> wrote:

Thanks!

 

From: tsc@... [mailto:tsc@...] On Behalf Of Brian Behlendorf
Sent: Monday, December 17, 2018 5:52 AM
To: tsc@...
Subject: [Hyperledger TSC] Scope Clarification Framework from the GB to the TSC

 

Dear TSC,

 

I am sending the below on behalf of the Hyperledger Governing Board.  Hope it provides some clarity to the new as-yet-unnamed project related to supply chain functionality that was approved last week, and future project proposals.

Brian

 

 

Dear Hyperledger Technical Steering Committee,

 

The Governing Board has reviewed the Hyperledger charter, section 1, paragraph a, which stipulates that one part of the mission of Hyperledger is to: "create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions."

 

The Governing Board believes that the terms "framework and code base" can refer not just to the systems used to build distributed ledger and smart contract engines (such as the existing projects labeled "Frameworks" on the Hyperledger project list), and not just to tools that make using these frameworks easier (such as the existing projects labeled as "Tools" in the project list), but may also include libraries, asset descriptions, templates, proof of concept code, demo code, and even code that presents polished user interfaces to non-technical end users.  So long as distributed ledger functionality is a core part or unavoidable dependency of these technologies, they are within the scope of Hyperledger as defined in the Charter, section 1, paragraph a.  This is true for both code placed into Hyperledger Labs, and for a Top Level Project.

 

However, the GB also believes that for practical reasons, the TSC should be particularly demanding of the relevancy of proposed Top Level Projects to the Hyperledger mission when considering projects that may lie closer and closer to specific application use cases and end-users, and further away from being classified as a "framework", "tool", "library", or similar.  Projects consume real resources on both the part of the TSC and Hyperledger staff and budget in order to give them the same level of promotion and treatment that other projects have. As such, please consider that:

 

·         Projects should not serve a very narrow set of use cases

·         Projects should not consist of source code mostly unrelated to blockchain functionality

·         Projects should not be regionally specific

·         Projects should be generalizable to multiple industries

·         Projects should be substantial and not just samples that could be included in the relevant framework or proposed as a Lab instead

·         Projects must follow the Charter and use Hyperledger’s repositories and governance model.

·         Projects should accelerate the ability for multiple businesses to create multiple different applications. For example, product traceability, directory services, tokenization, multi-sided marketplaces are a better fit than a project candidate more narrowly focused on one use case or industry, or built by and for a small number of organizations.

 

This should be the guiding framework for consideration when the TSC is considering new projects. It is not a strict policy, but serves to help identify generally which types of project should be encouraged when there is any doubt.

 

Great frameworks need great production applications, to not only demonstrate the power of the framework, but to test the assumptions about what kind of functionality should be baked into frameworks rather than left to applications on top.  Having a few such production applications at Hyperledger likely will make the Hyperledger frameworks better, and easier to adopt.  But it will also be a successful outcome for Hyperledger when we see other thriving open source projects hosted on Github or elsewhere who are using Hyperledger frameworks and code.  

 

The Governing Board trusts the TSC to use this guidance to determine which projects are appropriate for admittance as Top Level Projects.

 

Best,

 

The Hyperledger Governing Board

 

 

 

 

 

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


 

--

Ian Allison 

Reporter | CoinDesk

Direct:  +44 203 894 5977

Mobile: +44 742 768 6132

 

CoinDesk: News -- Events -- Research

 


Re: Scope Clarification Framework from the GB to the TSC

Middleton, Dan <dan.middleton@...>
 

Hi Ian,

All of the TSC votes are public (at the meeting and recorded in our minutes):
https://lists.hyperledger.org/g/tsc/message/1889

In this case we had one abstention and one absent.

 

Hyperledger labs are modeled after the Apache Project’s labs

http://labs.apache.org/

It’s meant to be an easy place for the community to hack stuff together either on a path to becoming a project or for other technical exploratory reasons.

 

This is a top level project and (as soon as we have a name for it) it will join the other 10 projects in the greenhouse visible on our landing page:

https://www.hyperledger.org/

 

As a top level project it enters the formal project lifecycle and receives the Hyperledger support (community outreach, marketing, security review, etc.) which goes along with that responsibility.

https://wiki.hyperledger.org/community/project-lifecycle

 

 

Regards,

Dan

 

From: <tsc@...> on behalf of Ian Allison <ian@...>
Date: Monday, December 17, 2018 at 1:07 PM
To: "Bowman, Mic" <mic.bowman@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Scope Clarification Framework from the GB to the TSC

 

hi Guys,

Can I ask - How many votes were there in total, for and against sawtooth supply chain? And when did the vote take place? Also, what is the name of the top tier Sawtooth got elevated to, and what does it mean to get put there versus the lab?

 

This is not for quoting but background for a story - many thanks Ian 

 

On Mon, Dec 17, 2018 at 5:17 PM Mic Bowman <mic.bowman@...> wrote:

Thanks!

 

From: tsc@... [mailto:tsc@...] On Behalf Of Brian Behlendorf
Sent: Monday, December 17, 2018 5:52 AM
To: tsc@...
Subject: [Hyperledger TSC] Scope Clarification Framework from the GB to the TSC

 

Dear TSC,

 

I am sending the below on behalf of the Hyperledger Governing Board.  Hope it provides some clarity to the new as-yet-unnamed project related to supply chain functionality that was approved last week, and future project proposals.

Brian

 

 

Dear Hyperledger Technical Steering Committee,

 

The Governing Board has reviewed the Hyperledger charter, section 1, paragraph a, which stipulates that one part of the mission of Hyperledger is to: "create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions."

 

The Governing Board believes that the terms "framework and code base" can refer not just to the systems used to build distributed ledger and smart contract engines (such as the existing projects labeled "Frameworks" on the Hyperledger project list), and not just to tools that make using these frameworks easier (such as the existing projects labeled as "Tools" in the project list), but may also include libraries, asset descriptions, templates, proof of concept code, demo code, and even code that presents polished user interfaces to non-technical end users.  So long as distributed ledger functionality is a core part or unavoidable dependency of these technologies, they are within the scope of Hyperledger as defined in the Charter, section 1, paragraph a.  This is true for both code placed into Hyperledger Labs, and for a Top Level Project.

 

However, the GB also believes that for practical reasons, the TSC should be particularly demanding of the relevancy of proposed Top Level Projects to the Hyperledger mission when considering projects that may lie closer and closer to specific application use cases and end-users, and further away from being classified as a "framework", "tool", "library", or similar.  Projects consume real resources on both the part of the TSC and Hyperledger staff and budget in order to give them the same level of promotion and treatment that other projects have. As such, please consider that:

 

·         Projects should not serve a very narrow set of use cases

·         Projects should not consist of source code mostly unrelated to blockchain functionality

·         Projects should not be regionally specific

·         Projects should be generalizable to multiple industries

·         Projects should be substantial and not just samples that could be included in the relevant framework or proposed as a Lab instead

·         Projects must follow the Charter and use Hyperledger’s repositories and governance model.

·         Projects should accelerate the ability for multiple businesses to create multiple different applications. For example, product traceability, directory services, tokenization, multi-sided marketplaces are a better fit than a project candidate more narrowly focused on one use case or industry, or built by and for a small number of organizations.

 

This should be the guiding framework for consideration when the TSC is considering new projects. It is not a strict policy, but serves to help identify generally which types of project should be encouraged when there is any doubt.

 

Great frameworks need great production applications, to not only demonstrate the power of the framework, but to test the assumptions about what kind of functionality should be baked into frameworks rather than left to applications on top.  Having a few such production applications at Hyperledger likely will make the Hyperledger frameworks better, and easier to adopt.  But it will also be a successful outcome for Hyperledger when we see other thriving open source projects hosted on Github or elsewhere who are using Hyperledger frameworks and code.  

 

The Governing Board trusts the TSC to use this guidance to determine which projects are appropriate for admittance as Top Level Projects.

 

Best,

 

The Hyperledger Governing Board

 

 

 

 

 

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


 

--

Ian Allison 

Reporter | CoinDesk

Direct:  +44 203 894 5977

Mobile: +44 742 768 6132

 

CoinDesk: News -- Events -- Research

 


Re: Scope Clarification Framework from the GB to the TSC

Ian Allison
 

hi Guys,
Can I ask - How many votes were there in total, for and against sawtooth supply chain? And when did the vote take place? Also, what is the name of the top tier Sawtooth got elevated to, and what does it mean to get put there versus the lab?

This is not for quoting but background for a story - many thanks Ian 


On Mon, Dec 17, 2018 at 5:17 PM Mic Bowman <mic.bowman@...> wrote:

Thanks!

 

From: tsc@... [mailto:tsc@...] On Behalf Of Brian Behlendorf
Sent: Monday, December 17, 2018 5:52 AM
To: tsc@...
Subject: [Hyperledger TSC] Scope Clarification Framework from the GB to the TSC

 

Dear TSC,

 

I am sending the below on behalf of the Hyperledger Governing Board.  Hope it provides some clarity to the new as-yet-unnamed project related to supply chain functionality that was approved last week, and future project proposals.

Brian

 

 

Dear Hyperledger Technical Steering Committee,

 

The Governing Board has reviewed the Hyperledger charter, section 1, paragraph a, which stipulates that one part of the mission of Hyperledger is to: "create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions."

 

The Governing Board believes that the terms "framework and code base" can refer not just to the systems used to build distributed ledger and smart contract engines (such as the existing projects labeled "Frameworks" on the Hyperledger project list), and not just to tools that make using these frameworks easier (such as the existing projects labeled as "Tools" in the project list), but may also include libraries, asset descriptions, templates, proof of concept code, demo code, and even code that presents polished user interfaces to non-technical end users.  So long as distributed ledger functionality is a core part or unavoidable dependency of these technologies, they are within the scope of Hyperledger as defined in the Charter, section 1, paragraph a.  This is true for both code placed into Hyperledger Labs, and for a Top Level Project.

 

However, the GB also believes that for practical reasons, the TSC should be particularly demanding of the relevancy of proposed Top Level Projects to the Hyperledger mission when considering projects that may lie closer and closer to specific application use cases and end-users, and further away from being classified as a "framework", "tool", "library", or similar.  Projects consume real resources on both the part of the TSC and Hyperledger staff and budget in order to give them the same level of promotion and treatment that other projects have. As such, please consider that:

 

·         Projects should not serve a very narrow set of use cases

·         Projects should not consist of source code mostly unrelated to blockchain functionality

·         Projects should not be regionally specific

·         Projects should be generalizable to multiple industries

·         Projects should be substantial and not just samples that could be included in the relevant framework or proposed as a Lab instead

·         Projects must follow the Charter and use Hyperledger’s repositories and governance model.

·         Projects should accelerate the ability for multiple businesses to create multiple different applications. For example, product traceability, directory services, tokenization, multi-sided marketplaces are a better fit than a project candidate more narrowly focused on one use case or industry, or built by and for a small number of organizations.

 

This should be the guiding framework for consideration when the TSC is considering new projects. It is not a strict policy, but serves to help identify generally which types of project should be encouraged when there is any doubt.

 

Great frameworks need great production applications, to not only demonstrate the power of the framework, but to test the assumptions about what kind of functionality should be baked into frameworks rather than left to applications on top.  Having a few such production applications at Hyperledger likely will make the Hyperledger frameworks better, and easier to adopt.  But it will also be a successful outcome for Hyperledger when we see other thriving open source projects hosted on Github or elsewhere who are using Hyperledger frameworks and code.  

 

The Governing Board trusts the TSC to use this guidance to determine which projects are appropriate for admittance as Top Level Projects.

 

Best,

 

The Hyperledger Governing Board

 

 

 

 

 

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf



--
Ian Allison 
Reporter | CoinDesk
Direct:  +44 203 894 5977
Mobile: +44 742 768 6132

CoinDesk: News -- Events -- Research


Re: Scope Clarification Framework from the GB to the TSC

Mic Bowman
 

Thanks!

 

From: tsc@... [mailto:tsc@...] On Behalf Of Brian Behlendorf
Sent: Monday, December 17, 2018 5:52 AM
To: tsc@...
Subject: [Hyperledger TSC] Scope Clarification Framework from the GB to the TSC

 

Dear TSC,

 

I am sending the below on behalf of the Hyperledger Governing Board.  Hope it provides some clarity to the new as-yet-unnamed project related to supply chain functionality that was approved last week, and future project proposals.

Brian

 

 

Dear Hyperledger Technical Steering Committee,

 

The Governing Board has reviewed the Hyperledger charter, section 1, paragraph a, which stipulates that one part of the mission of Hyperledger is to: "create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions."

 

The Governing Board believes that the terms "framework and code base" can refer not just to the systems used to build distributed ledger and smart contract engines (such as the existing projects labeled "Frameworks" on the Hyperledger project list), and not just to tools that make using these frameworks easier (such as the existing projects labeled as "Tools" in the project list), but may also include libraries, asset descriptions, templates, proof of concept code, demo code, and even code that presents polished user interfaces to non-technical end users.  So long as distributed ledger functionality is a core part or unavoidable dependency of these technologies, they are within the scope of Hyperledger as defined in the Charter, section 1, paragraph a.  This is true for both code placed into Hyperledger Labs, and for a Top Level Project.

 

However, the GB also believes that for practical reasons, the TSC should be particularly demanding of the relevancy of proposed Top Level Projects to the Hyperledger mission when considering projects that may lie closer and closer to specific application use cases and end-users, and further away from being classified as a "framework", "tool", "library", or similar.  Projects consume real resources on both the part of the TSC and Hyperledger staff and budget in order to give them the same level of promotion and treatment that other projects have. As such, please consider that:

 

·         Projects should not serve a very narrow set of use cases

·         Projects should not consist of source code mostly unrelated to blockchain functionality

·         Projects should not be regionally specific

·         Projects should be generalizable to multiple industries

·         Projects should be substantial and not just samples that could be included in the relevant framework or proposed as a Lab instead

·         Projects must follow the Charter and use Hyperledger’s repositories and governance model.

·         Projects should accelerate the ability for multiple businesses to create multiple different applications. For example, product traceability, directory services, tokenization, multi-sided marketplaces are a better fit than a project candidate more narrowly focused on one use case or industry, or built by and for a small number of organizations.

 

This should be the guiding framework for consideration when the TSC is considering new projects. It is not a strict policy, but serves to help identify generally which types of project should be encouraged when there is any doubt.

 

Great frameworks need great production applications, to not only demonstrate the power of the framework, but to test the assumptions about what kind of functionality should be baked into frameworks rather than left to applications on top.  Having a few such production applications at Hyperledger likely will make the Hyperledger frameworks better, and easier to adopt.  But it will also be a successful outcome for Hyperledger when we see other thriving open source projects hosted on Github or elsewhere who are using Hyperledger frameworks and code.  

 

The Governing Board trusts the TSC to use this guidance to determine which projects are appropriate for admittance as Top Level Projects.

 

Best,

 

The Hyperledger Governing Board

 

 

 

 

 

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Scope Clarification Framework from the GB to the TSC

Brian Behlendorf
 

Dear TSC,


I am sending the below on behalf of the Hyperledger Governing Board.  Hope it provides some clarity to the new as-yet-unnamed project related to supply chain functionality that was approved last week, and future project proposals.

Brian



Dear Hyperledger Technical Steering Committee,


The Governing Board has reviewed the Hyperledger charter, section 1, paragraph a, which stipulates that one part of the mission of Hyperledger is to: "create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions."


The Governing Board believes that the terms "framework and code base" can refer not just to the systems used to build distributed ledger and smart contract engines (such as the existing projects labeled "Frameworks" on the Hyperledger project list), and not just to tools that make using these frameworks easier (such as the existing projects labeled as "Tools" in the project list), but may also include libraries, asset descriptions, templates, proof of concept code, demo code, and even code that presents polished user interfaces to non-technical end users.  So long as distributed ledger functionality is a core part or unavoidable dependency of these technologies, they are within the scope of Hyperledger as defined in the Charter, section 1, paragraph a. This is true for both code placed into Hyperledger Labs, and for a Top Level Project.


However, the GB also believes that for practical reasons, the TSC should be particularly demanding of the relevancy of proposed Top Level Projects to the Hyperledger mission when considering projects that may lie closer and closer to specific application use cases and end-users, and further away from being classified as a "framework", "tool", "library", or similar.  Projects consume real resources on both the part of the TSC and Hyperledger staff and budget in order to give them the same level of promotion and treatment that other projects have. As such, please consider that:


  • Projects should not serve a very narrow set of use cases

  • Projects should not consist of source code mostly unrelated to blockchain functionality

  • Projects should not be regionally specific

  • Projects should be generalizable to multiple industries

  • Projects should be substantial and not just samples that could be included in the relevant framework or proposed as a Lab instead

  • Projects must follow the Charter and use Hyperledger’s repositories and governance model.

  • Projects should accelerate the ability for multiple businesses to create multiple different applications. For example, product traceability, directory services, tokenization, multi-sided marketplaces are a better fit than a project candidate more narrowly focused on one use case or industry, or built by and for a small number of organizations.


This should be the guiding framework for consideration when the TSC is considering new projects. It is not a strict policy, but serves to help identify generally which types of project should be encouraged when there is any doubt.


Great frameworks need great production applications, to not only demonstrate the power of the framework, but to test the assumptions about what kind of functionality should be baked into frameworks rather than left to applications on top.  Having a few such production applications at Hyperledger likely will make the Hyperledger frameworks better, and easier to adopt. But it will also be a successful outcome for Hyperledger when we see other thriving open source projects hosted on Github or elsewhere who are using Hyperledger frameworks and code.  


The Governing Board trusts the TSC to use this guidance to determine which projects are appropriate for admittance as Top Level Projects.


Best,


The Hyperledger Governing Board

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: Proposed release of the Iroha audit report

Baohua Yang
 

LGTM!
Thanks!

On Fri, Dec 14, 2018 at 3:41 PM hmontgomery@... <hmontgomery@...> wrote:

Yeah, I’m pretty much always in favor of releasing security audits if the bugs have been fixed.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Friday, December 14, 2018 5:30 AM
To: Arnaud Le Hors <lehors@...>
Cc: dhuseby@...; hyperledger-tsc <hyperledger-tsc@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit report

 

Does anyone else on the TSC have an opinion on this ?

 

If we want to streamline TSC calls and do online voting, we actually need to pay attention to the emails...

 

-mark

 

On Tue, Dec 11, 2018 at 8:44 AM Arnaud Le Hors <lehors@...> wrote:

SGTM.
--
Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




From:        "mark wagner" <mwagner@...>
To:        dhuseby@...
Cc:        hyperledger-tsc <hyperledger-tsc@...>
Date:        12/06/2018 07:39 PM
Subject:        Re: [Hyperledger TSC] Proposed release of the Iroha audit report
Sent by:        tsc@...





Thanks for the great writeup Dave

As you mentioned that all four issues have been resolved I would currently vote to release the report. <insert weasel words here> Of course if others come up with an objection that I had not considered I may need to factor that into my decision. </weasel words>

What do others think ?
-mark

On Thu, Dec 6, 2018 at 8:56 AM David Huseby <dhuseby@...> wrote:
Hello TSC,

As part of my visit to the Iroha team, I finalized the Iroha audit
checks with the team and I think that it is time to publish the Iroha
audit report and I would like the TSC's approval to do so.  I
recommend that the report be published.

The Iroha audit found four security issues, including one that was
critical enough to require us to issue our first CVE (
https://www.cvedetails.com/cve/CVE-2018-3756/)  All four issues were
tracked using our JIRA and resolved earlier this year.

Memory leak in Irohad ( https://jira.hyperledger.org/browse/IR-1)
Nettitude found a memory leak associated with processing a remote
request that creates a very slow potential denial of service.

Multi-signatory transactions can potentially be authorised by single
user ( https://jira.hyperledger.org/browse/IR-2)
This bug exploited some errors in the signature storage and validation
to bypass the transaction signature validation.  This is similar to
bug #3 bellow.  A malicious user could bypass the transaction
signature checking by signing it multiple times with a
non-deterministic signature scheme.

Vote early, Vote often ( https://jira.hyperledger.org/browse/IR-3)
This is the issue that required a CVE.  Nettitude found that by
modifying the ed25519 signature library to use random nonces instead
of message hashes, the signature checking code could be exploited to
accept multiple signatures produced with the same keypair.  This
allowed a single malicious node to sign the malicious transaction
multiple times and the other nodes would view the signatures as unique
and valid.  This completely bypasses one part of the byzantine fault
tolerance of the blockchain.

IP addresses can be made permanently unusable using the add peer
command ( https://jira.hyperledger.org/browse/IR-4)
This was a small error that is resolved by using DNS names and is not
really a problem to hold up the release.

Cheers!
Dave



---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...





--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc




--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc



--
Best wishes!

Baohua Yang


Re: Proposed release of the Iroha audit report

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

Yeah, I’m pretty much always in favor of releasing security audits if the bugs have been fixed.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Friday, December 14, 2018 5:30 AM
To: Arnaud Le Hors <lehors@...>
Cc: dhuseby@...; hyperledger-tsc <hyperledger-tsc@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit report

 

Does anyone else on the TSC have an opinion on this ?

 

If we want to streamline TSC calls and do online voting, we actually need to pay attention to the emails...

 

-mark

 

On Tue, Dec 11, 2018 at 8:44 AM Arnaud Le Hors <lehors@...> wrote:

SGTM.
--
Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




From:        "mark wagner" <mwagner@...>
To:        dhuseby@...
Cc:        hyperledger-tsc <hyperledger-tsc@...>
Date:        12/06/2018 07:39 PM
Subject:        Re: [Hyperledger TSC] Proposed release of the Iroha audit report
Sent by:        tsc@...





Thanks for the great writeup Dave

As you mentioned that all four issues have been resolved I would currently vote to release the report. <insert weasel words here> Of course if others come up with an objection that I had not considered I may need to factor that into my decision. </weasel words>

What do others think ?
-mark

On Thu, Dec 6, 2018 at 8:56 AM David Huseby <dhuseby@...> wrote:
Hello TSC,

As part of my visit to the Iroha team, I finalized the Iroha audit
checks with the team and I think that it is time to publish the Iroha
audit report and I would like the TSC's approval to do so.  I
recommend that the report be published.

The Iroha audit found four security issues, including one that was
critical enough to require us to issue our first CVE (
https://www.cvedetails.com/cve/CVE-2018-3756/)  All four issues were
tracked using our JIRA and resolved earlier this year.

Memory leak in Irohad ( https://jira.hyperledger.org/browse/IR-1)
Nettitude found a memory leak associated with processing a remote
request that creates a very slow potential denial of service.

Multi-signatory transactions can potentially be authorised by single
user ( https://jira.hyperledger.org/browse/IR-2)
This bug exploited some errors in the signature storage and validation
to bypass the transaction signature validation.  This is similar to
bug #3 bellow.  A malicious user could bypass the transaction
signature checking by signing it multiple times with a
non-deterministic signature scheme.

Vote early, Vote often ( https://jira.hyperledger.org/browse/IR-3)
This is the issue that required a CVE.  Nettitude found that by
modifying the ed25519 signature library to use random nonces instead
of message hashes, the signature checking code could be exploited to
accept multiple signatures produced with the same keypair.  This
allowed a single malicious node to sign the malicious transaction
multiple times and the other nodes would view the signatures as unique
and valid.  This completely bypasses one part of the byzantine fault
tolerance of the blockchain.

IP addresses can be made permanently unusable using the add peer
command ( https://jira.hyperledger.org/browse/IR-4)
This was a small error that is resolved by using DNS names and is not
really a problem to hold up the release.

Cheers!
Dave



---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...





--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc




--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc


Re: Proposed release of the Iroha audit report

mark wagner <mwagner@...>
 

Does anyone else on the TSC have an opinion on this ?

If we want to streamline TSC calls and do online voting, we actually need to pay attention to the emails...

-mark


On Tue, Dec 11, 2018 at 8:44 AM Arnaud Le Hors <lehors@...> wrote:
SGTM.
--
Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




From:        "mark wagner" <mwagner@...>
To:        dhuseby@...
Cc:        hyperledger-tsc <hyperledger-tsc@...>
Date:        12/06/2018 07:39 PM
Subject:        Re: [Hyperledger TSC] Proposed release of the Iroha audit report
Sent by:        tsc@...




Thanks for the great writeup Dave

As you mentioned that all four issues have been resolved I would currently vote to release the report. <insert weasel words here> Of course if others come up with an objection that I had not considered I may need to factor that into my decision. </weasel words>

What do others think ?
-mark

On Thu, Dec 6, 2018 at 8:56 AM David Huseby <dhuseby@...> wrote:
Hello TSC,

As part of my visit to the Iroha team, I finalized the Iroha audit
checks with the team and I think that it is time to publish the Iroha
audit report and I would like the TSC's approval to do so.  I
recommend that the report be published.

The Iroha audit found four security issues, including one that was
critical enough to require us to issue our first CVE (
https://www.cvedetails.com/cve/CVE-2018-3756/)  All four issues were
tracked using our JIRA and resolved earlier this year.

Memory leak in Irohad ( https://jira.hyperledger.org/browse/IR-1)
Nettitude found a memory leak associated with processing a remote
request that creates a very slow potential denial of service.

Multi-signatory transactions can potentially be authorised by single
user ( https://jira.hyperledger.org/browse/IR-2)
This bug exploited some errors in the signature storage and validation
to bypass the transaction signature validation.  This is similar to
bug #3 bellow.  A malicious user could bypass the transaction
signature checking by signing it multiple times with a
non-deterministic signature scheme.

Vote early, Vote often ( https://jira.hyperledger.org/browse/IR-3)
This is the issue that required a CVE.  Nettitude found that by
modifying the ed25519 signature library to use random nonces instead
of message hashes, the signature checking code could be exploited to
accept multiple signatures produced with the same keypair.  This
allowed a single malicious node to sign the malicious transaction
multiple times and the other nodes would view the signatures as unique
and valid.  This completely bypasses one part of the byzantine fault
tolerance of the blockchain.

IP addresses can be made permanently unusable using the add peer
command ( https://jira.hyperledger.org/browse/IR-4)
This was a small error that is resolved by using DNS names and is not
really a problem to hold up the release.

Cheers!
Dave



---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...





--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc





--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc


Re: Proposed release of the Iroha audit report

Arnaud Le Hors
 

SGTM.
--
Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM




From:        "mark wagner" <mwagner@...>
To:        dhuseby@...
Cc:        hyperledger-tsc <hyperledger-tsc@...>
Date:        12/06/2018 07:39 PM
Subject:        Re: [Hyperledger TSC] Proposed release of the Iroha audit report
Sent by:        tsc@...




Thanks for the great writeup Dave

As you mentioned that all four issues have been resolved I would currently vote to release the report. <insert weasel words here> Of course if others come up with an objection that I had not considered I may need to factor that into my decision. </weasel words>

What do others think ?
-mark


On Thu, Dec 6, 2018 at 8:56 AM David Huseby <dhuseby@...> wrote:
Hello TSC,

As part of my visit to the Iroha team, I finalized the Iroha audit
checks with the team and I think that it is time to publish the Iroha
audit report and I would like the TSC's approval to do so.  I
recommend that the report be published.

The Iroha audit found four security issues, including one that was
critical enough to require us to issue our first CVE (
https://www.cvedetails.com/cve/CVE-2018-3756/)  All four issues were
tracked using our JIRA and resolved earlier this year.

Memory leak in Irohad ( https://jira.hyperledger.org/browse/IR-1)
Nettitude found a memory leak associated with processing a remote
request that creates a very slow potential denial of service.

Multi-signatory transactions can potentially be authorised by single
user ( https://jira.hyperledger.org/browse/IR-2)
This bug exploited some errors in the signature storage and validation
to bypass the transaction signature validation.  This is similar to
bug #3 bellow.  A malicious user could bypass the transaction
signature checking by signing it multiple times with a
non-deterministic signature scheme.

Vote early, Vote often ( https://jira.hyperledger.org/browse/IR-3)
This is the issue that required a CVE.  Nettitude found that by
modifying the ed25519 signature library to use random nonces instead
of message hashes, the signature checking code could be exploited to
accept multiple signatures produced with the same keypair.  This
allowed a single malicious node to sign the malicious transaction
multiple times and the other nodes would view the signatures as unique
and valid.  This completely bypasses one part of the byzantine fault
tolerance of the blockchain.

IP addresses can be made permanently unusable using the add peer
command ( https://jira.hyperledger.org/browse/IR-4)
This was a small error that is resolved by using DNS names and is not
really a problem to hold up the release.

Cheers!
Dave



---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...





--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc




Re: Hyperledger JIRA boards: how do we use them and why there are so many of them?

Silona Bonewald <sbonewald@...>
 

Howdy,

One of the things we are discussing and planning right now is how to make the CA's work more transparent and how to centralize information better.

After HGF, We will be sending out an email about the move to Confluence.  Right now we are getting Confluence ready for the move.  I don't want to simply announce and not give time for people to do it properly.  Moving btn wikis is a perfect time to cleanup.  We need to prep all the communities to be ready. We also need to give them guidelines on information needed and common structures to help findability.  So we are doing checklists and help files as we speak.

We are also reviewing the JIRA setup.  In fact, all of the CA requests will start to go thru a public JIRA so you can see, learn, and help our community support one another better.  We are also putting all of the CA docs in the wiki so people can watch our planning process.  We will be drinking our own wine.  Publishing our own Roadmap.  (Also with the comments in confluence - it will be a lot easier to give us direct feedback and understand our reasons. )

This is useful information about the boards.  Once the Confluence is up and running - we will see about a review of the JIRA boards and policies so the community can all check in on their needs.  We do need a better JIRA policy and it's on the roadmap.  We are a limited resource and can't always do everything that is requested but we can be more transparent about it going forward.  And hopefully be able to reach out to the community more often for help. 

One of the big reasons for moving to Confluence is the granular permissions.  The team is looking at more tools that support the fact that we are a community of communities and we need to figure out how to grant autonomy while being integrated and having open communications without accidentally stepping on each other's work.

HTH,
Silona



On Fri, Dec 7, 2018 at 1:54 PM Christopher Ferris <chris.ferris@...> wrote:
Actually, no, I was waiting for the LF to formally share that it was available.

Chris

On Fri, Dec 7, 2018 at 6:08 AM Iushkevich Nikolai <nikolai@...> wrote:
Cris,

I think that we might need to review your approach of using dashboards over boards, this can be helpful for our project as well.  We've always dreamt of having regular meetings where we can discuss processes and tools that support them. If we can talk about how other projects use JIRA for e.g. Fabric or Sawtooth community work or tasks for maintainers this will help us improve processes together.

If we combine that with a clean-up call that'll be more effective as we possibly are going to cross-question needs for some boards, tags and as a result we will have tidier JIRA.

Haven’t you started to use https://wiki2.hyperledger.org? This is a new confluence instance, we already have access there. 

Nikolai


6 дек. 2018 г., в 17:40, Christopher Ferris <chris.ferris@...> написал(а):

Nicolai,

Don't disagree, but frankly, using just the list of boards without context is useless, even if there were fewer.
I deleted mine, most had been created in a different time when I was experimenting how best to leverage for Fabric. Now we create dashboards instead, because most Fabric teams (anyway) are not using scrum or kanban boards. It really doesn't fit the open source model.

That said, I wouldn't object to a clean-up of JIRA, generally. We might want to discuss how we go about that. e.g. do we issue a call for self-cleanup, then issue warning (we're going to delete X unless you object in a week's time) and then have someone with administrative privileges delete, etc.

I'm also keen on us getting access to Confluence, because putting content around dashboards and epics will help immensely, and we can then leverage a wiki page as the front door for new developers etc.

Chris

On Thu, Dec 6, 2018 at 7:24 AM Nikolay Yushkevich <nikolai@...> wrote:
Hello!

Recently HL Iroha maintainers have started to use HL JIRA instance for project tracking and issue/bug reporting. Almost immediately we realized that there are too many boards, and possibly it is hard for an occasional contributor to check how things are going with a project’s release or where to find a good first issue.

There are some boards with restricted visibility, and they are empty as well. There are boards with stale issues, which are pending for 100, 200, 300 days. There are boards that are spelled in ALL CAPS; that have «copy of» in their name — and this looks very messy for a curious contributor.

Our concern is that we can’t find the board of our project easily if we open a list of all boards.

Let’s agree on some policy that is meaningful for all projects, supports their delivery process and would be transparent for contributors: where to find good first issues? Where to check if the bug is fixed? And similar things.

I think that you have something to add to this discussion and I would be happy to hear your thoughts on that.

Nikolai



--
You received this message because you are subscribed to the Google Groups "Community Architects" group.
To unsubscribe from this group and stop receiving emails from it, send an email to community-architects+unsubscribe@....


--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org

1981 - 2000 of 3892