Date   

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 <chris.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 <nikolai@...>
 

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 <mwagner@...>
 

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



Proposed release of the Iroha audit report

David Huseby <dhuseby@...>
 

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


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

David Huseby <dhuseby@...>
 

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

On Thu, Dec 6, 2018 at 4:24 AM Iushkevich Nikolai
<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


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

Nikolay Yushkevich <nikolai@...>
 

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


Q1 2019 Working Group and Project Updates Schedule

Tracy Kuhrt <tkuhrt@...>
 

Please find the schedule for the Q1 2019 working group and project updates schedule below:
  • January 10, 2019
    • Hyperledger Composer (Q4 2018 holdover)
    • Hyperledger Explorer (Q4 2018 holdover)
    • Hyperledger Quilt (Q4 2018 holdover)
    • Hyperledger Caliper (Q4 2018 holdover)
    • Hyperledger Fabric
    • Architecture WG
  • January 17, 2019
    • Hyperledger Sawtooth
  • January 24, 2019
    • Hyperledger Iroha
    • Identity WG
  • January 31, 2019
    • Hyperledger Composer
  • February 7, 2019
    • Hyperledger Indy
    • Performance and Scalability WG
  • February 14, 2019
    • Hyperledger Burrow
  • February 21, 2019
    • Hyperledger Cello
    • Technical WG China
  • February 28, 2019
    • Hyperledger Explorer
  • March 14, 2019
    • Hyperledger Quilt
    • Learning Materials Development WG
  • March 21, 2019
    • Hyperledger Caliper
  • March 28, 2019
    • Hyperledger Ursa
These dates are also reflected in the TSC calendar and reminders will be sent out to the respective mailing lists prior to the due date.

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


Re: Agenda for December 6, 2018

Mic Bowman
 

Just to point out that Jan 10 is going to be very full. Would it make sense to extend the time to a full two hours to accommodate all of the updates? Otherwise… suggest we push out a couple of them.

 

--mic

 

From: tsc@... [mailto:tsc@...] On Behalf Of Tracy Kuhrt
Sent: Wednesday, December 5, 2018 2:07 PM
To: tsc@...
Subject: [Hyperledger TSC] Agenda for December 6, 2018

 

Location: https://zoom.us/my/hyperledger.community.backup

·  Reminders

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

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

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

o Provide input on Community Survey

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

·  Supply Chain updated proposal

·  Quarterly project updates - none this week

o January 10th: Hyperledger Composer deferred due to lack of update (original due date October 29th)

o January 10th: Hyperledger Explorer deferred due to lack of update (original due date December 3rd)

o January 10th: Hyperledger Quilt deferred due to the canceled meeting on December 13th

o January 10th: Hyperledger Caliper deferred due to the canceled meeting on December 20th

o January 10th: Hyperledger Fabric

·  Quarterly WG updates - none this week

o January 10th: Architecture WG

·  Technical WG India proposal

·  Hyperledger Labs update

 

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

Hyperledger Chat: @tkuhrt


Re: Agenda for December 6, 2018

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

In regards to the Composer situation we should have a discussion about our lifecycle.

 

Besides reviewing the other links below, please review https://wiki.hyperledger.org/community/project-lifecycle

so we can have some discussion on that.

 

Thanks,
Dan

 

From: <tsc@...> on behalf of Tracy Kuhrt <tkuhrt@...>
Date: Wednesday, December 5, 2018 at 4:07 PM
To: "tsc@..." <tsc@...>
Subject: [Hyperledger TSC] Agenda for December 6, 2018

 

Location: https://zoom.us/my/hyperledger.community.backup

·  Reminders

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

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

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

o    Provide input on Community Survey

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

·  Supply Chain updated proposal

·  Quarterly project updates - none this week

o    January 10th: Hyperledger Composer deferred due to lack of update (original due date October 29th)

o    January 10th: Hyperledger Explorer deferred due to lack of update (original due date December 3rd)

o    January 10th: Hyperledger Quilt deferred due to the canceled meeting on December 13th

o    January 10th: Hyperledger Caliper deferred due to the canceled meeting on December 20th

o    January 10th: Hyperledger Fabric

·  Quarterly WG updates - none this week

o    January 10th: Architecture WG

·  Technical WG India proposal

·  Hyperledger Labs update

 

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

Hyperledger Chat: @tkuhrt


Agenda for December 6, 2018

Tracy Kuhrt <tkuhrt@...>
 

Location: https://zoom.us/my/hyperledger.community.backup

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


Hyperledger Labs Q4 update

Tracy Kuhrt <tkuhrt@...>
 

