Explore Projects

The project aims to make the following changes to the talawa-api: Enforce a stricter, standard graphql-pattern to get rid of the current anti-pattern nature that exists in the API. Resolve the relations that exist within the application optimally. Caching data for MongoDB collection entities having significantly higher number of read operations than write operations using Redis in memory Cache. Monitoring changes in the API schemas and relaying the changes to the client apps using Graphql-Inspector for better versioning migrations. Implement Data Normalization on the Client side(admin-portal and talawa mobile app) cache-store using Apollo Client Normalization. Providing a standard, scalable Error Handling mechanism within the graphql API using unions and interfaces to allow a consistent relay of Errors to the Client apps which will allow them to have more control over customizing UI behavior in case of errors. Implement stricter and simpler RBAC in the API resolvers in line with the business logic. Implement SSL in the client-server layer to encrypt all data exchanged between the client apps and API. Encryption of PII data within the SSL layer and in the Database at rest for added security using AES algorithm to encrypt and decrypt PII fields.

<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>

This project aims to create a tool that automatically generates Python typing stubs for the Device Under Test (DUT) in cocotb-based hardware verification testbenches. By leveraging cocotb’s existing introspection capabilities, the tool will produce .pyi stub files describing the DUT’s interface – its hierarchy of modules and signals – in a statically typed fashion. These stubs will enable IDE features like auto-completion via VS Code’s Pylance and allow static type checkers such as mypy to catch errors in testbench code, significantly improving the hardware verification development experience​. The generated stubs will mirror the HDL design’s structure (with considerations for hierarchical vs. flat representations) and provide a structured abstraction of the DUT interface that can even be used for mocking or unit-testing components of the testbench. Initially, the stub generator will rely on runtime cocotb introspection only, but it will be designed with extensibility in mind, so that future enhancements (e.g., integrating a SystemVerilog language server like slang for richer type info) can be incorporated​. Over a 175-hour Google Summer of Code timeline, the project will deliver a working stub-generation utility, along with documentation, tests, and integration into the cocotb ecosystem, providing a concrete benefit to the open-source hardware verification community.

<p>Opportunistic IPsec is an attempt to encrypt the internet at large. The idea is to build VPN tunnels directly to all internet hosts irrespective of the communication used. An initial proof of concept was created that leverages LetsEncrypt certificates for use with IKE and IPsec. The goal of this project is to turn this proof of concept into production quality code that makes it trivial to enrol and deploy on any server and any client.</p> <p>The project has the following objectives:</p> <ul> <li>Automate Client, Server configuration and the enrollment and updating of LetsEncrypt certificates for use with libreswan.</li> <li>Implement a DNS/DNSSEC based method for advertising Opportunistic IPsec support using LetsEncrypt for servers.</li> <li>Design a non-DNS based method for publishing support of LetsEncrypt based Opportunistic IPsec for servers.</li> <li>Enhance libreswan to allow a secure fallback to the existing NULL Authentication method.</li> <li>Ensure the working of two behind the same NAT. Along with ensuring the working of two clients behind NAT, with one not using IPsec.</li> <li>Support the recovery from server OR client reboot/crashes. Along with ensuring no lockouts happen.</li> </ul>

The Shmdata library provides a layer to share streams of framed data between processes via shared memory. It supports any kind of data stream: it has been used with multichannel audio, video frames, 3D models, OSC messages, and various others types of data. Shmdata is server-less, but requires applications to link data streams using socket path (e.g. "/tmp/my-shmdata-stream"). Shmdata is very fast and allows processes to access data streams without the need for extra copies. However, permissions are not supported, and any stream shared on the system with Shmdata is accessible system-wide. The project will enable the possibility for a Shmdata user to configure streams permission using shared memory right setting at the API level. When sharing data between processes via shared memory, not all components of the data need to be visible to everyone. Different groups might need to access different data, furthermore, some data might only be needed to be visible to the owner of the files. In such cases, the permissions that would have to be implemented are combinations of 'read', 'write' and 'execute' permissions that would be given to the owner, group or common user(i.e. everyone else). Permissions would be 'none', 'execute only', 'write only', 'write and execute', 'read only', 'read and execute', 'read and write', 'read, write and execute' with corresponding values of 0-7 respectively. DELIVERABLES * Providing an option for users to restrict or openly share data streams via these file/ directory access modes: read, write and execute/traverse. * Changing data access permissions. * Documentation for the improvements made. * Incorporation of ACL to assist with Unix file permissions. (optional/if time allows).

