Eclipse Platform - Generating Stronger DSA & RSA Keys

[axmanalad]

As October came to a close, my micro-internship opportunity with CodeDay Labs ended as well. I was given the opportunity by Computing Talent Initiative (CTI) and CodeDay Labs to collaborate with a team and work in an open source contribution for Eclipse Foundation project. I would like to share my insights on how my experience felt like with the team.

Firstly, I would like to thank Sathya Narayanan and Utsab Saha for prepping my advancement to tackle my first open source contribution when participating in the CTI program. Moreover, I also would like to place my gratitude for my teammates, Shawn Lin and Chelsy L. for supporting and ensuring small but powerful tips into dedication for this project, including our technical mentor Polina Keselman for her valuable wisdom.

This transformative journey has only begun, and I cannot wait to find more opportunities. To understand the how my contribution impacted the Eclipse Platform, please take a deep dive into my inspiring article.

Introduction

For one month, I was given the opportunity by CodeDay Labs and Computing Talent Initiative (CTI) Accelerate to contribute to one of the largest Java IDEs, the Eclipse Platform. I was assigned to a team of three with a mentor to solve an issue for this project. From struggling to create the development environment, to searching through the codebase, to brief communications, I saw that our team as a whole was new to contributing; I found that our team revolved on complexities that we needed to embrace towards. In this article, I will present the progression of how our team was able to advance from reading a codebase to compiling and presenting a solution to the project, to gaining another follow-up opportunity. Not only has this project introduced us to the world of open source contribution but it also reflected a learning experience into the steps of programming real world solutions.

The Codebase

Eclipse-Platform is an open source project which is the base framework for the integrated development environment Eclipse. It is the second most popular IDE for Java and was the most popular until 2016. Eclipse is also a free open-source IDE that any programmer can use through multiple operating systems (Windows, Mac, and Linux) and extensible plug-in for customization.

First time opening up Eclipse IDE greets with a “Welcome” page

For Java developers, Eclipse is an important IDE for developing computer applications. This IDE is utilized for computer programming, mainly to write programs or create software with Java, but it can also be written in other programming languages such as C and Python. As the base framework, it holds all the functionalities and services it needs to operate Eclipse for development purposes. These services perform every necessary function a developer would need to create computer applications and optimize their workflow.

For example, a Java developer can develop a mobile application by writing Java code in their coding environment, finding code suggestions by Intellisense, debugging in real-time, and pushing code through a remote server like GitHub inside of Eclipse.
Since Eclipse has been around for more than twenty years and is currently the second most popular IDE for Java development, there are millions of users who still use Eclipse IDE to develop applications with Java.

A Java project showcase of “HelloWorld” utilizing the Eclipse IDE.

In the open source of the Eclipse Platform, committers join in GitHub to contribute to the project. There are 22 repositories that are based on several Java libraries like Ant and Maven. These libraries would then be utilized into repositories as modules that link together to perform operations for other Eclipse repositories such as build tools, the Standard Widget Tool (SWT), etc.

Showcase of Eclipse Platform’s repositories of open contributions.

Tech Stack

Before heading into the issue, there are a few tech stacks that should be interpreted.

Important tech stacks of the Eclipse Platform.

Java Programming Language - This is the core language that Eclipse primarily utilizes to implement the entire IDE. According to the master repository of Eclipse Platform, 96.7% of its repository is made with Java. There are also numerous libraries and modules that the Eclipse Platform integrated with purely Java that it honestly works as the back-end of its program as well.
Workbench, Standard Widget Tool, JFace - All of these frameworks/toolkits incorporate some user interaction. For example, Workbench is responsible for the functionality of the IDE and provides visual options like toolbars and editors. Standard Widget Tool is responsible for supplying graphical interfaces that ensure quality appearance. JFace is responsible for simplifying complex interfaces by handling dialog boxes, wizards, etc.
Equinox - Although the Eclipse Platform does not provide a natural back-end framework, Equinox is the closest by unloading and loading plugins, bundles, and services; allows developers to run applications as bundles.
Java Secure Channel - This is a Java library that is responsible for creating secure/SSH connections between two computers; essential for key management such as DSA and RSA key pairs when authenticating SSH for remote connections like Git. This is also very important for the issue.

About the Issue

The codebase handled weak keys, specifically RSA (Rivest-Shamir-Aldeman) cryptography. The issue that we tackled for the Eclipse-Platform is: When generating an RSA key, it is always defaulted to RSA-1024, a weak encryption that is not as secure as RSA-2048 or RSA-4096.

Locating the Preferences Page for accessing the key generator.

Normally when you open the Eclipse IDE, the application will open your workspace. To generate an RSA-key, you will navigate through Window => Preferences. Afterwards, you can either search up “SSH2” or navigate through General => Network Connections => SSH2. Go into Key Management and there you will find two key generators.

The RSA key generates a random RSA-1024 key to save locally when pressing the “Generate RSA Key..” button.

Showcase of the Key Management, where the RSA key becomes generated.

Meanwhile, what the issue declares to be satisfied is that the key generator should have a larger key size, such that RSA-2048 or RSA-4096 could be generated instead for stronger encryption. A stronger RSA encryption will allow a more secure transmission of sensitive data and protects data exchange between the server and client. This is especially important for open-source projects of many developers that may want to retrieve or transmit data between their side and the server they are working on. For a better visual of how the keys are generated, a system diagram is provided below.

Flow Control of Eclipse’s Key Generation

A simple system diagram on how Eclipse handles key generations.

Digging Into the Issue

Relevant to the issue of generating an RSA key, I had to identify key locations to where the codebase is generating an RSA key by pressing a button. Luckily, the initial comment of the issue provided a hint that the button was in the “Preferences” page. I made a few comments regarding this location to understand how the RSA key gets generated.

