Explore Projects

One of the key use cases of blockchain integration is asset bridging: in essence, "locking" an asset (typically, a native coin or token) in a smart contract on its authoritative ledger and making available corresponding, newly minted (wrapped/shadow/...) assets on another. By now, bridging is supported by quite mature solutions in the cryptoworld; however, the same is not true for "consortial" distributed ledger technologies. At the same time, such functionality can be expected to become an important requirement in the not too distant future - Analysing the implementation approaches of standard "token models" (ERC20, ERC-721, ... - as far as this has been already done) in native Fabric chaincode and creating conceptual mappings between standard Ethereum token types and Fabric-native assets (including, but not limited to, the different authentication and authorization approaches). - Creating a brief review of the bridging approaches and mature technologies widely used in the cryptoworld. - Performing a requirement analysis for bridging assets from Fabric to Ethereum-based networks (and back), taking into account that the parties performing the bridging have to be explicitly given permission to do so by an authority and may be subject to regulatory requirements. - Based on the available open-source components, designing and prototyping a Fabric-Ethereum bridge fulfilling the requirements As the proposed project bridges multiple fields, creating a centralized solution.

Kata Containers is an open source community working to build a secure container runtime with lightweight virtual machines that feel and perform like containers, but provide stronger workload isolation using hardware virtualization technology as a second layer of defense. Expected Outcome: KubeArmor natively protecting Kata containers with required Integration.

Extend the Kyverno CLI to cover generate policies and improve tests coverage for Kyverno. Based on the test results, the candidate has to add more unit/E2E tests.

