trufflesecurity/trufflehog

user (instead of org) with token is not working

Offen

#4.517 geöffnet am 26.10.2025

Auf GitHub ansehenContributor Guide
 (3 Kommentare) (1 Reaktion) (1 zugewiesene Person)Go (2.397 Forks)batch import
help wantedneeds-reconciliationpkg/sources

Repository-Metriken

Stars
 (26.285 Sterne)
PR-Merge-Metriken
 (Durchschn. Merge 28T 2h) (41 gemergte PRs in 30 T)

Beschreibung

TruffleHog Version

trufflehog 3.90.11

Expected Behavior

Considering this checks an user's repositories:

trufflehog github --org $user

And this checks an organization's repositories:

trufflehog github --org $org --token $GITHUB_TOKEN

This also should check an user's repositories, but now using a token:

trufflehog github --org $user --token $GITHUB_TOKEN

Actual Behavior

When a user is passed to --org and --token is specified, the repositories of the token's owner are being analyzed (instead of the specified user).

Steps to Reproduce

  1. Run the following command using a user instead of an organization:
trufflehog github --org $user --token $GITHUB_TOKEN
  1. Notice that the specified user' repositories will not be checked.

Potential Solution

I have a suggestion that worked here:

  1. Go to the function getReposByOrgOrUser inside pkg/sources/github/repo.go;
  2. Remove the parameter authenticated, and pass false to the function getReposByUser();
  3. Inside pkg/sources/github/github.go, update all the references that call getReposByOrgOrUser, removing the boolean parameter.

I did not create a PR because I feel this solution may have collateral effects that I cannot understand now, having a very superficial context of the code.

Contributor Guide

Research-Richtung
Untersuche die Funktionen `getReposByOrgOrUser` und `getReposByUser` in pkg/sources/github/repo.go, um zu verstehen, wie die Token Authentifizierung das Abrufen von Benutzer vs. Organisations Repositories beeinflusst. Verfolge die Verwendung in pkg/sources/github/github.go und berücksichtige die in der Ausgabe vorgeschlagenen Änderungen.
Tech Stack
go
Domain
backend
Issue Type
Fehler
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
2
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-3 Stunden
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
Go
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
75