Location of the issue in the codebase of PreferencePage.java file.

Another hint proved that this was the location of the issue by exploring the “KeyPair.class”, where a method called “genKeyPair” has a default key size of 1024 bits.

Image of genKeyPair function in KeyPair.class

I had to explore through other classes to understand how each of the new objects work, particularly “KeyPairRSA(jsch)”, which generates the key pair to be in RSA format. From here, I noticed that one of the tech stacks for this issue was the Java Secure Channel (JSch), a Java implementation meant for providing secure connection between clients. Once I figured out how the codebase worked for the particular functionality, I proceeded to start implementing a solution.

Implementing a Solution

The first thing I quickly checked was verifying whether the location of the issue was correct. This was verified by placing print statements for the console to return feedback if the statement was called inside of the function. Once I figured out the statement was called by testing the key generator button, I started to modify the codebase with a simple if and else statement.

Before Code Modification

After Code Modification

My first solution was to fixate the RSA key size to 2048 bits, acknowledging the issue’s recommendation. This was implemented by changing both the “genKeyPair” function and the kpairComment to their respective bit size. The DSA (Digital Signature Algorithm) key size was kept to 1024 bits.

One week later, a few knowledgeable people and the project manager answered my questions that allowed me to adjust my solution. This adjustment upgraded from 2048 bits to 4096 bits as the key size for RSA. DSA would also be formatted to provide 3072 bits instead of 1024 bits. Notably, DSA-4096 would give an error instead of DSA-3072 based on CPU runtime performance; the larger the key size, the more disk storage is utilized, which increases CPU runtime. By this error, I comprehended the idea that DSA-4096 consumes too much disk storage to compute a DSA key with a size of 4096 bits. Despite a decrease in performance, it is better to have a larger key size for more security.

Challenges Before Pull Requesting and Committing the Solution

One challenge prior to searching through the codebase was integrating a working environment. On the first day of attempting to get the workspace, the Contributing Page supplied the instructions, but I had trouble running the workspace as well as connecting to my GitHub forked repository.

The next day with a clear mind, I discovered my faults such as using IntelliJ IDEA as my IDE, attempting to use Visual Studio Code/GitHub’s codespaces, and not installing all packages. I was able to fix my problem by carefully reading the installation instructions as well as using Git Bash and Linux commands to create separate remotes linking to both my forked repository and the main repository. I would learn that following any contributing instructions is essential to open source contributions.

Another challenge involved vague instructions in the issue, such that I do not know whether the issue wants multiple options of generating different key sizes or whether the key size should only affect the RSA key and not the DSA key. The problem with editing the key generator function in the PreferencePage.java file is that both RSA and DSA keys would be affected if we were to add an argument to the key size parameter. I would have to ask about these questions in the issue discussion.

Questions that I asked about the issue (Date: 10/17/2024)

Ever since I asked however, I have never received any feedback from the project managers. After almost a week, my team and mentor joined in a meeting to discuss our progress, and my mentor responded to just continue with the solution despite finding answers from the management team. I would submit my first pull request to the Eclipse Platform project, which was accidentally merged by the project manager without review. However, the project manager was able to answer my questions two days later. With my new solution, I made a new pull request.

The Pull Request Review Phase

The new pull request was made after refactoring the code based on the comment from the project manager. However, the problem with my previous solution involved many issues which were merge conflicts, failure on a few test cases, and messy commits. When the project manager noticed this, he made a feedback mentioning about organization and compiling, including the usage of two Linux commands I had less experience with: rebase and squash.

Before I tackled Git's rebase and squash, I had issues compiling the workspace to run the program, resulting in making the “Revert merge changes” commit. I had the practice of updating the workspace every time there is a new change to sync the fork repository and merge those changes into my local development environment. However, what I never noticed was the other repositories. Remember when I mentioned at the beginning of this blog about the project having 22 repositories? Apparently, these repositories also have to be updated to the latest changes locally. This was resolved according to the project manager’s comment by rerunning the Oomph Eclipse installer, which is the setup needed to create the development environment for contributing. This grabbed the latest changes easily without merging all repositories. I would realize later on that there was a better alternative.

Image of Eclipse Installer made by Oomph

After resolving that issue, I was less familiar with the concepts of rebasing and squashing, which required me to do a bit of research through Linux commands. I researched mostly from StackOverflow threads, absorbing more information such as how to remove a commit in the middle of a commit history and combining commits into a single commit. By the time I rebased and squashed the commits into a single clean commit, I forced-pushed the changes into the pull request. All the test cases have passed flawlessly and I followed up with an appreciative comment for his feedback.

Eclipse’s Test Cases after making the changes.

Afterwards, the project manager requested an organization of code, such that it simplifies the readability of the implementation. Once I cleaned up the code with his request, everything was satisfactory to earn a merge as the final solution.

Final Solution

In summary, the code changes reflect on a key size difference, which affects the output of key generation. By having a larger key size, it is more secure for Java developers to continue programming their projects while using the Eclipse IDE.

Before Code Changes (RSA-1024 Key Sample)

After Code Changes (RSA-4096 Key Sample)

It is an extreme honor to work with my partners along with my mentor to get through this journey. This is an opportunity I would truly never forget to experience the growth of software engineering, and I know my path only starts from here. I would like to thank a project manager of the Eclipse Platform, Hannes Wellmann. He has assisted and suggested an abundant amount of my progression towards developing the solution to the issue. As of November 4, 2024, I am in the process of making another contribution by a follow-up addition which allows the user to select the key size of the generated key.

This discussion was initially posted on LinkedIn.

[tfroment]

Thank you @axmanalad for sharing this great feedback with us here!