<p>Soletta has its own implementation of the lightweight machine to machine (LWM2M) protocol. The LWM2M protocol is used to remotely control IoT devices, these include: Firmware updates, status reporting and etc. Although Soletta already implements the LMWM2M Server and the LWM2M Client, Soletta's implementation is lacking some main features, namely: an LWM2M Bootstrap Server, Message Encryption and Data Access Control.</p> <p>The idea is to:</p> <ul> <li>Add support to LWM2M Bootstrap Server on Soletta, as specified by OMA, enhancing IoT developers' choices on how to bootstrap their machine-to-machine devices.</li> <li>Add support to CoAP Message Encryption inside Soletta's implementation of LWM2M, giving IoT developers' an increase sense of security when using LWM2M through Soletta.</li> <li>Add support to Data Access Control, allowing a LWM2M Client to support one or more LWM2M Servers, by determining which server is authorized to perform which operation. The LWM2M specification specifies Access Control Objects to handle authorization, and they will be implemented from scratch.</li> <li>Deliverables include API Code, Internal Code Changes, Unit Tests, Doxygen Documentation and Sample Applications.</li> </ul>

<p>In a standard container setup, the container shares the network namespace with</p><p>its host environment, meaning localhost inside the container refers to the same</p><p>loopback interface as the host's network namespace. Many CNI plugins and</p><p>container networking services rely on this assumption. For instance, Docker</p><p>sets up an internal DNS server listening on localhost within each container's</p><p>network namespace and configures `/etc/resolv.conf` accordingly. Similarly,</p><p>service meshes (e.g., Istio, Linkerd) inject sidecar proxies that listen on</p><p>localhost, and certain CNI plugins expose health checks or metrics endpoints on</p><p>the loopback interface.</p><p><br></p><p>&nbsp;In urunc, however, workloads execute inside a sandboxed environment</p><p>with its own isolated network stack. As a result,</p><p>localhost inside the sandbox does not refer to the host's network namespace</p><p>loopback interface but to the sandbox's own. This breaks any service that</p><p>relies on localhost-based communication between the container and host-level</p><p>components.</p><p><br></p><p>This project aims to investigate and implement mechanisms to bridge localhost</p><p>communication between the host network namespace and the sandbox. The mentee</p><p>will survey the landscape of CNI plugins and networking services that rely on</p><p>localhost, categorize the different communication patterns, and design a</p><p>solution that restores compatibility while preserving the</p><p>isolation guarantees that urunc provides.</p><p><br></p><p>- Expected Outcome:</p><p>&nbsp;- A survey and categorization of CNI plugins and networking services that</p><p>&nbsp;&nbsp;rely on localhost communication, documenting the specific patterns and</p><p>&nbsp;&nbsp;assumptions each makes.</p><p>&nbsp;- A design proposal of one or more mechanisms to bridge localhost traffic</p><p>&nbsp;&nbsp;between the host network namespace and the sandbox.</p><p>&nbsp;- Implementation of the proposed solution in urunc, with DNS resolution as</p><p>&nbsp;&nbsp;the primary use case.</p><p>&nbsp;- Evaluation of the new mechanism.</p><p><br></p>

