Explore Projects

<p>The Apache open-source-project <a href="https://brooklyn.apache.org/" target="_blank">Brooklyn</a> is a multi- cloud application management platform. Brooklyn can manage the provisioning and deployment of cloud applications, can monitor applications’ health and metrics, and handle the dependencies between components. It enables cross-computing features through a unified API built over <a href="https://jclouds.apache.org/" target="_blank">jClouds</a> to manage IaaS services offered by various providers. The tool offers a REST API and a GUI that enables a single-click deployment of applications across multiple machines, locations and clouds.</p> <p>As it was aforementioned, Brooklyn provides an API for the management of IaaS cloud services and ssh resources for a great number of providers and establishes a lifecycle for the management of services and applications. This project propose to extend this API with facilities for the management of PaaS offerings such as <a href="https://cloud.google.com/appengine/docs" target="_blank">Google App Engine</a>, <a href="http://aws.amazon.com/" target="_blank">AWS services</a>, <a href="https://www.heroku.com/" target="_blank">Heroku</a>, <a href="https://www.cloudfoundry.org/" target="_blank">CloudFoundry</a> (such as <a href="https://run.pivotal.io/" target="_blank">Pivotal</a> or <a href="https://console.ng.bluemix.net/" target="_blank">Bluemix</a>) , <a href="https://www.openshift.com/" target="_blank">Openshift</a>, etc., providing an homogeneous access to IaaS and PaaS services. Moreover, it opens up some interesting proposal such as adding new technologies support, e.g., Python, PHP and adding new management policies in order to take advantage of PaaS features.</p>

<p>The ScummVM project currently does not support the original MacVenture games developed for the Macintosh 128k. However, there is already a modern implementation of these games that supports the original game files, the WebVenture engine.</p> <p>Most of the reverse engineering work for the MacVenture games is <a href="http://seancode.com/webventure/formats.html" target="_blank">already done</a> in the WebVenture engine, but since it is written in JavaScript, a direct port is necessary for it's integration with ScummVM. In addition, the WebVenture engine already supports the Apple II versions of the games, making it possible for them to be added to the same engine in the respective ScummVM implementation.</p> <p>Therefore, the goals of this project are:</p> <ul> <li>To write an engine in C++ to support these games, with a base in the existing JavaScript implementation.</li> <li>To integrate the engine with the existing ScummVM framework, so that it can support MacVenture games in the many platforms that ScummVM supports.</li> </ul> <p>Most of the MacVenture games were pioneers in their respective genres, so the ScummVM community would benefit greatly from having access to these games as classics of their genres, for academic and nostalgic value.</p>

This proposal sets out to implement several kinds of Quantum Vision Transformers (QViT) for High Energy Physics (HEP) analysis at the Large Hadron Collider (LHC), inspired by the seminal work of Cherrat et al., which introduces three innovative quantum transformer architectures: Orthogonal Patch-wise Neural Network, Quantum Orthogonal Transformer, and Quantum Compound Transformer. Despite the groundbreaking nature of their research, the absence of released source code has left a significant gap in practical application and reproducibility. Furthermore, attempts by last year's contributors, Marçal Comajoan Cara and Eyup B. Unlu, to implement the Quantum Orthogonal Transformer faced challenges; Marçal encountered training issues due to NaN values, and Eyup's implementation did not proceed to the training phase of transformers, highlighting the difficulties in realizing these models. This project aims to address these gaps by developing QViT models within the TensorFlow Quantum framework, leveraging this technology to bridge theoretical insights with practical application, thereby marking a potential first in applying these models for the analysis of particle jet images in HEP.

