Explore Projects

Apache HugeGraph's query engine relies on Java 11, TinkerPop 3.5.1, and Groovy 2.5.x, facing critical issues: the security sandbox depends on Java's deprecated SecurityManager and a blacklist already bypassed in CVE-2024-27348, while TinkerPop 3.5.x lacks 26 new Gremlin steps, GraphBinary, and JDK 17 support. This project will execute a phased upgrade to Java 17 + TinkerPop 3.7.x + Groovy 4, covering full TinkerPop API migration with custom Steps/Strategies adaptation, a security sandbox redesign from runtime blacklist to a three-layer compile-time whitelist defense using Groovy 4's @CompileStatic and AST Customizers with configurable enforcement modes (strict/warn/off), extension to PD/Store distributed modules, and performance benchmarking on the Twitter-2010 dataset. Deliverables include the upgraded codebase (PR), the new compile-time security sandbox, PD/Store module upgrade, a quantified performance benchmark report, full regression test reports, and a complete documentation set.

This project focuses on developing modular data preparation workflows within the PEcAn ecosystem to support ecological modeling.It targets the integration of diverse data sources for meteorology (e.g, NARR, ECMWF/ERA5, Ameriflux), soil (e.g, gSSURGO, SoilGrids, BADM), and vegetation initial conditions (e.g, LandTrendr AGB, BADM, bespoke CSV files)—and generate ensemble-based initial condition files. The goal is to create ensemble-ready inputs that enable sensitivity and uncertainty analyses. As a stretch goal, the project will implement an integrated workflow that runs the SIPNET model over these ensembles and performs variance partitioning to quantify the contribution of each data source to model output uncertainty. Current variance decomposition in PEcAn only supports parameter uncertainty. This project aims to address this gap by developing modular data preparation workflows that propagate and analyze uncertainty from multiple sources—including parameter, meteorological data, soil data and vegetation initial conditions. Deliverables include reusable R functions, data preparation modules, documentation, and example workflows integrated into the PEcAn system.

RNTuple is ROOT's next-generation columnar data format for High Energy Physics. Its storage layer is decoupled from its format layer, enabling new backends. This project implements a S3 storage backend for RNTuple, allowing datasets to be written to and read from S3-compatible object stores such as CERN's Ceph S3 and AWS S3. The approach introduces a new S3 locator type with two addressing modes: packed pages with multi-range GET for servers that support it, and one-page-per-object with concurrent GETs for those that do not. A JSON anchor at the base URL provides the entry point with a templated URL scheme for forward compatibility. The implementation adds RPageSinkS3 and RPageSourceS3 classes using the existing RCurlConnection as the transport layer, extended with PUT support and concurrent I/O via curl multi handles. Deliverables include the complete write path (Phase 1-2), complete read path with optimized cluster loading (Phase 3-4), RCurlConnection extensions for PUT and concurrent I/O, and a comprehensive test suite covering wire-level tests, locator round-trips, integration tests against MinIO and CERN Ceph S3, and performance benchmarks.

openPIP is an open-source platform for hosting and visualizing protein-protein interaction (PPI) data. The current version is built on a PHP 5.6 / Symfony 2.8 stack that has reached end-of-life, making it difficult to maintain and extend. This project performs a complete rewrite of openPIP using modern web frameworks: a React single-page application frontend with Cytoscape.js for network visualization, a REST API backend (Python/Django REST Framework or Node.js/Express, to be finalized with the mentor), and a PostgreSQL database, all containerized with Docker. Key deliverables include: (1) a clean REST API replacing the 27 monolithic PHP controllers, (2) an enhanced data upload pipeline supporting PSI-MI TAB and CSV formats with drag-and-drop, real-time validation, and async processing, (3) a responsive React frontend with interactive search, network visualization, and an admin panel, (4) production-ready Docker Compose deployment, and (5) a data migration script for existing openPIP deployments (HuRI, YeRI). I have direct experience with the openPIP codebase, having created its deployment guide and migrated the platform from openpip.baderlab.org to openpip.usask.ca.

