Explore Projects

The goal of this project is to get syzkaller, a coverage-guided OS kernel fuzzer, working under FreeBSD/RISC-V. As syzkaller is written mostly in Go, the first step is to ensure that Go is able to compile syzkaller. Previous work can be harnessed from two projects to make this tractable. First, Go has a RISC-V port targeting GNU/Linux, and second, the CHERI project has a FreeBSD/mips port of Go. The next step is to add FreeBSD/RISC-V support to syzkaller itself. A work-in-progress patch for FreeBSD/arm64 support can be used as a template. Two bonus tasks are: 1. upstream Go support for FreeBSD/RISC-V to the Go Project, and 2. begin fuzzing system calls under FreeBSD/RISC-V. Syzkaller is flexible enough to target OS interfaces other than system calls. For example, it has been used to fuzz the Linux USB stack and has found dozens of bugs in the USB subsystem alone. The details are complicated, but the idea is simple. 1. Generate a program, which invokes one or more system calls. 2. Run the generated program. 3. Check to see if the system diagnosed an error. - If not, collect kernel code coverage information and decide whether to try iterating upon the previous test program, or start anew. - If so, collect information about the crash and try to discover a minimal test case that triggers the crash. The mentors will have weekly meetings with the mentee to discuss progress and strategies for overcoming any challenges.