The GNOME organization has numerous websites to accommodate all its operations. Every website albeit serving different purposes falls under the GNOME umbrella. Consistency and homogeneity in the design of all present and future GNOME websites are imperative. The goal of this project is to develop and publish a unified CSS framework/library/toolkit incorporating the revised Human Interface and Visual Identity Guidelines that would allow developers to update existing GNOME websites or create new ones with a congruent visual identity. Evaluation, mockups, code-complete implementation, testing, and documentation of the individual elements such as labels, links, and images as well as composite components such as headers, footers and pagination will be performed. The project ensures creating a consistent framework with an exhaustive three-step workflow: 1. Inventory/Evaluation Phase: Variations in individual elements and composite components from each website are recorded to ensure all alternates are captured. 2. Iterative Design Phase: Mockups are created for each evaluated component considering all the possible variations encountered during evaluation. The mockups will be subsequently iterated upon after review and deliberation with the Design Team and other project stakeholders. 3. Implementation and Testing Phase: The final approved mockup will be implemented in TailwindCSS. The element/component will be documented and tested. Once the implementation is approved and all tests pass the element/component will be incorporated into the framework.

Customized SSH Authentication Free Implementation of the Cloud-COPASI for UConn users: The project proposal aims to create a customized version of Cloud-COPASI that already has a predefined HPC pool connection which will be used by all registered users of this version of Cloud-COPASI. It will also implement a quota system to prevent abuse of computing resources. This will be accomplished by using a predefined SSH connection to the facility. Instead of user holding the private key and moving the public key to the remote submit node, the server holds a database of all remote nodes and for each node it creates a separate public and private key pair. The public key will be copied to the remote node. The private key would be saved on the server. Whenever an authenticated user tries to connect to a particular submit node in the HPC facility, the private key for that node will be fetched by the server and will be used to authenticate the user against that remote node and there will be no need for the user to configure and enter any private key at all. Thus there will be just one private key for all users of a particular submit node. Server will also keep a tally of all the users that are currently using the server's private key at the moment. This will help implement a quota system to ensure that the resources are not maxed out. Over the span of 12 weeks, a customized version of cloud COPASI will be produced that will provide an easy to use interface for UConn users to submit their jobs and get results in quick time.

Verification in hardware design is a time-consuming and complex task as well as requires manual effort to update UVM testbench components (scoreboard, driver, sequencer) with constant changing DUT. This project proposes to solve this by using AI and NLP to extract key information from the provided DUT specs and updating the UVM components accordingly. This will reduce the manual effort of updating the components and optimize the process of verification. Project Deliverables are : An NLP-based parser for extracting DUT parameters Automated UVM component generation and adaptation Reinforcement learning for better verification environment

<p>The Component Development Kit as of now supports only Non UI components and lacks multiple language support. This proposal aims at upgrading the Component Development Kit to the next level. Enabling multiple language support as well as visible UI external components. Another ambitious feature this proposal offers to implement is support Background processes. Enabling more flexibility and widening the range of Apps made with App Inventor. Some minor tweaks largely requested by the user community has also been planned to be implemented during this summer. The Projects will be selected or done as per the priority of community.</p>

Current limitations: The current Back End for the Functional Annotation of Animal Genomes project (FAANG) provides users with a public rest API to access data. But it has a few limitations. First, in order to fetch data from different Elasticsearch indices or to fetch details of different documents, user has to make multiple API request calls. Second, users have to write CURL queries to work with the API which users may find complicated. Proposed solution: The main aim of creating a new backend for the Functional Annotation of Animal Genomes project (FAANG) is to make accessing and handling required data for users much easier than the current setup. In order to achieve this the following are the main tasks for the project: First, creating a Back End for Fetching Data (BE Read): To create a GraphQL Server which will make it easy to fetch the required data using advanced operations like join and aggregations by making a single API call to the Back End. Second, creating a Front End for Fetching Data (FE Read): To create a UI for selecting which data is to be fetched. Hence using a GraphQL Server, user only needs to make a single API call, and with a better UI, user wont have to worry about writing queries for fetching data. Deliverables : 1. Basic Fetching of documents (single and multiple documents of an elasticsearch index) 2. Implementing Dataloader in the GraphQL server for decreasing DB hits 3. Implementing Filter and Join functionality between elasticsearch indices for fetching data from the GraphQL server 4. Implementing Aggregation for data to be fetched from the GraphQL server 5. Implementing Frontend interfaces to make data fetching easier and reduce mistakes from the user's side

