# Oops: I Leaked Secrets — GitGuardian warned me ...

stephen infanto — Sat, 11 Apr 2026 20:22:12 +0000

I thought I was safe.

My .gitignore had all the usual rules:

.env
.env.*
*.env

But one day, I discovered that my .env.dev and .env.prod files were exposed in a side project.

Here’s what I learned and what you should do if this ever happens to you.

1. `.gitignore` Doesn’t Undo History

Adding files to .gitignore only prevents future commits.

If a file was previously committed, Git will continue tracking it. That’s why changes to my .env.prod were still showing up.

👉 Lesson: .gitignore is not retroactive.

2. Immediate Response Matters

The moment you suspect a leak, act fast.

Revoke exposed keys — treat them as compromised
Rotate API keys, database passwords, tokens
Redeploy applications with fresh secrets
Audit logs for suspicious activity

👉 Assume the worst. Delay increases risk.

3. Cleaning Your Repository History

Deleting the file is not enough.

Sensitive data may still exist in past commits.

To fully remove it:

Use tools like BFG Repo-Cleaner or git filter-repo
Rewrite commit history
Force push the cleaned repository

👉 This is the only way to truly scrub secrets.

4. Preventing Future Leaks

A few practices that help:

Double-check .gitignore paths
Avoid storing critical secrets in .env files
Use secret managers:
- AWS Secrets Manager
- HashiCorp Vault
- GitHub Secrets
Educate your team: once committed, secrets persist unless explicitly removed

5. Stop Tracking Immediately

If a file is already tracked:

(after banging head multiple times)

git rm --cached .env

This removes it from Git tracking without deleting it locally.

Key Takeaway

.gitignore is not a safety net — it’s a guardrail.

If secrets leak:

Rotate → Clean → Monitor

Security isn’t about never making mistakes.
It’s about responding correctly when they happen.

If you’ve faced something similar, I’d love to hear how you handled it.

The CSS Style Dilemma -When to Use `rem`, `em`, `px`, and `%`

stephen infanto — Mon, 13 Oct 2025 07:10:53 +0000

Mastering the CSS Toolkit: When to Use `rem`, `em`, `px`, and `%`

The smallest details often define the scalability and maintainability of a project. In CSS, the choice of unit—be it rem, px, em, or %—is a foundational architectural decision that impacts everything from accessibility to responsive design.

As frontend development becomes more component-driven, understanding the context of each unit is essential to avoid common scaling pitfalls and build truly resilient UIs.

if you are reading this ,chances are you might already know what these are, so, i am gonna be focusing on the when to use --aspect of things

1. The Scalable Standards: `rem` and `em`

These are your primary tools for creating UIs that adapt to user preferences and context.

The Root Master: `rem` (Root Em)

Definition: rem is defined only by the font size of the root element (the <html> tag). If the root font size is 16px, then 1rem equals 16px, regardless of where it's used in the document.
Best Practice Use Cases:
- Typography: The cornerstone of accessibility. Using rem ensures that all text scales uniformly when a user adjusts their browser's default font size.
- Spacing and Layout: Use rem for margins, padding, and standardised component sizes. This links your design system's spacing scale directly to your typography scale, creating a harmonious and scalable interface.

The Contextual Relative: `em`

Definition: The em unit is relative to its direct parent's font-size. If the parent does not have an explicit font size defined, it inherits until it finds the closest ancestor that does.
The "Compounding" Gotcha: Using nested elements styled with em can lead to unpredictable scaling because the value compounds: a child element with 1.2em inside a parent with 1.2em results in 1.44em (1.2×1.2) relative to the root.

Why not remove `em` and only use `rem`?

While rem is preferred for global consistency, em remains vital for local, component-specific scaling.

Local Contextual Scaling (The Tooltip Example): Use em for padding or margins within an element whose sizing should directly adapt to its own font size. For example, a button's padding or a tooltip's offset should increase proportionally if you adjust the button's font size—regardless of the root font size.

2. The Absolute and Fixed: `px` (Pixels)

The px unit represents a fixed, absolute screen pixel. It is the unit of stability and precision.

Best Practice Use Cases (When Absolute Consistency is Required):
- Borders and Separators: A $1\text{px}$ line should always be $1\text{px}$. Using rem for a border would make it scale with the user's font preferences, which is almost never desired.
- Shadows and Blurs: Shadows (box-shadow) and filters are visual effects that rely on absolute values for crispness and consistency across zoom levels.
- Fixed Size Assets and Icons: When integrating external assets or standardized iconography where the size must be non-negotiable (e.g., a $24\text{px}$ icon within a $48\text{px}$ box).

3. The Flexible Fluid: `%` (Percentage)

Percentage units are the workhorse of fluid, responsive layout, providing dynamism relative to a parent context.

Best Practice Use Cases:
- Fluid Layouts: Setting widths of columns, containers, and grid items relative to the parent container.
- Responsive Media: Ensuring images and video elements scale correctly within their containers (e.g., max-width: 100%).

The Fascinating Percentage Quirks (The Padding Paradox)

You’ve likely encountered this "gotcha" when attempting to maintain an aspect ratio:

The Paradox: When you apply padding-top or padding-bottom using a percentage, that percentage is calculated relative to the element’s WIDTH, not its height.

The Height Ambiguity

Width vs. Height Context:
- Width is almost always calculated relative to the parent’s content box, which nearly always has a defined width.
- Height often defaults to auto. If the parent’s height is auto, then setting height: 100\% on the child has no fixed base to calculate from, often resulting in $0$ or just the height of the content.

💡 The Modern Toolkit Summary

For maximum control, maintainability, and accessibility, your unit usage should adhere to context:

Unit	Context	Example Use Cases
`rem`	Global Scalability & Accessibility	Typography, standardized margins/padding, component baseline sizes.
`em`	Local, Self-Contained Context	Padding/radius within an element that needs to scale with its own font size (e.g., button padding, tooltip).
`%`	Fluid Layout & Responsiveness	Element widths, grid columns, media scaling (`max-width: 100\%`).
`px`	Fixed, Unchanging Precision	Borders, box shadows, subtle dividers, fixed-size icons.

Note: Design Tokens are Your Backbone

Before exposing these units directly, ensure you are leveraging **Design Tokens. Good design systems (like Chakra UI) have already encapsulated these best practices, providing you with tokens like spacing-md or font-size-lg that resolve to the correct rem, px, or em values, guaranteeing consistency across your entire codebase.

Forem: stephen infanto

# Oops: I Leaked Secrets — GitGuardian warned me ...

1. .gitignore Doesn’t Undo History