Turning a John the Ripper Good First Issue Into a Draft PR

I started with openwall/john issue #3896, a maintenance issue titled "Consistently (don't) split long source file lines." At first glance it looked like a formatting task. Once I read deeper, it became a lesson in how small style decisions can affect portability, readability, and contributor trust inside a mature C codebase.

What the issue was really about

The issue called out a long OpenBSD-SoftRAID test vector that had been split with backslash continuations. The maintainer proposed a safer approach: close the string on one line, reopen it on the next, and let the compiler concatenate adjacent string constants. That avoids depending on details like trailing whitespace. The second part of the issue was consistency: if one long source line is split, similarly long lines across the project should be handled with the same rule.

How I approached the draft PR

My first draft built on magnumripper's earlier PR #3908. I focused on src/openbsdsoftraid_variable_code.h, split long test vectors into adjacent string constants, and experimented with an .editorconfig line-length rule. I originally aimed for short 80-character splits around delimiter boundaries because that felt readable to me.

The maintainer feedback helped me recalibrate. The project did not want a broad delimiter-based refactor, and it did not want lines split that aggressively. The better target was closer to the existing project discussion: roughly 2000 characters per line for these huge vectors, with changes scoped to the original issue instead of expanding the problem.

Validation and takeaway

I tested the OpenBSD-SoftRAID format with ./john --test --format=openbsd-softraid, and the benchmark completed successfully. The bigger win was learning how to turn maintainer feedback into a better contribution: read the history, stay inside the issue's scope, preserve behavior, and ask clarifying questions early when style and maintainability are part of the bug.

• Issue: long C/header source lines needed consistent treatment.
• Draft PR: split OpenBSD-SoftRAID test vectors using adjacent string literals.
• Lesson: in a mature C project, "just formatting" still needs technical discipline.

Issue #3896 Draft PR #5967

Improving Keyshade.io Through Shared Zod Validation

Keyshade.io is an open-source secrets and configuration management platform. My CodeDay work focused on making auth and product text validation more consistent across shared TypeScript schemas and platform UI flows.

The consistency problem

The work focused on how user input moved from UI components into shared request payloads. Email, OTP, device details, project names, titles, and metadata all needed predictable validation behavior before data moved deeper into auth and product workflows.

Where I investigated

I focused on the platform side first and looked for component entry points where user-provided text moved into request helpers. That led to account and OTP flows, email helpers, device-detail schemas, and shared validation primitives in the @keyshade/schema package.

The schema-driven solution

The branch introduced centralized Zod schemas, including email, OTP, encrypted device data, IP address, metadata, title, and alphanumeric variants. Instead of writing one-off checks inside every component, the validation rules lived in the shared schema package and could be reused by auth, platform, and project request shapes.

On the frontend, OTP and email flows used schema parsing before sending requests, disabling invalid submissions and surfacing clearer feedback. The larger product idea was consistency: shared validation improves feedback and keeps request shapes aligned across the app.

Collaboration and coordination

The work also had a collaboration layer. A maintainer pointed out overlap with Keyshade issue #929, which described unicode values being accepted and then stripped into broken slugs. We clarified how our work related to the existing thread, asked where helper logic should live, and kept changes reviewable through focused commits and technical notes.

• Issue: auth and product input needed stricter, reusable validation.
• Solution: shared Zod schemas with safe parsing before data moved deeper into the app.
• Lesson: validation work is also coordination work when multiple contributors touch shared contracts.

Team PR #1278 Related Issue #929