Explore Projects

This project aims to significantly enhance libssh capability to handle OpenSSH certificates. Currently, libssh only supports certificates as opaque blobs for basic interoperability with some compatible OpenSSH servers. This implies that there is no control over the certificate attributes, thus preventing both user and host authentication by means of certificates. This project entails the development of a parsing mechanism for extracting certificate contents, along with a proper system to manage them. The deliverables are a set of new APIs for handling certificate-based user and host authentication, combined with an entire key revocation control infrastructure.

<ul> <li><strong>Add support of Kotlin/Native in processing-android</strong>.</li> <li><strong>Migration of Java based processing's android mode to Kotlin</strong>.</li> <li>Spilt Android specific logic from the plain java code.</li> <li>Restructuring the android mode to Multiplatform library using Kotlin/Native.</li> <li>Implementing on at least one platform (<strong>primarily JVM</strong>).</li> <li>Migrating Groovy based Gradle System to Kotlin Script (kts) based Gradle System.</li> </ul>

<p>JGraphT currently lacks proper support for trees (i.e. simple, undirected, connected, acyclic graphs). Sure, all algorithms that work on undirected graphs will work on trees but in some cases, there may be a much more efficient option. Also, there are some classic tree-algorithms that are currently missing from the library. I plan to work on the following:</p> <ul> <li>tree traversals</li> <li>algorithms for computing lowest common ancestors in trees and DAGs</li> <li>tree decompositions</li> <li>AHU algorithm for deciding tree isomorphism</li> <li>Prüfer encoding</li> </ul>

<p>This project serves as a modification to the Project “Porting MAVROS for ROS2” and instead aims to provide Ardupilot with native support for ROS2 with basic publish-subscribe features.</p> <p>The protocol that would be followed to implement the native features would be the XRCE-DDS protocol (DDS for resource-constrained environments). This project would involve the building of an XRCE-DDS client along with necessary IDL files for publishing time-critical vehicle messages across to either an :</p> <ul> <li>XRCE-Agent (for native DDS models)</li> <li>Micro-ROS Agent (for ROS2 nodes) with basic publish-subscribe functionality</li> </ul>

<p>Fractal currently supports only one account, if you want to be connected at the same time with different accounts the user has to launch several instances. I would implement multi account support in the client so users can have more than one account connected at the same time with a user friendly interface. I would need to work with GNOME's design team to come up with the interface. To add multi account support first there is some work on the backend to do, then we can work on the interface. I will take the fractal-next branch as the basis for this work.</p>

Description: To integrate KubeArmor with OpenTelemetry, an adapter needs to be created. OpenTelemetry is a standard for telemetry data, including distributed tracing, metrics, and logs, and has an SDK and a collector component that can run on Kubernetes. Applications can directly expose OpenTelemetry data through in-app instrumentation using the OpenTelemetry SDK. The collector can then gather data from multiple applications in a cluster and send it to various backends for storage and visualization, such as Jaeger. Expected Outcome: The mentee's task is to develop an OpenTelemetry adapter for KubeArmor that can receive logs, alerts, and telemetry from the kubearmor-relay-service and convert it into the OpenTelemetry format. They are also expected to create documentation and usage guides that describe how to set up and use the adapter, as well as demonstrate the integration with a backend that supports OpenTelemetry.