Description: Notary is a CNCF incubating project that aims to provide signing and verification capabilities to ensure delivery integrity and security. It supports creating and storing signatures for container images, SBOM, vulnerability scanning results, etc. to ensure the artifacts someone produced have not been tampered by others. Notary only has an Azure Key Vault plugin for storing keys in Azure Key Vault, which is used to sign and verify artifacts in the OCI registry. [HashiCorp Vault](https://github.com/hashicorp/vault) is a popular KMS and we see more and more users rely on it in the on-premise environment. Expected Outcome: Develop a Key Management System (KMS) plugin with [HashiCorp Vault](https://github.com/hashicorp/vault) for Notary CLI (Notation), which can be used to store the keys for Notation signing and verification.

A VS code extension and toolbox to debugging a chaincode. The extension once installed can be used by developers of chaincode to run and debug from their IDE, to understand how their chaincode behaves. The current process of installing the chaincode, adding the logs, running it through a test network for operational efficiency is not ideal for a faster development cycle. There is also a dependency on number of tools and commands that a developer would need to be aware of before developing the chaincode. The scope of this project is to utilize one of the existing deployment means for the chaincode, then provide a debugger from the VS code through a plugin. Expected Outcome and Deliverables - Develop a plugin that can be installed and run on any developer machine. - Ideally, one should be able to develop on any operating system, be it a Mac, Windows, or any of the Linux variant. - Debug the chaincode as the developers are used to writing their code, as opposed to learning administrative aspects. At times reproducing a production scenario is all it takes to fix an issue, and it may get complicated with patch fixes. - Option to initialize the state database so that the debugging can be effective. - This is a futuristic goal to achieve with the project. - Primary goal is for the chaincode to be deployment ready at the end of the development cycle. The deliverable is the working VS code plugin.

SPIRE (https://spiffe.io), the SPIFFE Runtime Environment, is an extensible system that implements the principles embodied in the SPIFFE standards. SPIRE manages the platform and workload attestation provides an API for controlling attestation policies and coordinates certificate issuance and rotation. Being a critical system, it is important that operators be able to monitor (and respond to) the current health/state of their SPIRE deployments. To do this, SPIRE needs to grow a full-featured health subsystem that is capable of collecting the status of other subsystems and reporting on it. In this project, you will design and implement this new subsystem with the help and guidance of the SPIRE maintainers.

Increasingly, edge locations are becoming Kubernetes (K8s) based as K8s can support multiple deployment types (Virtual Network Functions, Containerized Network Functions, Virtual Machines and containers). ONAP4K8s is the project that enables ONAP to deploy workloads in K8s based sites. ONAP4K8s enables operators to use a K8s based sites to deploy workloads. In ONAP they can use this to deploy workloads on both Openstack based sites as well K8s based. It also enables usage of common compute resources for both network functions and applications, thereby utilizing compute infrastructure efficiently. ONAP4K8s is being extended to support deploying and connecting apps/services that span across multiple clusters. Major work items where intern can help are – 1. API enhancements 2. Improve code coverage 3. Adding support for application upgrades 4. Adding test cases for new use cases 5. Improving monitoring, tracing, logging of microservices

KubeEdge 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 60% to 70% (currently, the UT coverage rate is 38.69% ). It is important to note that in addition to requiring the overall UT coverage of KubeEdge to meet the requirements, the UT coverage of each core code directory (cloud/, edge/, keadm/ and pkg/) also needs to exceed 60%. Expected Outcome: Increase the UT coverage rate to 60% to 70%

Refactor the ORAS documentation structure and write new user guides based on the latest version of ORAS. The detailed ORAS documentation structure and content should be refactored according to the proposal in the [upstream issue](https://github.com/oras-project/oras-www/issues/65). - Expected Outcome: Deliver a developer-friendly documentation structure for ORAS and write new user guides according to the proposed documentation structure. Publish all content at https://oras.land/

<p>Meshery's CI/CD infrastructure spans a large and growing collection of GitHub Action workflows that have accumulated technical debt - inactive workflows, insecure patterns, and duplicated logic. This internship has two phases: first, a comprehensive audit and restructuring of existing workflows; second, the introduction of [GitHub Agentic Workflows](https://github.github.com/gh-aw/) to bring Continuous AI capabilities to Meshery's repository automation. Agentic Workflows allow automation to be defined in plain markdown and compiled into guardrailed GitHub Actions that run AI agents (Copilot, Claude, Codex) on schedule or in response to events - enabling automated CI failure triage, PR analysis, issue management, documentation maintenance, and compliance scanning with minimal human intervention.</p><p><br></p><p>Recommended Skills: GitHub Actions workflow authoring, CI/CD concepts, YAML, supply chain security basics (secret hygiene, fork-safe triggers, pinned actions). Interest in AI-assisted automation is a plus.</p><p><br></p><p>Responsibilities:</p><p>&nbsp;- Audit all workflows in `meshery/meshery`, cataloging each by type, activity status, and identified issues (duplication, insecurity, staleness).</p><p>&nbsp;- Produce a structured report with prioritized remediation recommendations, then implement accepted changes - consolidating redundant workflows and hardening insecure patterns.</p><p>&nbsp;- Author workflow taxonomy definitions (security classification levels, workflow types) for the Meshery Build and Release docs.</p><p>&nbsp;- Design and contribute agentic workflow definitions using the `gh aw` framework - covering CI failure diagnosis, PR feedback summarization, issue triage, and documentation consistency.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- Measurably reduced and consolidated workflow set with no inactive or redundant workflows remaining.</p><p>&nbsp;- Published audit report and workflow taxonomy added to docs.meshery.io.</p><p>&nbsp;- A suite of agentic workflow definitions (`.md` + compiled `.lock.yml`) committed to the repository, demonstrating Continuous AI applied to Meshery's software delivery lifecycle.</p><p><br></p>

Istio extends Kubernetes to establish a programmable, application-aware network. Working with both Kubernetes and traditional workloads, Istio brings standard, universal traffic management, telemetry, and security to complex deployments Istio does not support HTTPs based metric scraping for control plane, gateway, and Envoy sidecar metrics This could have some security related consequences: - An attacker might find some sensitive information that they can use for their advantage. For example, Envoy /stats endpoint can be used to enumerate all upstream services in the cluster. - In theory an attacker could masquerade the metrics endpoint(s) and inject fake data to monitoring systems, in order to e.g. hide an ongoing attack, confuse the system to autoscale up/down etc. It would be nice to protect the metrics endpoints with TLS, using mutual authentication. While this feature is a big one covering multiple components, the easiest component alone is intended to be covered as part of this internship. Expected Outcome: - Implement HTTPS metrics for ztunnel component - Add unit tests and integration tests for the feature - Add documentation for the functionality

Currently Vitess has a rich set of functional tests that are run as part of every commit to catch regressions early. However, they are not sufficient to assess the quality of the product for production rollout. We currently do not test for incompatibilities introduced via upgrade, and ensuring that users can downgrade one level if they need to backout of a failed upgrade. The scenarios will need to be written down, and then tests can be written using GitHub actions: - Document Supported Upgrade/Downgrade Scenario

Current Thanos topology is generally horizontally scalable. However, the use cases and approaches of deploying Thanos shifted through time. While initially, Thanos was enabling ingestion through sidecars, now it’s not uncommon to see Thanos receiver usage. This means that the invariant of definite size TSDB block is no longer true. With offline deduplication and arbitrary Receive tenants data can be ingested into huge, often hundreds GB size TSDB blocks. This makes it harder to scale compaction and query operation on top of such blocks. The idea of this work is to vertically split larger blocks into smaller ones with the common scaling technique called sharding. As a mentee, we will guide you to make progress towards this goal by teaming up with experienced developers to deliver transparent automation for vertical block sharding! We are looking forward to working with you! During this mentorship, you will learn a lot about programming in Go, distributed Systems, TimeSeries Database, Prometheus, Thanos!

Kubernetes currently uses Kubetest as the interface for launching and running e2e tests. There is a new [kubetest2](https://github.com/kubernetes-sigs/kubetest2) that is in the process of being developed and will need to be rolled out to various CI harnesses and jobs. As part of this project we will focus on SIG-Node related CI jobs. Here's how we currently test SIG-Node related code - [e2e-node-tests.md](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md). There will be a lot of interesting problems to solve and this work is critical to how we test kubernetes not just in GCP, but also across all the other cloud providers going forward.

Description: This project will add new useful sample applications to the Certifier Framework including a secure messaging app and several key management applications. In addition, we plan to support more platforms, including client platforms like RISC-V, ARM, Raspberry Pi based implementations and potentially a "soft" platform like Android (which is not an "official" Confidential Computing platform but a simulated environment useful for interacting with "real" Confidential Computing platforms). Expected Outcome: The forgoing applications (using the certifier framework), some additional "shims" to support other programming environments like Java and additional support for new platforms.

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.

Description: Create MeshMark provides a universal performance index to gauge your mesh’s efficiency against deployments in other organizations’ environments. MeshMark functions as a service mesh performance index (a scale) to provide people the ability to weigh the value of their service mesh versus the overhead of their service mesh and assess whether they are getting out of the mesh what they are “paying” for in it. Work with maintainers from Layer5, Intel, Red Hat, and HashiCorp on researching cloud native infrastructure performance. Internship involves: machine learning, adaptive algorithms, running and analyzing performance statistics.

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