<p>The aim of this project is to decouple the current orga-server and move to API centric approach, with orga-server as the central API server &amp; open-event-frontend as the frontend.</p>

<p>The [Ecosystem Explorer](<a href="https://explorer.opentelemetry.io" rel="noopener noreferrer" target="_blank">https://explorer.opentelemetry.io</a>) helps users discover and get detailed documentation around various OpenTelemetry components. As the project expands to more ecosystems (Python, JavaScript, GenAI), information density will increase significantly, requiring patterns and approaches tailored to more than just the initial Java Agent use case. This mentorship involves conducting UX research to understand how users actually want to consume and use this information, covering: how users currently find information about components or instrumentation (LLMs, GitHub, docs, vendor sites, trial and error); what questions they are trying to answer (what telemetry will I get, how do I configure it, what changed between versions); what personas exist (app developers instrumenting code, platform engineers running collectors, SREs debugging production); how similar tools present dense technical information (npm registry, crates.io, Go pkg site, Docker Hub); and how LLMs are being used in this area and what the experience has been with them. The research will inform how we structure information, what features to prioritize, and how to present complex telemetry data in an accessible way.</p><p><br></p><p>Expected Outcome:</p><p><br></p><ul><li>User Interviews Report: Summarized findings from 3-5 user interviews covering different user types and key tasks</li><li>Competitive Analysis Report: Findings from reviewing 2-3 similar tools (e.g., package registries, API documentation sites) on how they present component information</li><li>Information Architecture Recommendations: Proposed structure for presenting a specific type of component data (e.g., "instrumentation" or "collector components")</li><li>Wireframes/mockups (stretch goal): Visual concepts for key user flows</li></ul>

<p>PowerShell is a widely used administration tool in Windows Server workloads. This project aims at porting it to FreeBSD in order to make it easier and faster for Windows Server professionals to start working on FreeBSD server workloads and to make available yet another shell choice which is friendly for new-coming Windows users. In order to achieve that, however, porting the .NET Core SDK toolchain, including CoreCLR, CoreFX and the CLI itself, is necessary once they are vital PowerShell dependencies. As a result, FreeBSD users should have access to PowerShell, an object-oriented shell to interact with the system, and .NET Core, which can be useful for developers to build and run their applications on FreeBSD personal and server machines.</p>

pgmoneta is a backup / restore solution for PostgreSQL, it supports doing backups, listing all backups for a server, restoring a backup from a server, archiving a backup from a server, deleting a backup as well as retaining a backup from a server at a local level. This project aims to abstract how backups are stored in various locations such as locally and on remote machines. By the end of GSoC 2022, I would like to complete the following work: 1- Implementing a local storage engine. 2- Implementing a SSH storage engine. 3- Implementing Amazon S3 storage engine. 4- Implementing Ceph storage engine. 5- Supporting other pgmoneta-cli commands as restore, archive, delete and retain for storage engines. Supporting Ceph storage engine depends on whether implementing S3 storage engine has been finished or not.

Jaeger is a distributed tracing platform. Jaeger V2 is a major new version where we rebase all Jaeger backend components (agent, collector, ingester, and query) on top of the OpenTelemetry Collector. (1) Currently jaeger-v2 components are initialized without observability clients. We need to instantiate appropriate logging, tracing, and metrics clients and pass them to the components. The existing code uses internal metrics API, which needs to be bridged to OTEL metrics to minimize code changes. (2) Jaeger-v1 components can report their readiness using an internal health check API that is connected to the healthcheck endpoint on the admin port. We need to implement similar capability in Jaeger-v2. Expected Outcome: Achieve parity in observability of jaeger-v2 compared to jaeger-v1

<p>XMPP RFCs and Specifications define connection establishment over TCP, BOSH and websockets. Smack currently establishes connection between Server and Client using TCP and BOSH. BOSH suffers from high transport overhead as compared to TCP. Also various issues with long polling are suggested to have an impact upon BOSH based systems [RFC 6202 Section 2.2]. WebSocket provides an alternative to the limitation of inefficient communication between the server and the client by providing bi-directional, full-duplex, real-time client/server communications. The protocol consists of an opening handshake followed by basic message framing, layered over TCP [RFC 6455]. Adding WebSocket support to Smack will allow it to establish a continuous Client-Server connection with less overhead.</p>

<p>Mercurial has an extension called Largefiles, which allows storing large files outside of the normal history to decrease needed bandwidth for clones and pulls. Large files are stored in a central location and you fetch them only when you need them. Largefiles extension supports by design storing files in the same location as the main repository hosting server. It can be workaround by configuring a web server to redirect largefiles request to some other URL, but this solution does not provide sufficient flexibility. The Project goal is to allow user to specify remote server where large files are stored. Instead of downloading all files from the the main repository, client would download them from remote store, which could greatly decrease load from the main server. Remote store can live anywhere on the web e. g. in the cloud, so connection among clients and the store should be secure.</p>

This project focuses on making SymPy's assumptions system more robust, efficient, and reliable through a three component architectural upgrade. The first component introduces a backend solver for Equality Logic and Uninterpreted Functions (EUF) directly into the SAT engine. The second component upgrades the Linear Real Arithmetic (LRA) solver to safely handle complex domains, irrational boundary limits, and symbolic infinities (like oo) without failing while also refactoring the core ask dispatcher to resolve many recursion loops during query evaluation. Last component, the project will replace thousands of hardcoded static unit tests with dynamic, property-based tests using the Hypothesis library. By automatically generating complex mathematical trees to find hidden bugs, these enhancements will smooth out the rough edges of the assumptions module, making it a significantly faster and mathematically stronger.

A library management add-on for managing Different online-offline FreeCAD components is a utility application for FreeCAD which allows an easy and structured management of components/models available online or offline and to easily be inserted into the FreeCAD document. Its basic functionalities is to facilitate individual component from the online repository to be able to browsed, downloaded, and extended by already available local components. For a Library management system, a robust repository of data and an local storage structure is must. This is important as user need to brows through the all the existing models which are the part of the repository and download only selective models. A structured local storage will not only also allow users to easily add their own models to the local library management system, but also to the online repository open to public. For maintaining the metadata of these, a well defined storage structure is required. All this need to have an proper interface to be operable. The interface for the above will be developed as both a Graphical Interface and module for python scripting.

<p><em>The primary goal of my idea is to implement a WAF which uses Machine Learning to detect anomalies in web traffic.</em></p> <h7>The proposed idea</h7> <p>Since the Securtea is a software that is used on the server-side of an application. In order to implement a WAF we need to monitor the traffic that is being sent to the Web Server. This could be done by utilizing the Ngnix 's and Apache's reverse Proxy. Where we configure the reverse proxy to proxy pass every request to a listening server that is capable of analyzing the traffic. Once the analysis is done it can be passed back to the required server and the response is sent back to the proxy and the proxy would send it back to the client.</p> <p>The analysis part includes , ML model that has been trained with various simulation of web traffic .The simulation includes both good and bad traffic . The traffic is then feature engineered to get additional features , that help us to identify the nature of a traffic.</p>

<p>The proposal is on implementing the SCIM 2.0 compliance test suite which can be run on both the cloud and on premise by eliminating the limitations that can be seen in SCIM 1.1 compliance test suite. In the proposed test suite, it is expected to validate the supportability of a provided service provider, in terms of the SCIM 2.0 core specification and protocol specification.</p> <p>The test suite should be able to generate a detailed analysis view and comprehensive report upon providing the server’s SCIM endpoint. The report should include the test results indicating the coverage percentage of each specification and a detailed view of the results of each test including requests sent by the test suite, expected response and the server response along with the indication whether a particular test is passed or not.</p> <p>Apart from that the test suite should be run against WSO2 Identity Server to identify any gaps between the SCIM 2.0 specifications and Identity Server and provide improvements to the product.</p>