DEV Community: Shreya Dutta

Syncing a Private GitHub Repo to a Public Org Repo with GitHub Actions (and the auth trap nobody tells you about)

Shreya Dutta — Sun, 31 May 2026 17:11:49 +0000

I recently set up a CI/CD pipeline for TraceHawk — my DevSecOps scanner project under the ArceonSec GitHub org.

The goal was simple: dev happens in a private repo, and when code reaches prod, it automatically syncs to the public org repo.

Simple in theory. Two hours of PAT hell in practice 🙄

Here's everything I learned so you don't have to.

The Setup

Three branches in the private repo:

main — active development
staging — CI checks run here (Ruff, Docker build, Gitleaks, Semgrep, health check)
prod — triggers automatic sync to the public ArceonSec org repo

The public org repo (ArceonSec/tracehawk) only has main and always mirrors prod.

Nobody commits there directly.

Also because I am the only member :')

The Workflow

name: Sync To Public Repository

on:
  push:
    branches:
      - prod

jobs:
  sync-to-public:
    name: Sync Prod To ArceonSec
    runs-on: ubuntu-latest
    timeout-minutes: 10
    environment:
      name: production

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Configure Git
        run: |
          git config user.name "GitHub Actions"
          git config user.email "actions@github.com"

      - name: Remove Default Auth Header
        run: |
          git config --local --unset-all "http.https://github.com/.extraheader"

      - name: Add Public Repository Remote
        run: |
          git remote add arceon \
          https://x-access-token:${{ secrets.ARCEON_PAT }}@github.com/ArceonSec/tracehawk.git

      - name: Push Prod Branch To Public Main
        run: |
          git push arceon prod:main --force

Looks straightforward.

It wasn't.

Trap #1 — The Auth Header Override

This one got me the hardest.

actions/checkout sets a local Git config header called:

http.https://github.com/.extraheader

with the default GITHUB_TOKEN authorization.

This happens silently in the background.

When you add a second remote and try to push using your PAT, GitHub Actions still uses this default header — effectively ignoring your PAT entirely.

The push fails with:

remote: Permission to ArceonSec/tracehawk.git denied to github-actions[bot].
fatal: unable to access: 403

Fix

Unset the header before pushing:

git config --local --unset-all "http.https://github.com/.extraheader"

Add this before adding the remote.

This was the root cause of most of my pain.

Trap #2 — PAT Scopes

You need exactly two scopes on your Classic PAT:

repo — to push to the org repo
workflow — because your repository contains .github/workflows/ files

Without workflow, GitHub blocks the push:

refusing to allow a Personal Access Token to create or update workflow
without `workflow` scope

Fix

Add the workflow scope and regenerate the token.

Trap #3 — Org PAT Access

If you're pushing to an organization repository, the org must allow PAT access.

Navigate to:

github.com/organizations/YOUR_ORG/settings/personal-access-tokens

Make sure both:

Classic PATs
Fine-grained PATs

are allowed.

Some organizations restrict PAT access by default.

Trap #4 — Environment Secrets vs Repository Secrets

I used a production environment block:

environment:
  name: production

This changes where GitHub looks for secrets.

Instead of repository secrets, GitHub now checks environment secrets.

If ARCEON_PAT exists only as a repository secret, the workflow won't find it.

Fix

Either:

Add the secret to the environment
Remove the environment block

I kept the environment block because it allows deployment protection rules later.

The PAT Setup (Correct Way)

1. Create a Classic PAT

GitHub
→ Settings
→ Developer Settings
→ Personal Access Tokens
→ Tokens (classic)

Scopes:

repo
workflow

2. Allow PAT Access

Organization Settings
→ Personal Access Tokens

Ensure PAT access is allowed.

3. Add the Secret

Private Repo
→ Settings
→ Environments
→ production
→ Add Secret

Name:

ARCEON_PAT

The Full Branch Flow

main (dev)
    ↓ manual merge when ready

staging
    ↓ CI runs
    ↓ Ruff
    ↓ Docker build
    ↓ Gitleaks
    ↓ Semgrep
    ↓ Health check

prod
    ↓ sync workflow fires

ArceonSec/tracehawk (main)

Dev stays private.

Public repo stays clean and presentable.

Why `--force`?

Since ArceonSec is a pure mirror, prod should always win.

If histories diverge (for example, someone manually pushes to the public repo), a normal push gets rejected.

git push arceon prod:main --force

is safe here as long as nobody commits directly to the mirror repository.

Which they shouldn't.

All Checks Passed <3

happy noises 🦅🦅🦅

TL;DR Checklist