My GSoC 2025 proposal focuses on enhancing the "Transformed Cubic Grids" framework (Issue #264) within the QC-Devs organization by implementing adaptive quadrature methods. Current Becke-style molecular grids suffer from overlapping atomic grids, leading to redundant computations and reduced accuracy in quantum chemistry simulations. Building on prior work (Issues #7, #15, #96), I will develop algorithms to dynamically adjust grid points and weights based on integrand behavior, such as electron density, ensuring high accuracy with fewer points. My deliverables include refreshing and merging Pull Request #136, implementing adaptive methods (e.g., trapezoidal or Simpson’s rule with refinement), writing comprehensive tests and documentation, and creating Jupyter notebook tutorials for practical use in molecular property calculations.

<p>Talawa App already has the English language at the moment. As the app is being targeted to a broad audience so we need to support more language for great user experience and engagement. While the current language will be reused, we will be changing its hardcoded nature in the widgets (like app bar, buttons, form fields etc) to a more dynamic one. Users will be allowed to easily switch the language of their choice during Signup or Login. Users will also have the capability to change the language inside the app. Talawa app aims to build a strong and meaningful relationship among the members of the organizations with the help of features like group chats, news feed and events. Therefore making sure of effective communication between people of different language is also necessary. Modification in the backend will be done accordingly to help different language users to communicate effectively in groups. This project idea serves to solve the barrier of communication which can hinder the growth of the community through the Talawa app.</p>

The zlib is required for compiling and running many existing C / C++ / Rust apps in Wasm. Most noticeably, it is [needed in the Python port to Wasm](https://github.com/python/cpython/issues/93819). The VMWare Wasm Labs team is using a zlib port from [Singlestore](https://github.com/singlestore-labs/python-wasi) in [their Python Wasm runtime](https://wasmlabs.dev/articles/python-wasm32-wasi/). In WasmEdge, we could support the zlib host functions through our [plugin system](https://wasmedge.org/book/en/plugin.html). This way, any existing zlib apps can be compiled to Wasm and runs inside WasmEdge. - Expected outcome: Create a new [WasmEdge plugin](https://wasmedge.org/book/en/plugin.html) that exports all public functions in `zlib`. Implement SDK (in C/Rust) that uses the C ABI to generate corresponding headers for the above plugin. Generate the unit tests and pass the unit tests. >80% of code coverage for verification.

Currently InVesalius does not support simultaneous visualization of structural MRI and fMRI volumes. This is however of large interest to visualize both modalities for people involved in the clinical and analytical domain. Indeed a direct implication would be to have functional connectivity induced graphs visible along with structural connections (white matter). On top of which, after generating 3d maps, it may then be possible to visualize in space the functional connections versus structural connections. First of all, this project would be a useful feature to InVesalius, but secondly also to the neuroscience community. By having InVesalius open source and in a UI format it would enable clinical experts or neuroscientists without engineering background to have ready to go visualization of fMRI and structural MRI volumes. In general this could be extended to other modalities as well. Two possible ways to simultaneously visualize structural MRI and fMRI are: 1. Overlay different masks or contrasts (need to be carefully picked) for each of the two modality. There might be a need to apply some color distribution matching between structural and functional (e.g histogram equalization) since one would be T1 and the other T2 to have better visualization. Both slices would need to be co-registered prior to overlaying. The effect on the generation of 3D visualization would also be cared for. 2. Having two views or preview of fMRI in each orientation (sagittal, coronal, axial and 3d). Two views or one main view and a preview would require to have a tracker (dot) that points to the same voxels in the two views. This could be a way for the user to match regions for instance and essentially avoid crowding the visualization. The language I plan on using and believe fits the project would be python. The potential libraries used during the project would include already required ones for InVesalius (e.g scipy,opencv)

This project is a continuation of the project : ROS-2 Native Support for Ardupilot, which I worked on while receiving mentorship from Ardupilot in 2021. It intends to provide a number of technical improvements to the ROS-2 support capabilities currently available in the Ardupilot codebase.The major improvements planned for the project are 1) Implementation of Data Writer functions for ROS-2 messages 2) Creating a ROS-2 package that verifies if the DDS capabilities in Ardupilot are functioning properly or not 3) Development support for Gazebo Simulation with ROS-2 4) General Improvements for Ardupilot’s DDS Client to make it more user-friendly

pwndbg currently has support for debugging the jemalloc and glibc allocators. There are many programs out there that use different allocators, so extending support is important. I will implement support for musl's allocator: mallocng. This will require gaining a precise understanding of the used data-structures and algorithms. It will involve carefully reading the source (https://git.musl-libc.org/cgit/musl/tree/src/malloc/mallocng). In the end pwndbg will have additional commands for visualizing the data-structures used by mallocng, analogous to the heap, bins, arena, mp, vis etc. commands used for glibc malloc.

<p>This Google Summer of Code proposal describes a project to create custom Jupyter kernels for the Eclipse Advanced Scripting Environment's (EASE) script interpreters. These kernels can be used to execute code from an existing Jupyter instance and give feedback from the EASE script engine. A typical example for such code feedback would be an image of a calculated graph. A generic framework to easily publish this data from script code or EASE modules needs to be provided. The focus of this project is on implementing the kernels and not on creating custom Eclipse views for Jupyter clients. Since custom views might be desired in the future this project should take this into consideration.</p>