<p>XaoS currently cannot support very deep zooms because the 80-bit floating-point arithmetic used runs out of precision before too long. It should be possible to add arbitrary precision to XaoS using the MPFR library ( <a href="https://www.mpfr.org/" target="_blank">https://www.mpfr.org/</a>), or a different one if it is not fast enough to support real-time zooming. The second part of the project focuses on rendering very large size images to support high-quality output. Support for various colour profiles, batch output, cropping, and the cartesian grid will be added along with this. Additional improvements to XaoSjs and support for web compilation of XaoS will also be carried out.</p>

<p><span style="color: rgb(65, 65, 65);">The Linux kernel is the largest open source project with millions of lines of code and 10,000+ developers across the globe. It is a challenge to understand how the community works, how to get started in learning the code base, and take steps to become a contributor. This project will help developers new to kernel development navigate the large code base, diverse community, and guide them in choosing the areas of the kernel to focus on to enhance, fix bugs, and develop solutions working with the experts in the community. After the end of the project, the applicant will have a much deeper knowledge of many different areas of the Linux kernel and get their patches accepted into the kernel.</span></p>

GnuCOBOL currently has no support for the Object-Oriented Programming (OOP) features defined by the ISO standards ISO/IEC 1989:2002 through ISO/IEC 1989:2023. Object-Oriented (OO) code currently leads to syntax errors due to lack of parsing support. The project aims to build support for parsing all OO syntax, and for a subset, also implement AST and codegen support to get a minimal working prototype of calling class methods through objects. Support for complex OOP features like method overriding and single inheritance will also be implemented. Multiple inheritance, method prototypes and parameterised classes are excluded for now. As a result, future releases of GnuCOBOL 3 will be able to parse OO code and report a simple error message about the pending feature. GnuCOBOL 4 will introduce the new paradigm to users. It will be able to generate working binaries for OO code and handle complex features like method overriding and single inheritance. The project will help bring GnuCOBOL closer to being compliant with ISO standards for OO COBOL and establish it as a significant choice among institutions looking for a free COBOL compiler with OOP support.

<p>The VCF (Variant Call Format) is a format for text files, which is generally stored in a compressed manner to make the data retrieval of variants fast. The data which is redundant is not stored, only the variations are stored. VCF files are used to store all variant types which includes single nucleotide polymorphism (SNP) in a specific position of the genome, short insertions and deletions (INDEL) and structural variants (SV). VCF-validator includes various checks to ensure that the VCF file is consistent. It is based on a formal grammar and performs lexical, syntactic, and semantic analysis of the VCF file. It also includes a tool called VCF-debugulator which fixes errors such as the presence of duplicate variants automatically. SNPs and INDELs are fully supported in VCF-validator, but the support for SVs is still limited. The aim of this project is to improve the support for structural variants in the validator and the debugulator.</p>

Kmesh, as a high-performance service mesh data plane, is now only supported for use in a single cluster. However, now that multi-cluster support for istiod has been realized, we are able to move forward with the multi-cluster adaptation of Kmesh to support the use of Kmesh in multi-cluster environments. Adaptation to the current multi-cluster production environment with LLM and large data. - Expected Outcome: - 1.Code for implementing the Kmesh multi-cluster feature - 1.1. Adapting to the Istio Multi-Cluster Function API - 1.2. Traffic Management in multi-cluster scenarios - 1.3. Use IPsec to ensure the security of node communication. - 2.userguide doc - 2.1. proposal - 2.2. userguide - 3.e2e test - 3.1. Unit Test of Feature Function - 3.2. E2E test code

<p>This proposal aims to add call hierarchy support in Haskell Language Server(HLS).</p> <p>Language Server Protocol(LSP) has <a href="https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_prepareCallHierarchy" target="_blank">supported</a> call hierarchy in 3.16, which make us implement it in HLS possible.</p> <p>Inspired by <a href="https://github.com/haskell/haskell-language-server/issues/738" target="_blank">this issue</a>, my proposal involves the following steps this summer to contribute to call hierarchy:</p> <ol> <li><a href="https://github.com/haskell/lsp" target="_blank">LSP</a> spec support.</li> <li><code>prepareCallhierarchy</code> implementation.</li> <li><code>incomingCalls</code> implementation.</li> <li><code>outgoingCalls</code> implementation.</li> <li>Test</li> </ol> <p>I hope I can contribute to HLS to go further this summer.</p>

<p>Godot has support for video playback through VideoPlayer API, which while useful, is constrained to using one of the two supported formats (Theora or Webm) This project aims at using GDNative to add external library support to Godot for supporting multiple codecs without causing bloat and unnecessary size increase. This will be done by releasing a set of official external modules that the user can add to the project as per their requirement.</p>

<p>Currently no open source SOCKS proxy available for recent kernel versions. In fact router proxification depends on user-space proxy applications. This makes the operation much slower because of the intensive packet copy between kernel space and user-space. With this kernel module low-cost embedded devices can do the proxy function entirely in kernel space which makes the whole operation much faster, avoiding copies.</p>

The Mission Support System (MSS) client currently lacks the ability to save and restore view configurations, requiring users to manually recreate complex window layouts each time they reopen the application. Additionally, collaborative operations do not support sharing view configurations among participants, hindering real-time coordination. To enhance the user experience and collaboration in the Mission Support System (MSS), this project will introduce two major improvements. First, it will implement a local and server-side view restoration system, allowing users to save and reload their window layouts automatically. This will be achieved through JSON-based storage for local configurations and database integration for server-side persistence. Users will have the option to enable or disable view restoration via a new setting, ensuring flexibility. Second, the project will introduce a collaborative view-sharing feature through a dedicated "Manage View" widget. This will enable participants in an operation to share, browse, and load predefined layouts, ensuring consistency during joint missions. The widget will integrate with MSS’s existing operation system, allowing real-time updates via WebSocket notifications. Backend APIs will handle secure storage and retrieval of shared views, while the frontend will provide an intuitive interface for managing layouts. Together, these enhancements will eliminate the need for manual reconfiguration and streamline teamwork in mission planning and analysis.

ARM64 is becoming increasingly common with the rise of Apple Silicon and cloud instances like AWS Graviton, but Kubeflow still doesn’t run consistently on ARM-based systems. Right now, different components behave differently — some work partially, some require manual fixes, and others don’t work at all. This makes it difficult to use Kubeflow reliably outside of traditional x86 environments . The goal of this project is to make ARM64 a properly supported architecture across the Kubeflow ecosystem. Instead of partial or experimental support, the idea is to make sure Kubeflow works the same way on ARM as it does on AMD64. To achieve this, I plan to start by auditing the container images used in Kubeflow and identifying gaps in ARM64 support. Based on that, I will enable multi-architecture builds using Docker Buildx and integrate them into existing CI/CD pipelines so that ARM64 images are built and published automatically. I will also update manifests to remove architecture-specific references and ensure they work across both architectures without requiring changes. A major part of the work will be validation. I will deploy Kubeflow on ARM-based environments (OCI Ampere) and run end-to-end tests to catch issues that only appear at runtime. Any failures related to dependencies, builds, or configuration will be debugged and fixed incrementally. By the end of the project, Kubeflow should be able to run end-to-end on ARM systems without manual workarounds. The final output will include working multi-architecture builds, improved CI/CD pipelines, updated manifests, and a clear “golden setup” guide for running Kubeflow on ARM. Overall, this project is about making Kubeflow more consistent and usable across modern infrastructure, especially as ARM adoption continues to grow.

This project aims to add UEFI support to Rust to allow building applications and modules for edk2 and UEFI in general. This will entail achieving the following things: 1. Get most of Rust-std running under the UEFI target 2. Add testing support for UEFI target. 3. Possibly add support for ARM and RISCV UEFI targets (currently only X86_64, AARCH64, and I386 are present) By the end of this project, using Rust for UEFI target should be a smooth experience similar to normal std supported targets.

Shardingsphere federated query engine provides support for SQL statements. In the GSoc period, I have to add support for more MySQL SELECT statements so that more SQL statements can be converted into SQLNode. This can be achieved by: 1- Analysing the SQL statement I have to add support of, 2-Figure out components & logic required , 3- Make changes in SQL federation engine optimizer files , 4- Optimize parser files , 5- Make changes in TEST files to ensure test is passing successfully. After the support for More SELECT statements queries is added, The users & developers will be benefitted by utilising more SELECT queries for MySQL .

This project addresses the lack of execution tests for the BPF backend in GCC. While GCC has many compile-time tests, the BPF backend, which generates eBPF code run by the Linux kernel, lacks runtime validation. The goal is to create a test tool that runs eBPF programs on a live kernel in a virtual environment (using QEMU), similar to the kernel's selftest infrastructure. The tool will load and execute BPF objects and report results, allowing us to catch regressions early. Next, this tool will be integrated into GCC's Dejagnu-based testing infrastructure, and a dedicated testsuite for the BPF target will be added to the GCC testsuite. This project will help ensure that compiler changes do not inadvertently generate eBPF code that the kernel verifier rejects.

This projects aims to complete the support for Constant Folding in GCC Rust frontend. It will do so by finishing the already started constant folding port from GCC C++ frontend. It will help gccrs to: - Evaluate const functions. - Specify static array size using const expressions. - Check for overflows. - Support const generics in Rust >= 1.50.0. The current port in gccrs has the following issues which will be fixed as milestones for this project: - Evaluation of non-const expressions inside const expression is not handled properly. - Argument binding for const functions is not supported. - Arithmetic Overflows are not detected. - Constant functions with complex bodies containing conditions and loops are not handled properly. Fixing these issues above will complete the support for constant folding and help the areas which need it in gccrs.

<h3>Description</h3><p>This mentorship project combines both hands-on development and exploratory research.</p><p>CBOMkit currently supports cryptographic detection and analysis for Java, Python, and Go ecosystems. However, a significant portion of production systems relies on other programming languages like C/C++ (used especially in systems programming, embedded environments, and high-performance applications) and widely rely on crypto libraries like OpenSSL.</p><p><br></p><p>On the development side, the mentee will extend CBOMkit to support C/C++, with a primary focus on detecting usage of OpenSSL APIs, and cryptographic primitives. This includes adding C/C++ language support, designing detection logic in sonar-cryptography, integrating it into CBOMkit’s architecture, developing test cases and validating against real-world C/C++ projects, ensuring practical applicability and robustness.</p><p><br></p><p>Additionally, mentee will also test some other policies through existing Open Policy Agent (OPA) integration feature of CBOMkit.</p><p><br></p><p>On the research side, the mentee will analyze additional cryptographic libraries in the C/C++ ecosystem such as wolfSSL, libsodium, BoringSSL, and Botan, along with exploring language support for Rust and its associated cryptographic libraries. The goal is to evaluate their feasibility for future integration into CBOMkit.</p><h3><br></h3><h3>Learning Objectives</h3><ul><li>Understand analysis techniques for detecting cryptographic usage</li><li>Gain hands-on experience with cryptographic libraries such as OpenSSL in C/C++</li><li>Learn how to extend and contribute to a production-grade open-source security tool</li><li>Develop skills in designing test cases and validating tools on real-world codebases</li><li>Learn how policy-based security analysis works using Open Policy Agent (OPA)</li><li>Conduct technical research and evaluate cryptographic libraries and programming language for integration</li></ul><h3><br></h3><h3>Expected Outcome and Deliverables</h3><ul><li>C/C++ language support integrated into sonar-cryptography</li><li>OpenSSL detection module with meaningful coverage</li><li>integration with CBOMkit</li><li>Test suite for validating detection accuracy</li><li>Validation report using real-world C/C++ projects</li><li>Research document comparing additional libraries (wolfSSL, libsodium, BoringSSL, Botan) and language(Rust with its library) for integration feasibility</li><li>Blog post(s) or technical documentation describing implementation and findings</li><li>Evaluation with other policy through OPA</li></ul><h3><br></h3><h3>Recommended Skills</h3><ul><li>Proficiency in java with good understanding of C/C++</li><li>Experience with OpenSSL and general cryptographic APIs</li><li>Good understanding of cryptographic concepts (encryption, hashing, key exchange)</li><li>Experience with static analysis or code parsing (preferred but not mandatory)</li><li>Familiarity with Open Policy Agent</li><li>Familiarity with Git and open-source contribution workflows</li></ul><h3><br></h3><h3>Additional Information</h3><ul><li><a href="https://github.com/cbomkit/sonar-cryptography/blob/main/docs/LANGUAGE_SUPPORT.md" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">https://github.com/cbomkit/sonar-cryptography/blob/main/docs/LANGUAGE_SUPPORT.md</a></li><li><a href="https://github.com/cbomkit/sonar-cryptography/blob/main/docs/DETECTION_RULE_STRUCTURE.md" rel="noopener noreferrer" target="_blank" style="color: rgb(9, 105, 218);">https://github.com/cbomkit/sonar-cryptography/blob/main/docs/DETECTION_RULE_STRUCTURE.md</a></li></ul>

OWASP OWTF supports use of terraform to deploy OWTF on AWS and manifests for Kubernetes. To improve its capabilities, I will introduce support of Microsoft Azure and Improve current kubernetes manifest to support separate frontend and backend deployment of OWTF.

This project entails introducing support for measuring code coverage for all Kotlin files in the Android codebase with Bazel, with any support gaps documented.

<p>I would like to contribute by adding Greek support for Eczar, including polytonic, for all 5 weights.</p> <p>Eczar is designed by Vaibhav Singh, produced by David Březina, and published by Rosetta Type Foundry - [<a href="https://github.com/rosettatype/Eczar" target="_blank">https://github.com/rosettatype/Eczar</a>] [<a href="https://fonts.google.com/specimen/Eczar" target="_blank">https://fonts.google.com/specimen/Eczar</a>].</p> <p>As a typeface, Eczar has a strong personality, with five weights from Regular to Extra-Bold and can be used to set text from body copy to display. At the moment, only six Serif fonts that support Greek are available from Google Fonts and –in my opinion– do not provide this flexibility. Eczar already supports Latin and Devanagari. Devanagari are designed with an axis mirrored in relation to the Latin. This is a significant start regarding the addition of Greek glyphs, since one has a glimpse of the designer’s original aesthetics and design intentions; it also provides a good basis for certain letterforms that could be transferred into the Greek design, rendering a balanced outcome for all the supported scripts.</p>

JuliaImages takes support from JuliaIO to provide encode and decode methods of various image formats. The focus of this project is to add IO support for GIF and JPEG2000 formats. This project also aims to provide improved metadata EXIF support for the Julia community.

The project aims to enhance the metadata support in sunpy-soar, enabling better searching and filtering of solar data in the Solar Orbiter Archive (SOAR). Currently, sunpy-soar offers only basic metadata, such as SOOP name, time, and level. However, there is a wealth of additional data in SOAR that is not yet accessible through sunpy-soar. To address this, we propose adding support for various tables in SOAR, such as v_<ll/sc>data_item, v<ll/sc>repository_file, and v<instrument>_<ll/sc>_fits. These tables contain valuable metadata like filenames, filesize, sensors, and instrument-specific data. By implementing these tables, users will be able to access a broader range of metadata in sunpy-soar. Additionally, we plan to enable querying multiple tables simultaneously to retrieve more comprehensive metadata. This involves updating the sunpy-soar/client module to support constructing queries with metadata from different tables. We will also refine the sunpy-soar/attrs module to handle new metadata attributes efficiently. Overall, the deliverables encompass the entire process of updating and enhancing metadata support in sunpy-soar, from implementation to documentation, ensuring that users can effectively utilize the improved functionality for solar data exploration.