Date   

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
 

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

Hart Montgomery
 

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
 

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


Re: Proposed agenda item for this week's TSC call: Technical Working Group India proposal

David Boswell
 

Thanks to everyone for providing feedback on the Technical Working Group India proposal on the TSC call yesterday.  There were a few action items from the discussion that I wanted to follow back up on.

* Designating official staff points of contact: The document didn't indicate who the points of contact should be, so I added information that Julian and I will serve in this role.  Having clear points of contact will help streamline how we coordinate with this WG.

* Reaching out to project maintainers: Getting project maintainers involved in this effort is definitely something we want to do.  I'll take the action of reaching out directly to all maintainers.  In terms of timing, I'll hold off on doing that now since I feel that a message would get lost right before people travel for Global Forum.  If there aren't objections, I propose doing this after Global Forum and would also recommend including details of the TWGI's first call so people have an action they can take.

* Increasing diversity of group participants: As the group grows, we will make a point of following best practices and suggestions for how to increase diversity.

If there were other major points from the discussion that I missed that need to get addressed before we move forward with this, please let us know.

Thanks,
David

On Mon, Dec 3, 2018 at 5:55 PM Baohua Yang <yangbaohua@...> wrote:
Glad to see this, will add my comments!

On Tue, Dec 4, 2018 at 2:36 AM David Boswell <dboswell@...> wrote:
If there is space on the TSC agenda this week, I'd like to propose adding an agenda item about a Technical Working Group India proposal. 

This is an effort to increase engagement and participation from the community in India and is modeled on the Technical Working Group China.

Amol Kulkarni, Sr. Security Architect & Head of Engineering, Blockchain Program Office at Intel India, will present the proposal if we're able to add it to this week's agenda.

A draft of the proposal is at:


Thanks,
David



--
Best wishes!

Baohua Yang


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

Christopher Ferris
 

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




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

Nikolay Yushkevich
 

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




Minutes for December 6, 2018

Tracy Kuhrt <tkuhrt@...>
 

Hyperledger

Technical Steering Committee (TSC) Meeting

December 6, 2018 (7:00am - 8:00am PT)

via Zoom


TSC Members

Arnaud Le Hors


Baohua Yang

Yes

Binh Nguyen

Yes

Christopher Ferris

Yes

Dan Middleton

Yes

Hart Montgomery

Yes

Kelly Olson

Yes

Mark Wagner

Yes

Mic Bowman

Yes

Nathan George

Yes

Silas Davis

Yes


Resources:


Event Reminders

  • APAC Hackfest -- week of March 4th (details coming soon)

  • Schedule announced for Hyperledger Global Forum, December 12-15 (Basel, Switzerland)

  • Linux Foundation IT Limited support Dec 17, 2018 - Jan 2, 2019, inclusive

  • Provide input on Community Survey

  • Upcoming meetings canceled: December 13th (HGF), December 20th (holiday), December 27th (holiday), and January 3rd (holiday). Next meeting on January 10th.

    • Concern over the number of updates that exist on the 10th. Therefore, we will move the Fabric update to the 17th.


Supply Chain proposal update

  • The last review focused on three aspects:

    • Charter - the governing board is weighing in on this

    • Specificity - proposal has been updated based on feedback from the community

    • Cross-platform adoption

  • Develop behind Web Assembly for future cross-platform adoption

  • Create Libraries, Data models, and SDKs to advance the development of supply chain applications

  • Context updated to move scope and solution details out of this section into the right sections

  • In the Solution section, the diagram shows the main deliverables

  • BB: We need a different name for this proposal. Abstract/goofy names is a powerful thing. Before this is approved, we need to come up with a name for this. Name proposed is Hyperledger Grid.

  • CF: Could the marketing committee help with name search and trademark?

  • CF: Still struggling with how this is a generic thing. Is this technology that could be consumed other by Sawtooth. A couple platforms are interested in adopting Web Assembly.

  • CF: We still have work to do to figure out what the APIs will look like.

  • KO: This is shooting to where the hockey puck is going. Web Assembly is where the public space is going.

  • CF: Codify the standards in software.

  • NG: Incubating projects are intended to work this out.

  • MB: There is a shape of the API and incubation will allow for hardening of the API.

  • MB and SD: Specificity and context is much clearer now.

  • SD: Dependencies currently list Sabre. Does that imply that this is also dependent on Sawtooth then? Need ABI layer on WASM. Uncouple this from Sabre and Sawtooth. By making it a separate project, we can ensure that this bias doesn't exist. We also want Sabre to grow beyond just Sawtooth.

  • SD: If in Burrow, I did not want to support Sabre and instead add a WASM interpreter, what would the gap be to support these APIs? Sabre does get/set state and the application API will support the get/set state. A lot of the direction of the project depends on who we can get involved.

  • HM: This is in between Composer and Indy in Scope. The updates to the proposal cleared this up.

  • NG: Can we take a vote on this yet?

  • MW: Is the architecture designed to provide a layer for other platform support? The intent is that code goes through a WASM interpreter, which would allow others to pick that up. How hard is it to make a shim for Sabre for other platforms. Three operations: get, set, and registration API would need to be implemented.

  • Vote with the caveat on naming going through the marketing committee - CF abstained, AL not present, all other TSC members approved.


Quarterly project updates


Quarterly WG updates


Technical WG India proposal

  • Meetup groups in India were looking for help in connecting with others.

  • The Indian developer community is looking to have a better connection to the rest of the community.

  • India has one of the largest developer community

  • The intent is to nuture, encourage, and train folks in India for getting involved in Hyperledger.

  • Amol Kulkarni has signed up to chair the TWGI

  • There is a tremendous amount of curiosity and enthusiasm for blockchain technologies. Have people who want to contribute, but don't know how to.

  • Helping out with collaboration, technical exchanges, and tutorials. Act as a bridge. Provide mentorship.

  • NG: Maintainers of Indy would like to participate. We would like to have them.

  • BB: Regional WG is not intended to be a VPN into the larger community. We expect them to be involved in the community and to provide a local assist. Because time zone prevents people from participating, it might be worthwhile to have a volunteer who can feedback to the community in India.

  • VB: Gender diversity is lacking in this working group. What can we do to drive more participation?

  • SB: How do we integrate with the Community Architect team? What are the boundaries between these regional WGs and the Hyperledger staff? There is significant overlap. Promote the programs and events that are part of Hyperledger's global community. Using local communication tools, news is shared about what is happening. Work with the APAC team on how we bring this group in closer communication with The Linux Foundation and Hyperledger staff.

  • BY: States his support for this group and desire to help.

  • AK: Call for additional participants that have knowledge of the different projects.


Hyperledger Labs update

  • Deferred to mailing list conversation


----
Tracy Kuhrt
Community Architect, Hyperledger
The Linux Foundation
tkuhrt@...
Hyperledger Chat: @tkuhrt


Re: Proposed release of the Iroha audit report

mark wagner
 

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?

Christopher 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



Proposed release of the Iroha audit report

Dave Huseby
 

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@linuxfoundation.org


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

Dave Huseby
 

I think it would make discoverability better if the project had their
main boards named in such a way that they are 1) obviously the board
for project X and 2) sorted to be at the top of the first page with
the default sorting order (e.g. use underscores like __Iroha Dev).

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

On Thu, Dec 6, 2018 at 4:24 AM Iushkevich Nikolai
<nikolai@soramitsu.co.jp> 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

1361 - 1380 of 3264