✅ Unset the default auth header before pushing to another repository
✅ PAT needs repo + workflow scopes
✅ Allow PAT access in organization settings
✅ Put the secret in the correct location (environment secret if using environment:)
✅ Never commit directly to the mirror repository

That's it.

Took me two hours to figure out.

Should take you five minutes now :)

Thanks for reading :>

Chat with me on X/Twitter :)

How Strong Is Dropbox Password Security? Real Password Crack Time Analysis Using Modern GPU Models

Shreya Dutta — Sun, 08 Feb 2026 06:33:31 +0000

Hey everyone 👋🏻 I’m Shreya, a Computer Science student with cyber security as a specialization, exploring the various areas in Information Security. Today’s blog covers password policy analysis with Dropbox as a case study.

Password Policy Analysis — Dropbox

Password policy (Observed + Documented behavior):

At least 8 characters
Encourages letters, numbers, symbols (UI driven strength feedback)
Pattern / common password detection (not just character rules)

Though it doesn’t meet the 12 character requirement like many newer orgs these days, 8 characters is pretty much the minimum baseline still accepted across many platforms. Modern security guidance is slowly pushing toward 12–16+ characters as safer defaults.

Industry reality:

8 = legacy baseline
10–12 = modern baseline
14–16 = strong modern

Also to note, there’s no strict Upper/Lower case enforcement rule publicly documented, which can look like a drawback from a traditional complexity-rule viewpoint, but modern systems often prefer entropy + pattern detection instead of forcing predictable complexity substitutions.

Dropbox actually uses password strength detection that compares passwords against common words, names, patterns and numbers to prevent easy-to-guess passwords.

For more info: https://help.dropbox.com/security/password-control

Dropbox also recommends longer passwords, unique passwords per service, and enabling 2FA or passkeys for stronger protection.
Here: https://help.dropbox.com/security/secure-password

Passwords to Test

password_123
bluey#1996
bg@1996_dropbox

Detailed Explanation For Why Each Password Will Eventually Be Cracked

1️⃣ password_123

Very common password variant of this being “password123” has been in pretty much every password leak databases for years now, so this variant will also be cracked easily.

Attack reality:

This would likely be cracked instantly using credential stuffing or breach database matching, not brute force.

2️⃣ bluey#1996

Identical to email/first name plus 1996 could highly mean their birth year.

A little digging about the person’s identity and boom you have it all with all possible variants with name/birthdate etc.

Attack reality:

This is classic OSINT-derivable password construction.

3️⃣ bg@1996_dropbox

Abbreviation of name + year + website they’re signing up for along with 2 special characters.

Slightly better than last 2 but still very predictable as it’s a combo of name/DOB/website. Still not secure enough.

Attack reality:

Attackers specifically test service-name + year + initials combos.

Crack Time Testing

Went a step ahead and checked how long it’ll take hackers with modern tools to crack the above three.

Results:

First 2 → under 1 sec
Third → ~8 hrs

Important Context

These tools estimate brute-force cracking assuming:

No prior knowledge
No breach database
No OSINT

Real attackers usually try:

Leaks
Pattern mutations
OSINT guessing
Then brute force

You can try it on:

https://www.mypasswordchecker.com/

4th Password — Password Manager Style

I’d like to take a 4th password for the analysis, something that Google password manager would suggest:

XFu2&3fM^Tm&&2#

Looks like sci-fi but let’s see:

It does say very strong but modern GPUs can theoretically crack it in <12 days (pure brute force estimate assuming high compute resources).

Real-World Note

Without:

Breach exposure
Password reuse
Offline hash cracking

Attackers are unlikely to brute force something like this unless extremely high value target scenario.

Conclusion

Looks like we need to step up the password game.

Real Modern Direction

Longer passwords / passphrases
Unique per service
Password manager usage
MFA / Passkeys

Extra Real-World Security Context

Modern password strength systems don’t just check symbols. They check:

Common password lists
Human language patterns
Keyboard patterns
Known leaks

Research shows machine learning models can now learn real human password behavior from leak datasets and improve password guessing success significantly.

Also, password strength meters themselves can leak pattern info or be gamed if poorly designed.

Cool Research Papers to Explore

Human Password Modeling Research

https://arxiv.org/abs/2407.14145

Password Strength Meter Risks Research

https://arxiv.org/abs/2505.08292

Password Entropy Theory

https://arxiv.org/abs/2404.16853

NOTE

Most accounts are NOT hacked via brute force.

Most are compromised via:

Password reuse
Phishing
Malware / infostealers
Credential stuffing

Passwords are slowly becoming just one layer of authentication.

Hope you liked the write-up 🙂

Follow up in X / Twitter.