Every month there seems to be a new software vulnerability showing up on social media, which causes open source program offices and security teams to start querying their inventories to see how FOSS components they use may impact their organizations. 

Frequently this information is not available in a consistent format within an organization for automatic querying and may result in a significant amount of email and manual effort. By exchanging software metadata in a standardized software bill of materials (SBOM) format between organizations, automation within an organization becomes simpler, accelerating the discovery process and uncovering risk so that mitigations can be considered quickly. 

In the last year, we’ve also seen standards like OpenChain (ISO/IEC 5320:2020) gain adoption in the supply chain. Customers have started asking for a bill of materials from their suppliers as part of negotiation and contract discussions to conform to the standard. OpenChain has a focus on ensuring that there is sufficient information for license compliance, and as a result, expects metadata for the distributed components as well. A software bill of materials can be used to support the systematic review and approval of each component’s license terms to clarify the obligations and restrictions as it applies to the distribution of the supplied software and reduces risk. 

Kate Stewart, VP, Dependable Embedded Systems, The Linux Foundation, will host a complimentary mentorship webinar entitled Generating Software Bill Of Materials on Thursday, March 25 at 7:30 am PST. This session will work through the minimum elements included in a software bill of materials and detail the reasoning behind why those elements are included. To register, please click here. 

There are many ways this software metadata can be shared. The common SBOM document format options (SPDX, SWID, and CycloneDX) will be reviewed so that the participants can better understand what is available for those just starting. 

This mentorship session will work through some simple examples and then guide where to find the next level of details and further references. 

At the end of this session, participants will be on a secure footing and a path towards the automated generation of SBOMs as part of their build and release processes in the future. 

The post Generating a Software Bill of Materials (SBOM) with Open Source Standards and Tooling appeared first on Linux Foundation.

By Matt Zand

Recap

In our two previous articles, first we covered “Review of Five popular Hyperledger DLTs- Fabric, Besu, Sawtooth, Iroha and Indy” where we discussed the following five Hyperledger Distributed Ledger Technologies (DLTs):

1. Hyperledger Indy
2. Hyperledger Fabric
3. Hyperledger Iroha
4. Hyperledger Sawtooth
5. Hyperledger Besu

Then, we moved on to our second article (Review of three Hyperledger Tools- Caliper, Cello and Avalon) where we surveyed the following three Hyperledger t     ools:

1. Hyperledger Caliper
2. Hyperledger Cello
3. Hyperledger Avalon

So in this follow-up article, we review four (as listed below) Hyperledger libraries that work very well with other Hyperledger DLTs.      As of this writing, all of these libraries are at the incubation stage except for Hyperledger Aries,      which has graduated to      active.

1. Hyperledger Aries
2. Hyperledger Quilt
3. Hyperledger Ursa
4. Hyperledger Transact

Hyperledger Aries

Identity has been adopted by the industry as one of the most promising use cases of DLTs. Solutions and initiatives around creating, storing, and transmitting verifiable digital credentials will result in a reusable, shared, interoperable tool kit. In response to such growing demand, Hyperledger has come up with three       projects (Hyperledger Indy, Hyperledger Iroha and Hyperledger Aries) that are specifically focused on identity management.

Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions. It includes a shared cryptographic wallet (the secure storage tech, not a UI) for blockchain clients as well as a communications protocol for allowing off-ledger interactions between those clients.      This project consumes the cryptographic support provided by Hyperledger Ursa      to provide secure secret management and decentralized key management functionality.

According to Hyperledger Aries’ documentation, Aries includes the following features:

• An encrypted messaging system for off-ledger interactions using multiple transport protocols between clients.
• A blockchain interface layer that is also called as a resolver. It is used for creating and signing blockchain transactions.
• A cryptographic wallet to enable secure storage of cryptographic secrets and other information that is used for building blockchain clients.
• An implementation of ZKP-capable W3C verifiable credentials with the help of the ZKP primitives that are found in Hyperledger Ursa.
• A mechanism to build API-like use cases and higher-level protocols based on secure messaging functionality.
• An implementation of the specifications of the Decentralized Key Management System (DKMS) that are being currently incubated in Hyperledger Indy.
• Initially, the generic interface of Hyperledger Aries will support the Hyperledger Indy resolver. But the interface is flexible in the sense that anyone can build a pluggable method using DID method resolvers such as Ethereum and Hyperledger Fabric, or any other DID method resolver they wish to use. These resolvers would support the resolving of transactions and other data on other ledgers.
• Hyperledger Aries will additionally provide the functionality and features outside the scope of the Hyperledger Indy ledger to be fully planned and supported. Owing to these capabilities, the community can now build core message families to facilitate interoperable interactions using a wide range of use cases that involve blockchain-based identity.