Hello, Hyperledger TSC.

Please find the Q4 update for Hyperledger Labs at https://wiki.hyperledger.org/labs/2018-q4-update. As a summary:

  • Total Labs: 13
  • Labs proposed (since the last report): 17
  • Labs proposals accepted (since the last report): 12
  • Labs proposals in process: 5
  • Labs graduated: 2 (crypto-lib and z-mix = Ursa)


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


Hyperledger Explorer Quarterly Update Due #tsc-project-update - Thu, 12/06/2018 #tsc-project-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder:
Hyperledger Explorer Quarterly Update Due #tsc-project-update

When:
Thursday, 6 December 2018

Organizer:
tkuhrt@...

Description:
The Hyperledger Explorer project update to the TSC was due December 3, 2018, and it will be presented to the TSC on December 6, 2018. Please review prior to the meeting and bring your questions.

View Event


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

Baohua Yang
 

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


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

David Boswell
 

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


[zkproof-community] Announcing the 2nd ZKProof Workshop 2019

Vipin Bharathan
 

Hi all,
This is the announcement of the 2nd zkproof workshop. Several people from the Hyperledger community attended the first workshop. The standards will be derived from the outputs of the first workshop. This time it will be on the West Coast. Please apply to participate as it is an invitation only workshop.
Also, apply to present in the show case (Industry & Research) if you have products to showcase.
Please see the link below where you can apply.  
Best,
Vipin
---------- Forwarded message ---------
From: ZKProof Standards <contact@...>
Date: Wed, Nov 14, 2018 at 3:46 PM
Subject: [zkproof-community] Announcing the 2nd ZKProof Workshop 2019
To: <zkproof-standards-community@...>


Hello Everyone,

First off, we are delighted to let you know that we have welcomed three new members to the Steering Committee: Alessandro Chiesa, Jens Groth and Yael Kalai. Their addition and contribution will have a positive effect on the effort.

We are also happy to share with you that we have just published the website for the 2nd ZKProof Workshop, which will take place in Berkeley, California, on April 10th to 12th, 2019. You can now request an invitation here, we will get back to you as soon as we can.

The first two days will be dedicated to the Standards Workshop, where participants will discuss and agree on an initial set of community standards, derived from the three documents. The third day will be dedicated to an Industry & Research Showcase of existing work around zero knowledge proofs. 

In the coming weeks we will be adding to the website a call for community standards proposals and for research and industry showcase workshops.

Best Regards,
ZKProof Steering Committee & Organizers



--
You received this message because you are subscribed to the Google Groups "ZKProof Standards Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zkproof-standards-community+unsubscribe@....
To post to this group, send email to zkproof-standards-community@....
Visit this group at https://groups.google.com/a/zkproof.org/group/zkproof-standards-community/.
To view this discussion on the web visit https://groups.google.com/a/zkproof.org/d/msgid/zkproof-standards-community/CAM2MVa4fWa39GFs%2B52ASNSNyhkONRhYo_amCDi4AD7vq5FOg0Q%40mail.gmail.com.


Re: [Hyperledger Fabric] [Hyperledger TSC] CI/CD questions/discussion

Ramesh Thoomu <thoomu@...>
 

Hi Dave/Jonathan,
 
I will answer some of the common questions…
 
Concerning Rebase, several months ago we were asked to defer automatic rebuilds to save resource. However as Jonathan states this can cause problems if there has been a dependency change. We will plan on re-enabling the automatic rebuild upon Rebase if there are no concerns.
 
1) It appears that the HL Jenkins is only being used by Fabric, but a lot of the build tasks are failing and have been for months.  Where are Fabric's main CI builds happening?  Where are Fabric's CD binaries being stored?
 
Some of them fail intermittently either due to the infrastructure issues (e.g. timeouts due to slow infrastructure or failure to download third-party dependencies) or developer test flakes. Neither of these failures are related to Jenkins job configuration. We open JIRA for each issue observed.
 
While the flakes are very small percentage, given the amount of test automation that has been added to the CI they do show up sometimes.
 
We usually disable any job temporarily if it is failing consistently as a practice.
 
See the list of jobs (build, test, release, nightly etc..) we run for fabric. This includes all fabric repositories (not sure why Indy is here too):
Regarding the binaries, we push fabric, fabric-ca binaries to nexus2 repository.
 
2. Can we wipe out all of the CI builds on HL Jenkins that have been failing for months?
 
All the consistently failing jobs are on s390x release jobs. Fixes are not prioritized at this time, as these are platform specific not related to fabric code. We will disable them until fixes are available.
 