The Hash Time Locked Contract (HTLC) is a well-known pattern for dis-intermediated asset swaps, i.e., as a mechanism to exchange assets between two parties in two different blockchain networks in an atomic manner without a trusted mediator (or trusted third party). HTLC support has been implemented in the Hyperledger Weaver Labs project, with mechanisms to lock, claim, and unlock assets supported in both the contract and higher application layers. At present, the protocol requires several manual steps by the application users carrying out the exchange or agents acting on their behalf. We would like to automate this process as much as possible by augmenting the relay module in Weaver to communicate events and trigger transactions in foreign networks; this requires both research and software development. Further, HTLC is known to have flaws that could violate system integrity properties, because it relies on parties to execute certain actions by a certain timeout or forever lose the opportunity to carry out those actions; this makes the basic protocol intolerant to system crashes. Research is needed to (provably) determine the best way to make the HTLC protocol fault tolerant, using the features of the blockchain networks maintaining the assets and the Weaver relays mediating the exchange. Augmenting the existing HTLC mechanism within Weaver will provide practical validation of this research.

Cephalopods display complex behavioral states such as stress, curiosity, aggression, and comfort, but interpreting these states currently depends on expert manual observation and lacks scalable, reproducible tools. This project will build an open source multimodal pipeline that automatically infers and classifies cephalopod behavioral sentiment from video and optional bioacoustic data using computer vision and deep learning. The pipeline will include a dataset ingestion and preprocessing module supporting common video and audio formats, a behavioral feature extractor capturing locomotion, skin pattern dynamics driven by chromatophores, and body posture changes, and a sentiment classification system mapping extracted features to labeled behavioral states. A lightweight deployment API and interactive demo dashboard will make the system accessible to researchers and educators. Key deliverables include dataset ingestion and preprocessing scripts, a multimodal model baseline combining video and optional audio streams, a behavioral feature extraction module for movement and color and posture signals, a sentiment label classifier with training and evaluation scripts, full documentation with reproducible experiments, and a REST API with a demo dashboard for inference. The system will be designed for extensibility across species, datasets, and deployment environments including edge devices.

The project focuses on improving the functionality and usability of key components in the Eventyay platform, specifically the talks, tickets, and video modules and integrating them into a cohesive, unified system. The goal is to streamline event management by ensuring consistent user experience, reliable data handling, and simplified admin operations. Work includes fixing existing bugs in the ticketing and talk modules, refining attendee and speaker management flows, and aligning data models across tickets, sessions, and users. The contributor will optimize database interactions, implement input validation and error-handling mechanisms, and enhance admin interfaces to allow efficient management of attendees, speakers, sessions, and video resources from a single dashboard. Additionally, integration tests will be written to ensure system stability and prevent regressions during development. The contributor will also provide updated documentation reflecting the improved workflows and interfaces. These efforts aim to create a maintainable, scalable platform that supports a seamless experience for both event organizers and attendees. As part of the ongoing development process, the project also includes maintaining the documentation for the unified platform. This involves ensuring that the deployment of documentation works correctly, keeping it up to date with recent changes in the system architecture, and revising content as needed to reflect new features and workflows.

<p>The main goal of this year's GSoC was to develop <a href="https://github.com/fossasia/badgeyay" target="_blank"><strong>Badgeyay</strong></a> into a complete Service with services ranging from simple to complex functionalities which include :</p> <ul> <li>Modularizing the API and follow the best standards.</li> <li>Improving the Rest API and Resolving the known bugs.</li> <li>Improving current UI of Badgeyay and changing it along with GSoC Period by Using Ember JS and Semantic UI.</li> <li>Improving the Badge Layout and provide more features to the user. </li> <li>Implementing User Authentication and Integrating database management system into Badgeyay. </li> <li>Implementing a Badge Management System.</li> <li>Implementing Admin Panel.</li> </ul> <p>Tech Stack:</p> <p>The whole front end is shifted to Flask template to MVC frontend framework Ember JS. Everything in the frontend is divided into components and chaining of actions and models have been implemented. Semantic UI is used for styling purposes.</p> <p>The whole API is redesigned to follow JSON API specification using the marshmallow to make it compatible with data coming from Frontend. Firebase is also used to support admin and authentication functionalities from the backend flask server.</p>