For more detailed discussion on its implementation, visit the link provided in the References section.

Hyperledger Quilt

The widespread adoption of blockchain technology by global businesses      has coincided with the emergence of tons of isolated and disconnected networks or ledgers. While users can easily conduct transactions within their own network or ledger, they experience technical difficultly (and in some cases impracticality) for doing transactions with parties residing      on different networks or ledgers. At best, the process of cross-ledger (or cross-network) transactions is slow, expensive, or manual. However, with the advent and adoption of Interledger Protocol (ILP), money and other forms of value can be routed, packetized, and delivered over ledgers and payment networks.

Hyperledger Quilt is a tool for      interoperability      between ledger systems and is written in Java      by implementing the ILP for atomic swaps. While the Interledger is a protocol for making transactions across ledgers, ILP is a payment protocol designed to transfer value across non-distributed and distributed ledgers. The standards and specifications of Interledger protocol are governed by the open-source community under the World Wide Web Consortium umbrella. Quilt is an enterprise-grade implementation of the ILP, and provides libraries and reference implementations for the core Interledger components used for payment networks. With the launch of Quilt, the JavaScript (Interledger.js) implementation of Interledger was maintained by the JS Foundation.

According to the Quilt documentation, as a result of ILP implementation, Quilt offers the following features:

• A framework to design higher-level use-case specific protocols.
• A set of rules to enable interoperability with basic escrow semantics.
• A standard for data packet format and a ledger-dependent independent address format to enable connectors to route payments.

For more detailed discussion on its implementation, visit the link provided in the References section.

Hyperledger Ursa

Hyperledger Ursa is a shared cryptographic library that      enables people (and projects) to avoid duplicating other cryptographic work and hopefully increase security in the process. The library is      an opt-in repository for Hyperledger projects (and, potentially others) to place and use crypto.

Inside Project Ursa, a complete library of modular signatures and symmetric-key primitives      is at the disposal of developers to swap in and out different cryptographic schemes through configuration and without having to modify their code. On top its base library, Ursa      also includes newer cryptography, including pairing-based, threshold, and aggregate signatures. Furthermore, the zero-knowledge primitives including SNARKs are also supported by Ursa.

According to the Ursa’s documentation, Ursa offers the following benefits:

• Preventing duplication of solving similar security requirements across different blockchain
• Simplifying the security audits of cryptographic operations since the code is consolidated into a single location. This reduces maintenance efforts of these libraries while improving the security footprint for developers with beginner knowledge of distributed ledger projects.
• Reviewing all cryptographic codes in a single place will reduce the likelihood of dangerous security bugs.
• Boosting cross-platform interoperability when multiple platforms, which require cryptographic verification, are using the same security protocols on both platforms.
• Enhancing the architecture via modularity of common components will pave the way for future modular distributed ledger technology platforms using common components.
• Accelerating the time to market for new projects as long as an existing security paradigm can be plugged-in without a project needing to build it themselves.

For more detailed discussion on its implementation, visit the link provided in the References section.

Hyperledger Transact

Hyperledger Transact, in a nutshell, makes writing distributed ledger software easier by providing a shared software library that handles the execution of smart contracts, including all aspects of scheduling, transaction dispatch, and state management. Utilizing Transact, smart contracts can be executed irrespective of DLTs being used. Specifically, Transact achieves that by offering an extensible approach to implementing new smart contract languages called “smart contract engines.” As such, each smart contract engine implements a virtual machine or interpreter that processes smart contracts.

At its core, Transact is solely a transaction processing system for state transitions. That is, s     tate data is normally stored in a key-value or an SQL database. Considering an initial state and a transaction, Transact executes the transaction to produce a new state. These state transitions are deemed “pure” because only the initial state and the transaction are used as input. (In contrast to     other systems such as Ethereum where state and block information are mixed to produce the new state). Therefore, Transact is agnostic about DLT framework features other than transaction execution and state.