This project aims to add Arm Arm Confidential Computing Architecture (CCA) support to the Unikraft ecosystem, which is a step of “Unikraft as the Secure Configurable Unikernel”. Arm CCA is introduced in Arm v9 and it introduces new hardware features to make OS run as a confidential VM without trusting the underlying hypervisor. To achieve this goal, this project needs to finish the following tasks: 1) making CCA an option for Unikraft and adding support for necessary RSI commands; 2) preparing the FVP environment; 3) Adding support for more advanced features like attestation and memory encryption; 4) testing the project using several applications.

<p>FHIR (or Fast Healthcare Interoperability Resources) is a standard for exchanging electronic health records. It describes elements (called resources) and an API (or application programming interface) for implementation of the same. FHIR Narratives are human-readable representations of resources.</p> <p><strong>The project aims at adding support for FHIR Narratives to the FHIR2 Module of OpenMRS.</strong> Following are the overall objectives of the project:</p> <ul> <li>Create FHIR narratives for all resources defined by OpenMRS FHIR module.</li> <li>Develop a framework to support implementation-driven overrides for FHIR narratives.</li> <li>Add support for localization of the generated narratives.</li> </ul>

<p>This project aims to add support for arrays and allocatables in LFortran. Specifically, features to be added for arrays are as follows,</p> <ul> <li>Declaring Arrays</li> <li>Operations on Arrays</li> <li>Indexing Arrays</li> <li>Passing Arrays as Functions/Subroutines Arguments</li> <li>Array Initializer Expressions</li> <li>Slicing Arrays</li> <li>Intrinsic Functions for Arrays</li> </ul> <p>For supporting allocatables, the main focus would be on generating instructions to allocate memory in heap using <code>malloc</code>. There are some miscellaneous goals as well, such as improving support for pointers and kinds and some bug fixes discovered along the way.</p>

<p>Currently, the IKE and IPsec use UDP encapsulation whenever faced with NAT gateways which do not allow ESP or IKE packets. But some NAT rules even drop the UDP packets, only allowing TCP streams to go through. TCP encapsulation can reach through to hosts behind such NATs. An initiator must always try to send IKE_SA_INIT over UDP first, and if there are a certain number of transmission fails then only it should fall back to TCP. Another thing to do would be to schedule checks for UDP so we can go to establishing the tunnel using UDP if it becomes available and tear down the TCP IPsec tunnel. The above two steps are to be done as TCP encapsulation adds overheads and has performance trade offs compared to UDP, therefore we should always prefer using UDP unless required otherwise. Once the TCP support is added, we need to look into enabling ESPinTCP support in the kernel. The kernel must be able to identify TCP packets where the first 4 bytes are zero and we must tell the kernel to process ESPinTCP packets. Everything else will be done by following the draft RFC draft-ietf-ipsecme-tcp-encaps-09.</p>

<p>Matrix is an open, decentralized protocol for instant messaging (and more!) It has bridges to many other networks and protocol, e.g. IRC, Slack, and more. Initial support for Matrix was added in bug 1199855, but there's a lot to do still : Support more features from the Matrix SDK (video/audio calls, room topics, typing notifications, read receipts and a lot more.) Support one-on-one conversations. Add tests specific to Matrix. Improve the Matrix JS-SDK that Instantbird and Thunderbird depend on. Improving and expanding shared code and APIs used by all JavaScript protocol plugins (IRC, XMPP, Yahoo and Twitter). Improving documentation of the process for adding a protocol to Instantbird/Thunderbird. Using the Matrix protocol on a day-to-day basis to dog-food the code.</p>

<p>Quarkus is a Kubernetes Native Java framework tailored for GraalVM and HotSpot, crafted from best-of-breed Java libraries and standards,which currently is fully supported by Maven build tool which in simple words is used for building and managing any Java-based projects. Gradle is another open source build system which presently isn't supporting all the extensions and core of Quarkus i.e it is in preview mode. To make Gradle support Quarkus completely, we need to have a fairly good understanding of Java and Gradle build tool system. Then studying and comparing the existing Quarkus Maven plugin source code and Quarkus Gradle plugin source code we realize where Quarkus lags behind in the case of Gradle. The points where Quarkus lags can be enhanced by comparing and replicating all the integration tests of Maven plugin for Gradle plugin to increase the overall test coverage for Gradle.</p>