5. What is the official HL solution for build artifacts?  Where should our CD upload the binaries?
 
 
We have created HL helpdesk ticket#63838 to determine where to upload fabric build binaries.
 
For more details, see the CI documentation https://ci-docs.readthedocs.io/en/latest/index.html
 
We are planning to give overview on fabric CI process and recent Jenkins Pipeline improvements to the community on Dec 5th at 10:00 AM US EST https://wiki.hyperledger.org/projects/fabric/playbacks Please join us here to learn/understand more on CI/CD process.
 
Thanks,
Ramesh

----- Original message -----
From: "Jonathan Levi (HACERA)" <jonathan@...>
Sent by: fabric@...
To: David Huseby <dhuseby@...>
Cc: hyperledger-tsc@..., hyperledger-fabric <hyperledger-fabric@...>, Gari Singh <garis@...>
Subject: Re: [Hyperledger Fabric] [Hyperledger TSC] CI/CD questions/discussion
Date: Fri, Nov 30, 2018 1:34 PM
 
Also, the CI/CD still allows "people" and "processes" to break the build.
 
Speaking of the devil, we have just merged a fix (like an hour ago) that Jason pushed after hours...
 
 
I know some people got used to it, but really, this is not "normal".
 
Now, all of the pending CRs will (need to) be Rebase manually... and as some of you know, we have some issues with the "Rebase" button, with the parent issue... 
 
But even with that aside, it is a mess having 20+ builds running/pending due to the dilluge of rebases (and re-running builds).
 
While we should not change "everything" this week, there are many ongoing issues with the CI.

We have been discussing this serveral times (years), since the days of us voting for branches and development work flow, but if we are getting rid of Jenkins, let's also make sure that we get the basics right, because it is expensive, time/resources/dependencies-wise.
 
Thanks again,
Jonathan Levi
 
HACERA - To Blockchain with Confidence
 
Unbounded - To Network with Network
 
 
On Fri, Nov 30, 2018, 1:22 AM Jonathan Levi (HACERA) <jonathan@... wrote:
Dave (Mike and Hart), I am so glad this is being brought up again!
 
While I have a lot to say about this, I would like to point out that even though the Fabric devs historically we're/are the heavier/heaviest users of the Jenkins build... please let's not interpret this as if the Fabric devs and maintainers are happy with the current setup.
 
I can speak for myself though, to make things simpler. So, regarding #3, quickly:
 
"3) Can we make significant changes to Jenkins to make it less Fabric
specific and a better solution for all of the other projects?"
 
We need to make the Jenkins (or CI) build setup a better solution <full stop>.
 
The current setup cost us more than an extra month with Fabric 1.3... and this is only for the Identity Mixer work that HACERA helped to productionize in Fabric 1.3. Zurich Research spent a LOT of time, due to receiving the wrong output / build errors from the CI... and not everybody was able to realize the chain of things that were wrong in the setup(s).
 
In all fairness, we have setup our own CI(s) as we couldn't rely anymore on some the results... 
so please, I don't want anybody to be "jealous" that most of the contributions to the CI scripts came from us, historically (some of them are there pre Fabric 0.5). I have spent quite a while talking about this with Gari (Singh) just today, as he is/was working to remove some of the old configuration that we needed back in the day with Greg's Makefile.
 
Still, these won't save the day... as we have a LOT on our plates. We really need some better infrastructure. Due we some capacity to deal with this?
 
Let alone failing, the CA turned out to not even build the latest, the integration was running against old images, and boy, some of these things spit out and deploy outputs all over the place (even in daily builds).
 
All the CI code is checked in to a repo, but honestly, it is really hard to track due to all these shell scripts and genius pre- and post- processing logic that is magically applied in so many cases... and some of us, mere mortals, cannot follow anymore.
 
We about to cut a release candidate in a few days, and I was/am actually about to report tomorrow not only that many builds fail... but also that some "successful" runs are definitely not supposed to be passing.
 
It is not optimal. We definitely need better tooling, given the number of contributes.
 
Please take a look at my last few merges... or at how many times I am submitting a "reverify" and "remerge" just to stabilize some of these insane error messages.
 
It is very easy to see what the CI is doing, but it is even more easy to see how much we struggling with tests that we need to re-run, in many times locally and then we synchronize through chat messages, to ascertain some consistency.
 
While I am less active this year on the TSC... this really needs attention, so Dave (Hart and Mike), and the TSC, thank you, thank you, thank you, in advance.
 
People "spat blood" towards the end of Fabric 1.3, to the level of us scheduling another full release (1.4) just for house-cleaning. We really need to re-think/re-visit that pattern of "being too busy to sharpen the saw".
 