According to Hyperledger Transact’s documentation, Transact comes with the following components:

• State. The Transact state implementation provides get, set, and delete operations against a database. For the Merkle-Radix tree state implementation, the tree structure is implemented on top of LMDB or an in-memory database.
• Context manager. In Transact, state reads and writes are scoped (sandboxed) to a specific “context” that contains a reference to a state ID (such as a Merkle-Radix state root hash) and one or more previous contexts. The context manager implements the context lifecycle and services the calls that read, write, and delete data from state.
• Scheduler. This component controls the order of transactions to be executed. Concrete implementations include a serial scheduler and a parallel scheduler. Parallel transaction execution is an important innovation for increasing network throughput.
• Executor. The Transact executor obtains transactions from the scheduler and executes them against a specific context. Execution is handled by sending the transaction to specific execution adapters (such as ZMQ or a static in-process adapter) which, in turn, send the transaction to a specific smart contract.
• Smart Contract Engines. These components provide the virtual machine implementations and interpreters that run the smart contracts. Examples of engines include WebAssembly, Ethereum Virtual Machine, Sawtooth Transactions Processors, and Fabric Chaincode.

For more detailed discussion on its implementation, visit the link provided in the References section.

 Summary

In this article, we reviewed four Hyperledger libraries that are great resources for managing Hyperledger DLTs. We started by explaining Hyperledger Aries, which is infrastructure for blockchain-rooted, peer-to-peer interactions and includes a shared cryptographic wallet for blockchain clients as well as a communications protocol for allowing off-ledger interactions between those clients. Then, we learned that Hyperledger Quilt is the interoperability tool between ledger systems and is written in Java by implementing the ILP for atomic swaps. While the Interledger is a protocol for making transactions across ledgers, ILP is a payment protocol designed to transfer value across non-distributed and distributed ledgers. We also discussed that Hyperledger Ursa is a shared cryptographic library that would enable people (and projects) to avoid duplicating other cryptographic work and hopefully increase security in the process. The library would be an opt-in repository for Hyperledger projects (and, potentially others) to place and use crypto. We concluded our article by reviewing Hyperledger Transact by which smart contracts can be executed irrespective of DLTs being used. Specifically, Transact achieves that by offering an extensible approach to implementing new smart contract languages called “smart contract engines.”

References

For more references on all Hyperledger projects, libraries and tools, visit the below documentation links:

1. Hyperledger Indy Project
2. Hyperledger Fabric Project
3. Hyperledger Aries Library
4. Hyperledger Iroha Project
5. Hyperledger Sawtooth Project
6. Hyperledger Besu Project
7. Hyperledger Quilt Library
8. Hyperledger Ursa Library
9. Hyperledger Transact Library
10. Hyperledger Cactus Project
11. Hyperledger Caliper Tool
12. Hyperledger Cello Tool
13. Hyperledger Explorer Tool
14. Hyperledger Grid (Domain Specific)
15. Hyperledger Burrow Project
16. Hyperledger Avalon Tool

Resources

• Free Training Courses from The Linux Foundation & Hyperledger
  • Blockchain: Understanding Its Uses and Implications (LFS170)
  • Introduction to Hyperledger Blockchain Technologies (LFS171)
  • Introduction to Hyperledger Sovereign Identity Blockchain Solutions: Indy, Aries & Ursa (LFS172)
  • Becoming a Hyperledger Aries Developer (LFS173)
  • Hyperledger Sawtooth for Application Developers (LFS174)
• eLearning Courses from The Linux Foundation & Hyperledger
  • Hyperledger Fabric Administration (LFS272)
  • Hyperledger Fabric for Developers (LFD272)
• Certification Exams from The Linux Foundation & Hyperledger
  • Certified Hyperledger Fabric Administrator (CHFA)
  • Certified Hyperledger Fabric Developer (CHFD)
