andoriyaprashant / andoriyaprashant/OpSo

security: `.env` file with actual API keys/tokens is committed to the repository root — this exposes credentials to every person who has ever cloned the repo and is a critical security violation

Open
#479 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Dart
Stars
53
Forks
108
PR merge metrics
No merged PRs in 30d

Description

In Flutter projects, `.env` files are used to store API keys, tokens, and other sensitive configuration. A committed `.env` file means:

1. Every person who has ever cloned or forked this repo (109 forks as of today) has a copy of any credentials in that file
2. GitHub archives committed files — even if deleted, the keys remain in git history
3. Any API keys present are already compromised and must be rotated immediately

This is especially concerning since OpSo displays information from multiple open-source programs and may connect to external APIs.

## 🔍 Evidence

The `.env` file is tracked in git (visible in the repo file tree), which means it was intentionally or accidentally added and committed. The `.gitignore` file exists but apparently does not exclude `.env`.

## ✅ Proposed Fix

### Step 1: Remove `.env` from git history immediately

````bash
# Using git-filter-repo (recommended)
pip install git-filter-repo
git filter-repo --path .env --invert-paths
git push origin --force --all

# Alternative: BFG Repo Cleaner
bfg --delete-files .env
git reflog expire --expire=now --all && git gc --prune=now --aggressive
git push origin --force
````

### Step 2: Rotate ALL keys that were in the `.env` file

Whatever API keys, tokens, or secrets were in the file must be considered compromised. Generate new credentials from each respective service.

### Step 3: Create `.env.example` instead

````bash
# .env.example — commit this file with placeholder values
SOME_API_KEY=your_api_key_here
SOME_TOKEN=your_token_here
````

### Step 4: Fix `.gitignore` to exclude all env files

````bash
# .gitignore — ensure this is present
.env
.env.*
!.env.example
*.env
````

### Step 5: Add contributor warning in README

````markdown
## ⚠️ Security Notice
Never commit `.env` files. Always copy `.env.example` to `.env` and fill in your own values.
The `.env` file is excluded from version control by `.gitignore`.
````

## 📁 Files to Modify

| File | Change |
|---|---|
| `.env` | **DELETE from history** immediately |
| `.gitignore` | Ensure `.env` pattern is present |
| `.env.example` | Create with placeholder values only |
| `README.md` | Add security warning about credentials |

**Suggested labels:** `security`, `critical`, `urgent`

I would like to work on this. Could you please assign it to me?

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the tracked .env file, .gitignore, .env.example, and README.md, then inspect the repository history to confirm the exposure. Coordinate with a maintainer before any history rewrite or credential rotation because the proposed changes affect all clones and forks. Done means the sensitive file is removed as agreed, credentials are addressed, environment files are ignored, and contributor guidance is present.

Written by the indexing model from the issue text.

Assessment

Tech stack
dart, flutter, git
Domain
devops, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.