This project proposes the development of faust2clap, a tool that integrates the Faust programming language with the CLAP (CLever Audio Plugin) standard. Faust is a high-level functional language for real-time DSP, while CLAP is a modern open-source plugin format gaining traction as an alternative to VST and AudioUnit. Currently, Faust does not officially support CLAP as a target architecture. The goal is to extend the existing faust2xx framework by implementing a CLAP architecture file and a new command-line utility, faust2clap. This will allow developers to compile Faust DSP code into fully functional CLAP plugins, supporting advanced features such as per-note modulation and sample-accurate automation. Deliverables include the tool itself, a reusable architecture backend, a suite of test plugins, and comprehensive documentation. The project has been developed in close collaboration with the Faust team and aims to be merged upstream as an official component of the Faust toolchain. By bridging Faust and CLAP, this project supports open plugin standards, expands deployment options for DSP developers, and modernises the Faust ecosystem.

<h5>End-to-End Testing Support</h5> <p>Oppia Android's current testing corpus includes unit tests using the Robolectric testing framework &amp; integration tests using the Espresso testing framework (to ensure that the app operates as expected in a real Android environment). The current tests have a few limitations: they do not correctly facilitate cross-activity navigation flows which actual users will be triggering, and they do not verify that the app can interact with Oppia's backend correctly.</p> <p>To prepare for the global launch of the app, we need end-to-end tests that:</p> <ul> <li>Verify that the app works as a user would expect by playing through select critical user journeys</li> <li>Verify that the app operates as expected when interacting with a local developer instance of the Oppia backend server</li> </ul> <p>We expect that the tests will be written using UiAutomator &amp; are set up for interacting with a local development server (see <a href="https://developer.android.com/studio/run/emulator-networking.html" target="_blank">relevant documentation</a>).</p> <p>Note that this project requires running Linux with virtualization support (in order to run an Android emulator). You will need to make sure your computer supports <a href="https://help.ubuntu.com/community/KVM/Installation" target="_blank">KVM</a> and is running Linux.</p>

xeus-clang-REPL is a C++ kernel for Jupyter notebooks using clang-REPL as its C++ Interpreter. Cppyy is an automatic, run-time, Python-C++ bindings generator, for calling C++ from Python and Python from C++. Allowing C++ and Python to talk between themselves in a Jupyter notebook will allow users to switch between Python and C++ at will. This means that data analysts can set up their analysis in Python while running the actual analysis in C++. Thus reducing the time to write and debug their analysis pipeline. Initial support of cross talk between the two kernels has been implemented but this only supports passing primitive data types. This project aims to use Cppyy to extend this to support classes and functions.

Beam's Python SDK is increasingly the first choice for ML and data-intensive pipelines, making robust native streaming APIs more important than ever. However, two essential streaming primitives, UnboundedSource (Issue #19137) and Watch (Issue #21521), remain unavailable in Python despite being long established in the Java SDK. Today, Python developers who need these capabilities either pull in cross-language transforms that add Java dependencies and gRPC overhead, or wrestle with low-level RestrictionTracker internals. This project solves the problem by porting both primitives natively to Python on top of Beam's existing SDF framework. The UnboundedSource wrapper adapts the legacy reader API into a Splittable DoFn that handles checkpointing, watermark progression, deduplication, and splitting. The Watch transform adds periodic polling with composable termination conditions and stable dedup behavior. Porting both primitives natively abstracts away that complexity behind clean and Pythonic interfaces. It also unlocks native enhancements, such as updating fileio.MatchContinuously, without leaving the Python ecosystem. The planned deliverables are: (D1) a Python UnboundedSource API with its SDF-based wrapper, (D2) a native Watch transform with PollFn and TerminationConditions, (D3) a test suite spanning DirectRunner and Dataflow, and (D4) supporting documentation including docstrings, programming-guide updates, and migration notes.