• Hands-On Smart Contract Development with Hyperledger Fabric V2 Book by Matt Zand and others.
• Essential Hyperledger Sawtooth Features for Enterprise Blockchain Developers
• Blockchain Developer Guide- How to Install Hyperledger Fabric on AWS
• Blockchain Developer Guide- How to Install and work with Hyperledger Sawtooth
• Intro to Blockchain Cybersecurity
• Intro to Hyperledger Sawtooth for System Admins
• Blockchain Developer Guide- How to Install Hyperledger Iroha on AWS
• Blockchain Developer Guide- How to Install Hyperledger Indy and Indy CLI on AWS
• Blockchain Developer Guide- How to Configure Hyperledger Sawtooth Validator and REST API on AWS
• Intro blockchain development with Hyperledger Fabric
• How to build DApps with Hyperledger Fabric
• Blockchain Developer Guide- How to Build Transaction Processor as a Service and Python Egg for Hyperledger Sawtooth
• Blockchain Developer Guide- How to Create Cryptocurrency Using Hyperledger Iroha CLI
• Blockchain Developer Guide- How to Explore Hyperledger Indy Command Line Interface
• Blockchain Developer Guide- Comprehensive Blockchain Hyperledger Developer Guide from Beginner to Advance Level
• Blockchain Management in Hyperledger for System Admins
• Hyperledger Fabric for Developers

About Author

Matt Zand is a serial entrepreneur and the founder of three tech startups: DC Web Makers, Coding Bootcamps and High School Technology Services. He is a leading author of Hands-on Smart Contract Development with Hyperledger Fabric book by O’Reilly Media. He has written more than 100 technical articles and tutorials on blockchain development for Hyperledger, Ethereum and Corda R3 platforms at sites such as IBM, SAP, Alibaba Cloud, Hyperledger, The Linux Foundation, and more. As a public speaker, he has presented webinars at many Hyperledger communities across USA and Europe     . At DC Web Makers, he leads a team of blockchain experts for consulting and deploying enterprise decentralized applications. As chief architect, he has designed and developed blockchain courses and training programs for Coding Bootcamps. He has a master’s degree in business management from the University of Maryland. Prior to blockchain development and consulting, he worked as senior web and mobile App developer and consultant, angel investor, business advisor for a few startup companies. You can connect with him on LinkedIn.

The post Review of Four Hyperledger Libraries- Aries, Quilt, Ursa, and Transact appeared first on Linux Foundation – Training.

Today, the Linux Foundation announced that it would be adding Rend-o-matic to the list of Call for Code open source projects that it hosts. The Rend-o-matic technology was originally developed as part of the Choirless project during a Call for Code challenge as a way to enable musicians to jam together regardless of where they are. Initially developed to help musicians socially distance because of COVID 19, the application has many other benefits, including bringing together musicians from different parts of the world and allowing for multiple versions of a piece of music featuring various artist collaborations. The artificial intelligence powering Choirless ensures that the consolidated recording stays accurately synchronized even through long compositions, and this is just one of the pieces of software being released under the new Rend-o-matic project.

Created by a team of musically-inclined IBM developers, the Rend-o-matic project features a web-based interface that allows artists to record their individual segments via a laptop or phone. The individual segments are processed using acoustic analysis and AI to identify common patterns across multiple segments which are then automatically synced and output as a single track. Each musician can record on their own time in their own place with each new version of the song available as a fresh MP3 track. In order to scale the compute needed by the AI, the application uses IBM Cloud Functions in a serverless environment that can effortlessly scale up or down to meet demand without the need for additional infrastructure updates. Rend-o-matic is itself built upon open source technology, using Apache OpenWhisk, Apache CouchDB, Cloud Foundry, Docker, Python, Node.js, and FFmpeg. 

Since its creation, Choirless has been incubated and improved as a Call for Code project, with an enhanced algorithm, increased availability, real-time audio-level visualizations, and more. The solution has been released for testing, and as of January, users of the hosted Choirless service built upon the Rend-o-matic project – including school choirs, professional musicians, and bands – have recorded 2,740 individual parts forming 745 distinct performances.

Call for Code invites developers and problem-solvers around the world to build and contribute to sustainable, open source technology projects that address social and humanitarian issues while ensuring the top solutions are deployed to make a demonstrable difference.  Learn more about Call for Code. You can learn more about Rend-o-matic, sample the technology, and contribute back to the project at https://choirless.github.io/ 

The post New open source project helps musicians jam together even when they’re not together appeared first on Linux Foundation.