Karmada would like to improve the UT coverage of the code to better maintain the quality of the code and reduce the introduction of defects. Increase the UT coverage rate to 50% to 60% (currently, the UT coverage rate is [28.26%](https://app.codecov.io/gh/karmada-io/karmada) ). The entire Karmada repository is a bit large for one project, so we will split it into two projects. The current focus is mainly on `karmada-search`, `karmada-operator`, `karmada-webhook` components. Expected Outcome: - Increase the UT (Unit Test) coverage by more than 25% and add more than 5500 lines of code coverage except for the following directories: pkg/controllers pkg/dependenciesdistributor pkg/descheduler pkg/detector pkg/estimator pkg/scheduler pkg/resourceinterpreter pkg/util

A DID registry is a type of verifiable data registry that can be simply referred to as a role, a system performs to mediate the functionalities like create, verify, update, and deactivate the decentralized identifiers. The mentee will have an opportunity to learn -- The application and automation of the Decentralized Identity Hyperledger Aries and Ursa code base -- Public key cryptography -- Application of Hyperledger Ursa in enabling Zero-Knowledge proof -- Git, Shell Scripting, RUST -- Open source contribution, documentation, and sense of ownership Expected Outcome -- Command-Line utility to automate the process of creating a DID Registry for the members of organizations utilizing Github/Gitlab as Verifiable Credential Registry, On-boarding organizations, and features for easy management -- Proper test cases and documentations -- Codebase maintained with proper read me document

Crossplane supports pulling packages from private registries through a variety of mechanisms, including IRSA, Workload Identity, and packagePullSecrets. There are a wide variety of environments in which a user is pulling a private package, which can lead to confusion about which to use, the precedence with which each is invoked, etc. This can lead to issues such as crossplane/crossplane#2876, where I suspect that we are resolving to Application Default Credentials, when we actually want to be using the provided packagePullSecret.

Description: Kubewarden currently allow policy writers to use 4 different programming languages. Therefore, there are 4 SDKs to be maintained. However, they lack feature parity. In other words, some SDK have feature that have features not available in other SDKs. It's necessary to map what are the features missing between the Go and Rust SDKs and implement some of them. For that, it is necessary to read and understand what is done in the Rust SDK and implement the equivalent in the Go SDK. Expected Outcome: Map all the features missing between the Go and Rust SKDs and implement some of the missing features

Fablo is a Hyperledger Labs project that aims to manage a local Hyperledger Fabric network on Docker. Previous edition of Hyperledger Mentorship Program resulted with the implementation of the initial, experimental support for Kubernetes Operators (using Bevel Operator). The overall objective of the current mentorship program is to improve test coverage for Kubernetes Operators support for Fablo, implement crucial missing features and fix most important issues that come up as a result of testing. First, the mentee is responsible for implementing Bash scripts with automatic tests of a running HLF network, in a similar manner it is already done for Fablo on Docker. Tests need to verify the support for Fablo’s features, like network lifecycle support, using Fablo hooks, managing complex HLF network topologies, and others. On the basis of it, the mentee is going to create a set of issues and start working on them in the second part of the internship. Additionally the project includes implementing a few Fablo features supporting testing: `fablo invoke/query`, `fablo enroll` and `fablo chaincode list`.

Cryptographic mentorship - Spring/Summer '25 Mission: OpenBao exists to maintain and improve a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. The OpenBao community will provide this software under an OSI-approved open-source license, led by a community run under open governance principles. This mentorship focuses on adding post-quantum cryptography support to OpenBao: https://github.com/openbao/openbao/issues/496

The Hyperledger Greenhouse, powered by the Hyperledger Foundation, provides several Business Blockchain Frameworks & Tools, some of which compose the state of the art private blockchains. In particular, Hyperledger Fabric is amongst the most famous permissioned blockchains; Hyperledger Indy tackles the first big initiative to promote decentralized identity support; Hyperledger Caliper is a comprehensive blockchain-testing framework; Hyperledger Quilt enables a specific type of blockchain interoperability - enables payments across any payment network — fiat or crypto - using the Interledger protocol. Cactus is a blockchain integration tool designed to allow users to securely integrate different blockchains, promoting blockchain interoperability. This way, Hyperledger Cactus aims to provide Decentralized, Secure, and Adaptable Integration between Blockchain Networks. Hyperledger Cactus is currently undergoing a major refactoring effort to enable the desired to-be architecture which will enable plug-in based collaborative development to increase the breadth of use cases & Ledgers supported. To fully explore Cactus’ capabilities, and to promote the project’s adoption, one needs several business logic plugins that realize cross-blockchain use cases (similarly to fabric-samples). Many are proposed on the whitepaper, but few are implemented.

Crossplane provides a broad library of Kubernetes custom resources that let you orchestrate systems external to Kubernetes. These include AWS S3 buckets, GCP CloudSQL instances, Azure Cosmos tables, plain old SQL databases, Helm releases, and Dominos pizzas. We call these 'managed resources'. Crossplane's goal is to allow platform teams to build their own custom resources that are in turn composed of these primitives without needing to write Kubernetes controllers in Go. Crossplane currently has extensive unit testing, but not much in the way of automated integration/e2e tests. We have a very broad surface area to test (we have around a hundred controllers that interact with cloud providers) and would like to establish some integration testing best practices so that the community can easily contribute integration tests when they work on Crossplane.

We propose to use the composable Interwork Alliance Token Taxonomy Framework (IWA TTF) to produce a Learning Token that recognizes, registers, and rewards community engagement in teaching and learning experiences, certifying, at the same time, the acquisition of skills and competencies. Communities that agree upon valuable behaviors can turn those behaviors into unique token representations of their value and set up clear rules for its creation and supply, able to resist modification or tampering, and, most important, capable of being transferred per-to-peer. Our Learning Token is proof of behaviors that benefit learning communities, individual members, and collectivity. With IWA TTF, we shall define common token concepts with a clear understanding of our requirements. We shall specify properties for particular behaviors. We shall link their base Token Classification Hierarchy with our Taxonomy of DLT / Blockchain Educational Opportunities as initial meta-data for standard artifacts and control message descriptions.

The Karmada Certificate Lifecycle Management project addresses user challenges in certificate management, focusing on mitigating service disruptions and security risks due to expirations. Key goals include implementing a feature for real-time monitoring of certificates with advance notification for upcoming expirations; creating a comprehensive manual for manual replacement with best practices and visuals; allowing configurable certificate validity during deployment via CLI, Helm charts, and Operator; and designing an automated certificate rotation system to streamline certificate maintenance and ensure continuous security across Karmada environments. Expected Outcome: Certificate Visibility Tool/Feature, Manual Certificate Replacement Guide, Updated Installation Tools with Customizable Certificate Validity, and Automated Certificate Rotation Solution Design or Integration Recommended Skills: Golang, Kubernetes Admin, certificate management, Helm. Upstream Issue: karmada-io/community#69

The component-model proposal merges and supersedes the Module Linking and Interface Types proposals. With this feature, WasmEdge can execute multiple modules wasm with Module Linking and and more flexible types with Interface Type.

This feature request aims to automate the building and publishing of OS images that are used in Kubespray CI testing. Currently, these images (defined in `test-infra/image-builder/roles/kubevirt-images/defaults/main.yml`) must be manually created and pushed by maintainers. Automating this process would reduce manual work, eliminate bottlenecks when maintainers are unavailable, and could include automatic cleanup of outdated or unused images, while still retaining images needed for older supported release branches. - Expected Outcome: A CI job (likely post-merge and possibly periodic) that automatically: 1. Builds the required Kubespray OS images used in CI for tested distributions. 2. Pushes these built images to the appropriate registry. 3. Cleans up old or no longer needed images but retains those required for supported release branches.

Vitess is a CNCF project that has been around for a while. It has a strong community of users and contributors. We want to continue growing this community and make sure that everyone feels welcome and included. Expected Outcome: The mentee is expected to evaluate contributor ladder schemes and rewards and produce a recommendation for the Vitess maintainers. Once a decision is made, the mentee is expected to implement the decisions from the maintainer team. The mentee is expected to collect data about Vitess usage from the community and publish the highlights as a blog post. The mentee is expected to review the Getting Started docs (https://vitess.io/docs/20.0/get-started/) on the Vitess website and enhance them to improve the onboarding experience. The mentee is expected to research and recommend marketing opportunities for Vitess. These could be guest blog posts, podcasts, live streams etc.

The OpenAPI specifications for Kubernetes provides taxonomy, but augmenting a graph data model with formalized ontologies enables any number of capabilities, one of the more straightforward is the inferencing requisite for natural language processing, and consequently, a human-centric query / response interaction becomes becomes possible. More importantly, more advanced systems can be built when a graph data model of connected systems is upgraded to be a knowledge semantic graph. Expected Outcome: - YAML-formatted definition of one or more relationships per Kubernetes resource. - Documentation of each relationship - per component. - Development of new types of genealogies - new types of ways in which resources relate to one another and how these relationships might be visualized. - Verification of functional relationships

All In is a community dedicated to advancing diversity, equity, and inclusion within open source. All In for Students is a paid, 12-month program for select college students from underrepresented backgrounds. During the program, students will receive professional development training, open source education, a structured 12-week open source project, and ultimately have the opportunity to join one of our corporate partners for a summer internship experience.

Envoy is an open source edge and service proxy, designed for cloud-native applications.

FINOS (FinTech Open Source Foundation - part of the Linux Foundation) is looking for a summer marketing intern to assist with: - Marketing research (members, projects, BD) - Social media (research, operations) - Content for website (research, operations) - Podcast production (research, operations)

The RISC-V Mentorship Program enables one or more 12-week internship-style projects per session, funded by RISC-V, to match mentors/project leaders together with mentees/interns . Mentees are guided through a series of milestones by one or more project mentors, with whom the mentees meet on a weekly basis. Convolution is the core operation of deep learning models and computer vision applications. MLIR supports various convolution operations. Our project is to vectorize them for the RISC-V backend. There are several methods to implement convolution vectorization, such as optimizing nested loops, implementing vectorization algorithm, converting to GEMM, etc. This project needs to choose a vectorization method and implement a conversion pass for the convolution operations. As for the vector semantic support, MLIR has the “Vector” dialect for the general vector abstraction, and it also allows the backend-specific vector dialect, such as the “x86vector” dialect, “arm_neon” dialect, and “arm_neon” dialect. Like these dialects, the project also needs to propose an “RVV” dialect and work with existing dialects and tools. Deliverables: - An MLIR “RVV” Dialect. (Operations in the dialect can support the convolution vectorization) - A conversion pass to vectorize convolution operations in “Linalg” dialect with “RVV” dialect enabled. - A conversion pass to lower the operations in “RVV” dialect to “LLVM IR” dialect. - Unit tests for “RVV” dialect and conversion passes.

The Software Package Data Exchange (SPDX) is an open source standard for communicating software bills of material information (including components, licenses, copyrights and security references). To support SPDX, an online tool has been developed which provides an easy all-in-one website to upload and parse SPDX documents for validation, comparison and conversion and search SPDX license list. This project will provide enhancements and support for the online tools including: - More automated and high-quality deployment for software updates - Removing some of the dependencies on a Python Java Bridge by moving features like license matching over to a native Python implementation - Improving performance and quality of the online tools implementation

Hyperledger Cactus is a blockchain decentralised integration tool designed to allow users to securely integrate different blockchains started by companies Fujitsu and Accenture. Cactus has pluggable architecture which makes easy to integrate various blockchain by creating plugin, currently plugins for Fabric, Besu, Quorum are implemented. Cactus allows to transfer not only assets but also data between multiple blockchains. On the other hand Iroha (version 1.x) is great with asset management, and has functionality to store data, which makes those two projects a perfect fit! With this internship we will not only allow the interoperability between different blockchains but also create a system of Iroha networks that will also demonstrate the integration in examples easy to run by everybody. The mentee will be able to learn: 1) ways of integrating different projects from architectural point of view, 2) architecture of Iroha (1.x) and Cactus, 3) work in true spirit of open-source, communicating with both Iroha and Cactus community, joining calls and using other community tools, 4) writing documentation, so anyone in the community could use the results of their work, 5)following rules and standards of open-source projects created by hyperledger Expected Outcome 1) Documented, ready-to-use integration of Iroha and Cactus, 2) Documented example of integration between multiple (two and more) iroha's networks with Cactus, 3)Documented example of integration between Fabric and Iroha