------
 
I know, I know, it's close to Xmas time and not everybody likes to hear the truth about Santa (apparently this is a major realization in one's life. My biggest issue was the tooth fairy one, having broken a tooth by falling off  a skateboard straight on my face only to realize that I may get a similar tooth, at best, and forever be weary of strong Green apples. But hey! Let's not digress here! :D). If we want to discuss the CI problem, please let's keep the above in mind. Ramesh and others are working to capacity with every release, and we could/should give them a helping hand.
 
Sorry if this may extend the scope of work "slightly", but you guys are touching a really important topic. It needs much more work than "making it work not just for Fabric"... I would go as far as "making it work".
 
Will be happy to help too... so more questions or feedback is (always) welcome.
 
 
Thanks again,
Jonathan Levi
 
HACERA - To Blockchain with Confidence
 
Unbounded - To Network with Network
 
 
 
 
On Fri, Nov 30, 2018, 12:26 AM David Huseby <dhuseby@... wrote:
Hi TSC,

This morning Hart, Mike, and I met to discuss the plan for the Ursa
library CI/CD pipeline.  What actually happened was we took a good
look at the HL Jenkins setup and asked around about what all of the
other projects are using.  We came up with a list of questions we
decided to ask the TSC list about:

1) It appears that the HL Jenkins is only being used by Fabric, but a
lot of the build tasks are failing and have been for months.  Where
are Fabric's main CI builds happening?  Where are Fabric's CD binaries
being stored?

2) Can we wipe out all of the CI builds on HL Jenkins that have been
failing for months?

3) Can we make significant changes to Jenkins to make it less Fabric
specific and a better solution for all of the other projects?

4) The HL Indy experience with GitLab suggests that GitLab may be a
better all around solution for CI for the HL projects.  The free,
self-hosted version of GitLab supports the features we need: LDAP
integration and CI/CD pipeline with API.  Can we try using that?
Jenkins is super clunky.

5) What is the official HL solution for build artifacts?  Where should
our CD upload the binaries?

That's it for now.  It turns out that each project has their own CI/CD
pipeline and only Fabric is using the HL one.  Indy is using Jenkins
run by Evernym and Sovrin but they are moving to GitLab soon.  Iroha
is using Jenkins run by Soramitsu.  Burrow uses Helm charts for
executing things and I'm still waiting on details about Sawtooth.

Ultimately I would like us to set up a CI/CD system that all of the
teams want to use.  I think the initial set of requirements are:

1) Well documented and easy to get going for a new project.
2) Easy to maintain.
3) Integrates with a well defined CD storage system.
4) Integrates with both Gerrit and GitHub.

Both Jenkins and GitLab meet #3 and #4.  But I think only GitLab meets
#1 and #2.  I'd like to set an instance up and evaluate it.

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


 

 

 

 


Re: CI/CD questions/discussion

Jonathan Levi (HACERA)
 

Also, the CI/CD still allows "people" and "processes" to break the build.

Speaking of the devil, we have just merged a fix (like an hour ago) that Jason pushed after hours...


I know some people got used to it, but really, this is not "normal".

Now, all of the pending CRs will (need to) be Rebase manually... and as some of you know, we have some issues with the "Rebase" button, with the parent issue... 

But even with that aside, it is a mess having 20+ builds running/pending due to the dilluge of rebases (and re-running builds).

While we should not change "everything" this week, there are many ongoing issues with the CI.

We have been discussing this serveral times (years), since the days of us voting for branches and development work flow, but if we are getting rid of Jenkins, let's also make sure that we get the basics right, because it is expensive, time/resources/dependencies-wise.

Thanks again,
Jonathan Levi

HACERA - To Blockchain with Confidence

Unbounded - To Network with Network



On Fri, Nov 30, 2018, 1:22 AM Jonathan Levi (HACERA) <jonathan@... wrote:
Dave (Mike and Hart), I am so glad this is being brought up again!

While I have a lot to say about this, I would like to point out that even though the Fabric devs historically we're/are the heavier/heaviest users of the Jenkins build... please let's not interpret this as if the Fabric devs and maintainers are happy with the current setup.

I can speak for myself though, to make things simpler. So, regarding #3, quickly:

"3) Can we make significant changes to Jenkins to make it less Fabric
specific and a better solution for all of the other projects?"

We need to make the Jenkins (or CI) build setup a better solution <full stop>.

The current setup cost us more than an extra month with Fabric 1.3... and this is only for the Identity Mixer work that HACERA helped to productionize in Fabric 1.3. Zurich Research spent a LOT of time, due to receiving the wrong output / build errors from the CI... and not everybody was able to realize the chain of things that were wrong in the setup(s).