The proposal aims to develop an innovative, accessible mobile application to address the specific challenges faced by visually impaired students in their learning process. The app goes beyond traditional resources by utilising sound, touch, device sensors, and interactive elements to create a multi-sensory learning experience. This approach aims to improve engagement, understanding, and retention of key mathematical concepts. The proposal highlights my strong interest in accessibility software solutions, a relevant background in Android development, and a desire to use technology to make a positive social impact. Through my research, I have demonstrated the use of existing accessibility tools and outlined a comprehensive project plan that includes: 1.)Interactive modules: Lessons on basic arithmetic, cardinal directions, trigonometry, geometry, metric systems, and more. The modules thoughtfully leverage device features like magnetometers, gyroscopes, and accelerometers. 2.)Story-based learning: A story mode with auto-generated MCQs potentially using TensorFlow Lite for comprehension and assessment. 3.)Accessibility focus: Thorough consideration of screen reader compatibility, audio and haptic feedback, and support for Braille displays and switch access. 4.)Iterative development: A detailed timeline with a community bonding period, regular milestones, testing, and a phase for incorporating user feedback. The idea of this proposal aligns closely with Zendalona's mission.

The project focuses on upgrading the Eventyay platform components to VueJS 3 within the unified Eventyay codebase. While minor adjustments are required for the ticketing components, the primary focus lies on modernising the talk and video modules, which currently rely heavily on VueJS 2, as well as on updating project-specific plugins. The objective is to replace all existing VueJS 2 code with VueJS 3 across the entire platform while preserving existing functionality and API compatibility. As the Eventyay platform is being consolidated into a single repository, the project also includes implementing additional API features where necessary to support the unified infrastructure. The upgrade improves the maintainability and performance of the platform, aligns it with current best practices, and ensures long-term sustainability of the frontend codebase. Throughout the project, Vue dependencies are upgraded, and components are systematically refactored to address breaking changes introduced in Vue 3. Extensive compatibility testing is carried out to ensure stability across all migrated features. Updated components are made fully functional under Vue 3, with a gradual transition from the Options API to the Composition API where appropriate, leveraging the benefits of improved structure, reusability, and maintainability. In parallel, the continuous integration pipeline is refined to support automated testing and deployment, including the seamless rollout of updated documentation that reflects the evolving architecture and feature set of the unified platform.

As we plan to take the PSLab project to the next level, developing multiplatform support for the app and enhancing its communication capabilities are key to making PSLab more accessible and effective for students, educators, and science enthusiasts across diverse environments. Currently, the Pocket Science Lab (PSLab) mobile application is available only for Android, limiting its usability in institutions where iOS, desktop, or web platforms are widely used. This project aims to rebuild the existing Android app using Flutter, enabling support for Android, iOS, desktop (Windows, macOS, Linux), and web, all from a single codebase. Flutter’s flexibility and performance make it an ideal choice for this cross-platform transformation, ensuring a smooth user experience across all device types and screen sizes. Another crucial part of this project is enhancing the hardware communication layer to accommodate platform-specific constraints—particularly Apple’s restrictions on USB communication. To address this, the project will implement Wi-Fi-based connectivity using the ESP01 chip, allowing seamless data transfer between the app and the PSLab hardware across all platforms. This ensures that iOS and web users are no longer at a disadvantage and can fully utilize the PSLab instruments. By the end of the project, the app will offer a robust, real-time interface for core instruments like the Oscilloscope, Logic Analyzer, Multimeter, and Robot Controls, complete with interactive visualizations.