In all fairness, we have setup our own CI(s) as we couldn't rely anymore on some the results... 
so please, I don't want anybody to be "jealous" that most of the contributions to the CI scripts came from us, historically (some of them are there pre Fabric 0.5). I have spent quite a while talking about this with Gari (Singh) just today, as he is/was working to remove some of the old configuration that we needed back in the day with Greg's Makefile.

Still, these won't save the day... as we have a LOT on our plates. We really need some better infrastructure. Due we some capacity to deal with this?

Let alone failing, the CA turned out to not even build the latest, the integration was running against old images, and boy, some of these things spit out and deploy outputs all over the place (even in daily builds).

All the CI code is checked in to a repo, but honestly, it is really hard to track due to all these shell scripts and genius pre- and post- processing logic that is magically applied in so many cases... and some of us, mere mortals, cannot follow anymore.

We about to cut a release candidate in a few days, and I was/am actually about to report tomorrow not only that many builds fail... but also that some "successful" runs are definitely not supposed to be passing.

It is not optimal. We definitely need better tooling, given the number of contributes.

Please take a look at my last few merges... or at how many times I am submitting a "reverify" and "remerge" just to stabilize some of these insane error messages.

It is very easy to see what the CI is doing, but it is even more easy to see how much we struggling with tests that we need to re-run, in many times locally and then we synchronize through chat messages, to ascertain some consistency.

While I am less active this year on the TSC... this really needs attention, so Dave (Hart and Mike), and the TSC, thank you, thank you, thank you, in advance.

People "spat blood" towards the end of Fabric 1.3, to the level of us scheduling another full release (1.4) just for house-cleaning. We really need to re-think/re-visit that pattern of "being too busy to sharpen the saw".

------

I know, I know, it's close to Xmas time and not everybody likes to hear the truth about Santa (apparently this is a major realization in one's life. My biggest issue was the tooth fairy one, having broken a tooth by falling off  a skateboard straight on my face only to realize that I may get a similar tooth, at best, and forever be weary of strong Green apples. But hey! Let's not digress here! :D). If we want to discuss the CI problem, please let's keep the above in mind. Ramesh and others are working to capacity with every release, and we could/should give them a helping hand.

Sorry if this may extend the scope of work "slightly", but you guys are touching a really important topic. It needs much more work than "making it work not just for Fabric"... I would go as far as "making it work".

Will be happy to help too... so more questions or feedback is (always) welcome.


Thanks again,
Jonathan Levi

HACERA - To Blockchain with Confidence

Unbounded - To Network with Network




On Fri, Nov 30, 2018, 12:26 AM David Huseby <dhuseby@... wrote:
Hi TSC,

This morning Hart, Mike, and I met to discuss the plan for the Ursa
library CI/CD pipeline.  What actually happened was we took a good
look at the HL Jenkins setup and asked around about what all of the
other projects are using.  We came up with a list of questions we
decided to ask the TSC list about:

1) It appears that the HL Jenkins is only being used by Fabric, but a
lot of the build tasks are failing and have been for months.  Where
are Fabric's main CI builds happening?  Where are Fabric's CD binaries
being stored?

2) Can we wipe out all of the CI builds on HL Jenkins that have been
failing for months?

3) Can we make significant changes to Jenkins to make it less Fabric
specific and a better solution for all of the other projects?

4) The HL Indy experience with GitLab suggests that GitLab may be a
better all around solution for CI for the HL projects.  The free,
self-hosted version of GitLab supports the features we need: LDAP
integration and CI/CD pipeline with API.  Can we try using that?
Jenkins is super clunky.

5) What is the official HL solution for build artifacts?  Where should
our CD upload the binaries?

That's it for now.  It turns out that each project has their own CI/CD
pipeline and only Fabric is using the HL one.  Indy is using Jenkins
run by Evernym and Sovrin but they are moving to GitLab soon.  Iroha
is using Jenkins run by Soramitsu.  Burrow uses Helm charts for
executing things and I'm still waiting on details about Sawtooth.

Ultimately I would like us to set up a CI/CD system that all of the
teams want to use.  I think the initial set of requirements are:

1) Well documented and easy to get going for a new project.
2) Easy to maintain.
3) Integrates with a well defined CD storage system.
4) Integrates with both Gerrit and GitHub.

Both Jenkins and GitLab meet #3 and #4.  But I think only GitLab meets
#1 and #2.  I'd like to set an instance up and evaluate it.

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



2001 - 2020 of 3892