Haskell Language Server (HLS) currently supports Goto Definition only for symbols defined within a user’s project, making it difficult to inspect implementations of functions imported from external dependencies. This project extends that functionality to third-party libraries by enabling developers to navigate directly to dependency source code from within their IDE. The solution leverages .hie files generated by GHC and indexed via HieDb. During HLS startup, dependency HIE files will be discovered and indexed, allowing symbol lookups to resolve to external modules. When a user triggers goto definition on a dependency symbol, the corresponding source code will be extracted from the HIE file, written to a deterministic location, and opened in the editor. To ensure correctness, a type-level rule system will be introduced to prevent invalid rule execution on dependency files, replacing the current fragile runtime whitelist approach. The project deliverables include: rebasing and stabilizing the existing prototype (PR #3749), implementing a type-safe rule constraint system, ensuring complete rule coverage across file types, improving user experience through automated HIE file generation and indexing, enforcing read-only handling for dependency files, and exploring solutions for supporting boot libraries via prebuilt HIE artifacts. These improvements aim to deliver a robust, maintainable, and seamless dependency navigation experience in HLS.

Arterial Spin Labeling (ASL) is a non-invasive MRI technique that measures cerebral blood flow and supports studies on Alzheimer’s disease, stroke, and other neurological conditions. Yet existing software remains rigid, difficult to customize, and often restricted to brain-only research. Flexible ASL (PyASL) introduces a redesigned, developer- and user-friendly architecture that makes advanced ASL analysis accessible to a wider scientific community. Key innovations include: (1) Minimum programming knowledge required — run complete pipelines with more intuitive alternatives, such as YAML config, python notebook, command line interface, etc; (2) Mix & match preprocessing steps — combine algorithms from different pipelines without rewriting the code; (3) Easy plug-ins — add new preprocessing modules with minimal setup; (4) Support for integrating machine-learning models, custom statistics, and quality-control tools; (5) Extensibility beyond the brain to other organs, promoting cross-disciplinary imaging research. This system can cut integration time for new models or analysis steps by 60–80%, reduce development overhead, and foster reproducibility and cross-functional collaboration among clinical and technical teams. By bridging clinical imaging and modern AI, Flexible ASL lowers barriers for both novices and experts, helping to accelerate innovation in non-invasive perfusion imaging.

Effective connectivity analyses are a staple of many neurophysiological research projects, providing key insights into the healthy functioning of the brain and pathological alterations with disease. MNE-Connectivity leverages the API of the highly-popular MNE-Python signal processing package to provide tools for computing such connectivity. However, given the complexities associated with studying interactions in the brain, it is critical that the metrics for estimating connectivity are robust, and the estimates themselves statistically significant. Naturally, it is essential that such tools are available in open-source toolboxes, something we will address in this project. First, building on recent work in the MNE-Connectivity toolbox, we will implement further support for advanced multivariate connectivity metrics in the form of a dedicated decoding module. This module will provide flexible tools for the data-driven analysis of connectivity that is critical for robust characterisations of network activity in multi-channel recordings. The only comparable implementations of such methods are in toolboxes for the proprietary language MATLAB, limiting the availability of these tools to the wider research community. Second, we will expand the existing set of statistical features available in MNE-Python to include tools for assessing the statistical significance of estimated connectivity, crucial for distinguishing genuine interactions from background noise. In all cases, new features will be complemented with detailed examples and tutorials in the MNE-Connectivity documentation. Altogether, the project will expand the repertoire and quality of open-source tools available for studying connectivity in the brain, a cornerstone of modern neurophysiological research.

<p><strong>Federated internet data obtainer</strong> (Fido) is a very powerful query and fetch interface when it comes to its flexibility and versatility with different types of clients and query attributes. The data archives available at various FTP and HTTP sites mostly offer file-based records accessible easily through time ranges, and Fido evolved to efficiently handle such queries.</p> <p>This project will be an attempt to refactor the net module by standardizing all client classes and their responses. It will enable Fido to parse metadata queries and allow users to inspect them as well; particularly for meta-specific clients like <code>HEK</code> and <code>HEC</code> Clients. The project will also attempt to solve download failures with <code>JSOC</code> and <code>VSO</code> as in <a href="https://github.com/sunpy/sunpy/issues/3336" target="_blank">Issue #3336</a> and <a href="https://github.com/sunpy/sunpy/issues/3733" target="_blank">Issue #3773</a> respectively. Finally, this project will enable post-search filtering features for all clients of <code>sunpy/net</code> and use <code>scraper</code> objects to scrap all attributes for a response table from the data archives. This would be followed by writing pytests for various untested functions in the module.</p> <p>The project will end with easy interpretable documentation of code and gallery examples wherever possible.</p>

The Pharo VM is written in Slang, a Smalltalk subset that is transpiled to C by the CCodeGenerator. Currently, the entire VM is generated into a handful of large monolithic C files where code from completely different subsystems the garbage collector, the interpreter, and the JIT compiler are all merged together into a single output stream. This makes the generated code difficult to read, navigate, and maintain, and means that changing a single method triggers recompilation of the entire VM rather than just the relevant module. This project introduces separate compilation to Slang by refactoring CCodeGenerator to route generated C code into multiple files, one per class hierarchy, while correctly tracking and emitting #include dependencies between them. The approach involves extending CCodeGenerator to maintain per-hierarchy output streams, implementing a dependency graph builder to determine which hierarchies reference which others, generating corresponding header files with the necessary forward declarations and prototypes, and updating the CMake build system to automatically discover the new files. The deliverables are: a working dependency graph builder for TMethod objects, a refactored CCodeGenerator supporting multiple output streams, successful extraction of the SpurMemoryManager garbage collector hierarchy into its own standalone C file with correct includes as a proof of concept, header file generation for all separated modules, extension of separate compilation to the Cogit JIT compiler and remaining hierarchies, and an updated CMake build configuration. All existing VM tests will pass throughout, ensuring no regressions in the generated code.

My proposal aims to increase the level of context that Pwndbg provides when stepping through a binary by “annotating” the results of instructions. Alongside the disassembled machine instructions in the dashboard, there would be text to indicate the action that each instruction takes, such as moving values between CPU registers, writing data to memory, or doing a mathematical operation. We would resolve the concrete values that memory and CPU registers take on after each instruction, providing relevant information that the user would otherwise have to fish out manually using a GDB command that varies depending on the context. Pwndbg is starting to support this annotation feature for the x86 architecture. My project would add these annotations to other architectures supported by Pwndbg, namely 32-bit Arm, 64-bit Arm, RISC-V, and MIPS. This not only aids in debugging and reverse engineering, as you would gain much-needed context as to the results of instructions, but there is also an educational benefit in that you can visually see what each instruction is doing while stepping through a binary. We would additionally create annotations for future instructions in the disassembly view using emulation. By combining the Unicorn Engine, a CPU emulator framework, with the Capstone Engine, a disassembly framework, we can provide the user with insight into the next handful of instructions, providing more context and increasing debugging efficiency. Deliverable - A series of pull requests which add annotations for instructions for Arm, AArch64, RISC-V, and MIPS inside the “disassembly” view of the Pwndbg dashboard - A rewrite of the parent class API to make adding annotations to new architectures more simple - Add the ability for the recursive printing of pointers inside the annotations to provide enhanced information on pointers inside heap memory, such as internal heap manager metadata - Documentation and tests to aid future contributors and reduce chance of regressions

This project implements comprehensive patient-facing digital health capabilities in the CARE platform by integrating Ayushman Bharat Digital Mission (ABDM) Personal Health Record (PHR) flows. While CARE currently supports provider-side health information exchange through the existing ABDM module, it lacks patient-centered features that would allow individuals to access and control their health data. My solution builds a complete set of APIs and interactive user interfaces to bridge this gap by implementing seven key components: ABHA Enrollment - Digital identity creation with multiple verification methods Profile Login - Secure multi-channel authentication and session management User Profile Management - Personal health information control and preferences Discovery and Linking - Finding and connecting fragmented health records Subscriptions & Notifications - Automated health updates and alerts Consent Management - Granular control over data sharing permissions Health Record Display - Unified view of medical history across providers The implementation seamlessly integrates with the existing ABDM module while adding complementary PHR capabilities, enabling CARE to function effectively in dual roles—as both a provider-focused clinical system and a patient-centered health record platform. Deliverables include a fully functional implementation of all ABDM PHR APIs, an intuitive and responsive patient portal interface, comprehensive transaction tracking for compliance, and thorough documentation. All components will adhere to healthcare security and privacy standards while providing a cohesive user experience. The completed project will transform healthcare delivery by eliminating information gaps between providers and empowering patients as active participants in their care journey.

This project aims to deliver a fully-featured, cross-platform canvas-based editor for the Magic ePaper Badge, built entirely in Flutter without relying on third-party libraries. The application empowers users to create intricate badge designs with a highly customizable interface tailored specifically for ePaper screens, supporting tri-color rendering (red, white, black) and precise editing controls. Key features include a custom drawing canvas with gesture-based freehand and line drawing tools, a text overlay system with support for font selection, scaling, rotation, and locking, and an image import module allowing for multi-image manipulation on the canvas. A layer manager provides real-time reordering of image and text overlays, mirroring professional design software like Photoshop. A polished preview and export pipeline ensures clean final renders. Users can crop and adjust the final image with brightness and contrast controls before exporting it at the badge’s native resolution (240x416). The result is optimized for both BWR and BW UC8252 display variants. The project also includes robust NFC integration. I resolved critical issues in the original codebase, such as improper handling when NFC was disabled. I implemented a native Android method that navigates directly to the system’s NFC settings screen, significantly improving UX and cross-device reliability. The app now ensures seamless transmission of finalized designs to the ePaper badge over NFC. By implementing all functionality from scratch, this project delivers a performance-optimized, extensible editor tailored for the Magic ePaper Badge ecosystem, advancing FOSSASIA’s vision of accessible, user-driven customization tools.

<p>The [OpenTelemetry Go Compile Instrumentation](https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation) project provides `otelc`, a compile-time auto-instrumentation tool for Go applications. It injects OpenTelemetry instrumentation during the Go build process without requiring manual source-code changes in the target application. As the project moves toward its v1.0 release and continues feature-parity work with mature compile-time instrumentation efforts such as [Orchestrion](https://github.com/DataDog/orchestrion) and [Loongsuite](https://github.com/alibaba/loongsuite-go-agent), the next phase is to broaden real-world library coverage while hardening the tooling and contributor workflow needed to maintain those integrations over time. This mentorship focuses on adding several mentor-approved integrations from the project roadmap and backlog, such as messaging, database/cache, logging, Kubernetes client, or GenAI SDK libraries, while improving `otelc` whenever the integration work exposes gaps in rule authoring, hook implementation, testing, or debugging. The mentee will also document the science behind compile-time instrumentation: how Go symbols and versions are matched, how hooks are injected, how OpenTelemetry semantic conventions are applied, and how compatibility is verified across library releases.</p><p><br></p><p>Expected Outcome:</p><p> - Add `otelc` instrumentation support for 3-4 widely used Go libraries selected with mentors from the project roadmap/backlog, depending on complexity and project priorities.</p><p>&nbsp;- For each new integration, implement instrumentation rules and hook code, define supported version ranges, and follow the relevant OpenTelemetry semantic conventions.</p><p>&nbsp;- Add meaningful unit, integration, and/or end-to-end tests that verify the instrumented application builds and emits the expected telemetry.</p><p>&nbsp;- Improve the instrumentation tooling or contributor workflow as needed during the work, for example rule validation, hook scaffolding, latest-library compatibility checks, integration layout, or debugging output.</p><p>&nbsp;- Write documentation, examples, and demos that explain how to use the new integrations and how future contributors can build similar ones.</p><p><br></p>

<p>Design and implement a secure, auditable platform that enforces pre-execution authority for delegated actions initiated by humans, AI agents, and services. The platform will provide a single gateway for policy-driven request routing, a secret vault for API keys and credentials, and a delegation graph model to represent and evaluate long/deep delegation chains with real-time revocation and immutable proofs recorded to a ledger. Initial work will implement core components (gateway, policy evaluator, delegation graph, secret vault integration, immutable audit records) and end-to-end flows for common delegation scenarios. Later work will extend policy negotiation between agents, security reasoning modules, and audit reporting that derives intent and policy-improvement recommendations. The goal is a practical mentorship project that teaches secure authority delegation, DLT-backed auditability, and interoperable identity and credential patterns.</p><h3><br></h3><h3>Learning Objectives</h3><ul><li>Understand and implement delegation models and graph-based authority evaluation.</li><li>Build a policy-driven gateway that enforces pre-execution checks and real-time revocation.</li><li>Integrate secure secret storage and key management for service/API credentials.</li><li>Record tamper-evident audit trails on an immutable ledger and derive actionable audit reports.</li><li>Apply decentralized identity / verifiable-credential concepts to authorize principals (human, agent, service).</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><ul><li>Working prototype of a single gateway enforcing policy-checked executions with revocation support.</li><li>Delegation Graph module with algorithms for evaluation and path resolution.</li><li>Secret Vault integration (API for storing/retrieving encrypted keys) and sample connectors.</li><li>Immutable audit-log storage adapter (ledger integration) and a basic audit-report generator.</li><li>Documentation: architecture diagram, developer guide, onboarding tasks, and end-to-end test scenarios.</li></ul><p><br></p><p>Learn More at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/78" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/78</a></p>

<p><strong>*APPLICATION ONLY OPEN TO COLLEGE STUDENTS BASED IN CHINA*</strong></p><p><br></p><p><strong>Problem Statement</strong></p><p><br></p><p>Software refactoring and restructuring is common in the open-source development of SONiC. Existing code structure may limit the adoption of new usage scenarios or protocol features, necessitating its refactoring into a better logical structure. For example, the ongoing RIB/FIB project intends to separate the RIB and FIB maintenance code in Zebra and move the latter down to SONiC’s fpmsyncd component. Since fpmsyncd resides in SONiC code space, it allows FIB to construct SONiC specific forwarding chain, and handle route convergence based on SONiC’s requirements.</p><p><br></p><p><br></p><p><strong>Mentorship Objectives</strong></p><p><br></p><p>A central requirement in such refactoring is to ensure that behavior changes are exactly as expected. In the RIB/FIB example, it requires that normal executions must be equivalent before and after the refactor. The objective of this mentorship is to devise a systematic approach to validate behavioral equivalence during SONiC refactoring. More specifically, it involves applying formal methods to mathematically describe the intended behavior, compare two distinct setups, and generate comprehensive tests to ensure the consistency before and after the refactor. This will serve as an exemplar of the formal-methods-based correctness paradigm in production code development.</p><p><br></p><p><br></p><p><strong>Expected Outcomes and Deliverables</strong></p><p><br></p><ul><li>Abstract formal models describing expected behavior of the relevant RIB/FIB operations.</li><li>Testing infrastructure that supports parametrized testing of individual modules and execution sequences across modules.</li><li>A test generation framework and the resulting high-coverage benchmark to validate the correctness of the RIB/FIB implementation.</li><li>*<strong>Program Term: Summer / Fall Term (May - November) 20 hours of work each week*</strong></li></ul><p><br></p><p><br></p><p><strong>Recommended Qualifications</strong></p><p><br></p><ul><li>Familiarity with Python and C/C++</li><li>Basic understanding of network forwarding and routing</li><li>Comfort with hands-on systems work under technical guidance, including system setups, trouble shooting, etc.</li><li>Strong communication skills</li></ul>

<p>The Kuadrant Console Plugin provides a web interface for managing API gateway policies in OpenShift, but currently relies heavily on YAML editing for most policy types. While DNSPolicy and TLSPolicy already have user-friendly form-based interfaces with dual Form/YAML views, validation, and guided workflows, the remaining core policies (RateLimitPolicy, TokenRateLimitPolicy, AuthPolicy, Plan, and OIDC) still require users to manually write YAML. This creates a steep learning curve and error-prone configuration experience. This project aims to bring RateLimitPolicy, TokenRateLimitPolicy, AuthPolicy, Plan, and OIDC policies to feature parity with the existing DNS and TLS form implementations. Form designs will be provided by the Kuadrant team. The mentee will implement these designs as PatternFly-based form interfaces following the established patterns from the DNS and TLS policy forms. These forms will allow users to configure policies through validated form fields while maintaining the flexibility to switch to YAML view for advanced use cases. The forms must support both creation and editing of policies, include proper field validation, handle complex nested structures (such as rate limit configurations and authentication rules), and synchronize seamlessly between form and YAML representations using the same patterns already proven in the DNS and TLS implementations.</p><p><br></p><p>Expected Outcome:</p><p>&nbsp;- Form-based creation and editing interfaces for RateLimitPolicy, TokenRateLimitPolicy, AuthPolicy, Plan, and OIDC policies implemented using the same patterns, components, and structure as the existing DNSPolicy and TLSPolicy forms</p><p>&nbsp;- Dual view toggle (Form View / YAML View) with bidirectional synchronization using js-yaml for all five policy types</p><p>&nbsp;- Field validation following the established validation pattern covering required fields, numeric constraints, conditional dependencies, and Kubernetes resource naming conventions</p><p>&nbsp;- PatternFly component integration matching existing forms: expandable sections for complex nested configurations, validated text inputs, dropdowns for enum fields, and reuse of gateway selection components</p><p>&nbsp;- Policy-specific form fields for: rate limit units and counters (RateLimitPolicy), token-based rate limiting (TokenRateLimitPolicy), authentication strategies and credentials (AuthPolicy), plan tiers and quotas (Plan), and OIDC provider configurations (OIDC)</p><p>&nbsp;- Error handling using the existing error modal and inline validation message patterns</p><p>&nbsp;- Internationalization support for all form labels and validation messages using i18next following the existing localization structure</p><p>&nbsp;- Both create (`/~new`) and edit (`/:name/edit`) routes for each policy type matching the DNS/TLS routing pattern</p><p>&nbsp;- Unit and component tests covering form validation, YAML synchronization, and error states following the established testing patterns</p><p><br></p>