Large-Scale-Exploit of GitHub Repository Metadata and Preventive Measures

David Knothe; Frederick Pietschmann

REVIEW 3 major objections 5 minor 16 references

Large-Scale-Exploit of GitHub Repository Metadata and Preventive Measures

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that GitHub's public commit metadata lets an attacker build a phishing-ready database of hundreds of thousands of developers in about a day, and that noreply protection fails for many users.

desk verdict A credible proof-of-concept that mass identity harvesting from GitHub commit metadata works and that noreply addresses leak under a simple merge rule, but the headline numbers are extrapolations built on an unvalidated matching assumption. read the letter →

arxiv 1908.05354 v2 pith:PGIXB4VK submitted 2019-08-14 cs.CR

David Knothe , Frederick Pietschmann This is my paper · ORCID

classification cs.CR

keywords gitmetadataemailharvestingHubAPIpersonmatchingphishingnoreplyaddressesprivacyrepositoryexploitation

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper claims that the email addresses stored in every Git commit are a serious, easy-to-exploit privacy hole when commits are hosted publicly on GitHub. The authors build a scraping tool that fetches popular repositories, clones them, and runs git shortlog, then merges shortlog lines into person profiles using the rule that two lines with the same name or same email belong to one person. With 55,000 repositories they assemble a database of 210,164 people in about 1.5 hours, and they extrapolate that one day of computing yields roughly 650,000 person profiles. They further claim that about 12% of people use GitHub's noreply email service, and that for around half of those the private email can still be recovered from an older commit that used the real address. The paper's main conclusion is that existing countermeasures are insufficient and concrete changes—default noreply addresses, blocked pushes, clone rate limits, and better user education—should be adopted.

What carries the argument

The load-bearing mechanism is identity merging by git shortlog output: a shortlog line is (name, email, commit count), and the paper's person matching rule declares two lines to be the same person if either the name or the email matches. Iterated over thousands of repositories, this merges scattered commits into a person object containing all names, all emails, and all contributed repositories. The rule is what turns isolated email harvesting into a dense, phishing-ready profile database, because a single matching line in any repository is enough to attach a private email to a noreply-protected identity.

What would settle it

Take a controlled group of, say, 1,000 known developers, record their true name-to-email mapping, let their public repositories be processed by the paper's matching algorithm, and count how often two distinct people are merged or one person is split; if the merge rate is substantial, the 34.5% compromised-noreply figure overstates the privacy breach.

Watch

Extended reading notes

Core claim

The central discovery is that GitHub's own privacy feature is undone by Git's historical design. Every commit permanently records an author name and email; even if a user switches to username@users.noreply.github.com, a single earlier commit containing the real address, when merged into a person profile by the same-name rule, links the noreply identity to the private address. The paper's measurements show 210,164 persons from 55,000 repositories, with 31.6% contributing to at least two repositories, and 34.5% of noreply users compromised in the largest run. Extrapolating with regression curves, the authors estimate 1.36 million persons from all 7 million public repositories with at least one star, and roughly 650,000 persons in one day, with the private address known for about half of noreply users.

Load-bearing premise

The entire person database and every compromised statistic rest on the unpublished rule that two shortlog lines with the same name or the same email address always describe the same real person, so distinct people who share a name are silently merged into one identity and one person using different names stays split.

Editorial extensions

If this is right

Existing GitHub rate limits and abuse detection do not stop the attack, because after an initial API fetch the heavy work is ordinary git clone operations, which are not throttled.
A user who ever committed with a real email address cannot hide behind noreply afterwards; one leaked commit links all of their public commit activity to that address.
The person-repository graph makes targeted phishing feasible: the attacker can reference real repositories and programming languages, and the paper estimates click-through between 8% and 35%.
Simple defaults—enabling noreply for new accounts, blocking pushes that expose associated addresses, and adding clone rate limits—would reduce the attack's scale even if they cannot eliminate it.
The database grows sublinearly with repositories (roughly 3,310 × numRepos^0.382 persons), so the attack's marginal yield drops as it covers more repositories.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The person-matching rule has never been validated against known identities; if common names cause false merges, the reported 34.5% compromise rate is an overestimate, and real-world rates could be lower.
The same merging technique would work on any public Git host, not only GitHub, so the attack generalizes to GitLab, Bitbucket, or self-hosted mirrors if their repositories are crawlable.
The repository-coherence graph the paper describes for phishing could also be used defensively, e.g., to flag suspicious accounts that suddenly contribute to many unrelated projects, or to measure developer mobility across projects.
A direct test of the paper's central claim would be to run the pipeline on a cohort with known ground truth (e.g., a set of developers who confirm their own addresses) and compare merged identities against that ground truth.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Short version: this is a real piece of measurement work, not a toy. The authors built a tool that fetches top GitHub repos by stars, clones the smallest 40%, runs git shortlog -sne, and merges lines into person records when name or email matches. The measurements are concrete: 55k repos -> 210k persons in about 1.5 hours, 12% of persons use noreply, and the fraction of noreply users for whom a second address appears rises from 8.3% to 34.5% as more repos are added. That last trend is the most interesting thing in the paper, because it quantifies how a privacy feature degrades as an attacker sees more of a person's commit history.

What's new: earlier work like all-github-commit-emails collected raw addresses; this paper adds cross-repo identity merging and tries to measure how often noreply addresses are linked to real ones. That's a modest but real increment. The paper is also honest about the limits of the existing countermeasures and the proposals (e.g. clone rate limits) are sensible, if unsurprising.

Where it gets shaky: the person-matching rule in Section 2.2.2 is the load-bearing assumption, and it is never validated. 'Same name or same email' merges will create false identities for common names, and those false merges directly inflate Table 4's 'compromised' numbers: if two different developers share a name and one uses a noreply address while the other used a private address, the tool reports a compromise that didn't happen. The paper gives no precision/recall, no .mailmap check, no manual audit. That means the 34.5% and the extrapolated ~50% are upper bounds with unknown bias, not clean measurements. The extrapolations to 7M repos are also soft: they come from power-law fits to seven points and are used to produce the 650k person and 'single day' claims. Those figures should be read as illustrative, not predictive. Single-run measurements without error bars are a minor issue here; the trend is clear enough, but the absence of released code/data makes the quantitative claims harder to check.

Overall, the central qualitative claim holds up. You can harvest commit metadata at scale, and noreply is not as private as users think. The paper deserves a serious referee, but the authors should validate the matching rule, release the tool and data, and soften the extrapolated numbers.

Referee Report

3 major / 5 minor

Summary. This paper describes an attack pipeline that (1) uses the GitHub Search API to enumerate popular repositories, (2) clones a size-filtered subset and runs git shortlog -sne, (3) merges shortlog lines into person objects using the rule that lines with the same name or the same email belong to the same person, and (4) identifies GitHub noreply addresses that can be linked to other email addresses. The authors present measurements from an implementation named The Monster for repository counts from 100 to 55,000, reporting runtime, database size, and the fraction of noreply users for whom an additional email was found. They then fit regression curves to these seven data points and extrapolate to 7 million repositories, claiming an attacker can build a database of 650,000 persons in one day and that about 50% of noreply users can be linked to a private email address. The paper concludes with countermeasure proposals for Git, GitHub, and users.

Significance. If the measurement claims were fully supported, the paper would document a practical and scalable privacy weakness in the current Git/GitHub identity model, with concrete consequences for phishing risk. The paper's strengths are the direct measurement campaign (Tables 2–4 give concrete data points across seven repository counts) and the concrete, actionable countermeasures (default noreply addresses, push blocking, clone rate limits). However, the central quantitative claims rest on an unvalidated person-matching rule and on extrapolations from a small number of single-run measurements; the headline figures are therefore upper bounds with unknown bias rather than measured rates. The work is a useful measurement study but, as it stands, the strength of the conclusions exceeds the strength of the evidence.

major comments (3)

[§2.2.2, §3.2.3, Table 4] The person-matching rule in §2.2.2 ('Two lines that are matching (same name or same email address) come from the same person') is load-bearing for all person-level statistics, but it is never validated against ground truth. The paper provides no precision/recall estimate, no comparison with .mailmap data, and no manual audit of a sample of merged identities. This matters because §3.2.3 defines a noreply user as 'compromised' when the merged person object also contains any non-noreply address. If two distinct developers share a display name, one using a noreply address and the other using a private address, the merge rule creates a false compromise. The observed rise in the compromised rate from 8.3% at numRepos=100 to 34.5% at numRepos=55,000 is consistent with the accumulation of such false merges as more repositories are added, so the extrapolated ~50% claim in §3.3.3 inherits an unknown positive bias. Please validate the matching rule (e.g., via a sample of known GitHub users' commit histories) and report the resulting precision/recall, or explicitly reframe the compromised percentages as 'potential associations' rather than confirmed leaks.
[§3.3.2, §3.3.3, §3.1] The headline extrapolations (650,000 persons in one day; ~50% of noreply users compromised) are based on regression curves fitted to the seven measured points in Tables 2–4, with no error bars, no confidence intervals, and no cross-validation. The timing model in §3.3.1 (totalTime ≈ 0.1 sec × numRepos) is explicitly network-dependent, and the 40% smallest-repository threshold in §3.1 is an unoptimized free parameter. Because the extrapolation extends to numRepos values 100–10,000 times larger than the largest measured run, small changes in the fitted exponents (e.g., the 0.382 power for totalPersons) produce very large changes in the predicted totals. Please provide uncertainty bounds on every extrapolated figure, report repeat runs (especially at 55,000 repositories) to assess run-to-run variability, and present a sensitivity analysis over the repository-selection parameters.
[§3.3.2] The comparison of the shortlogLines regression to the 'all-github-commit-emails' dataset (5.3 million addresses) is not an independent validation: that dataset was assembled from the full public GitHub corpus, whereas The Monster deliberately selects top-starred repositories and discards the largest 60% by size. The regression curve is fit to data generated under The Monster's selection bias, so the coincidence of the extrapolated value with the 5.3 million figure is a within-model consistency check at best. Please either remove this comparison or clearly label it as a coarse consistency check, not a validation of the extrapolation.

minor comments (5)

[§1.5.1] The text 'GitHub API The Github API itself...' contains an inconsistent capitalization ('Github' vs 'GitHub'), and the sentence 'This event information will only contain an actual email address if the user has not or just recently activated GitHub’s noreply-email-address service' is unclear; it should state explicitly whether the events endpoint returns the commit email or the user's primary email.
[§3.2.1, Table 2] The table note 'clone, shortlog and merge added up take longer than step 2 – this is because cloning, shortlog and merging are performed simultaneously' states the sum of component times exceeds the wall-clock time of step 2. Since the components overlap, the sum being larger than the wall-clock time is expected; the note should explain why the overlap does not imply that the sum is a meaningful measure of resource consumption.
[§4.2.2] The proposal to change noreply-email-addresses to contain only a numeric ID or a random string would break the existing address format and could leak the ID anyway; a discussion of backward compatibility and of the cost of the extra API lookup per user would strengthen the proposal.
[§3.2.3] The term 'private email address' is used to describe any non-noreply address found for a person; since many developers use public, dedicated commit addresses (e.g., commits@example.com), the measured quantity is not necessarily private. Please adjust the terminology to 'non-noreply email address' or justify the assumption that all such addresses are private.
[Conclusion, Update] The update in the conclusion (August 14, 2019) mentions that GitHub declined to address the proposals, but gives no details on the disclosure timeline or GitHub's response; a brief responsible-disclosure note would be useful to readers.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the measured attack is direct, and the extrapolated figures are transparently labeled regression estimates rather than independent predictions.

full rationale

The paper's derivation chain is empirical rather than definitional. Section 2 defines an attack pipeline, and Section 3.2 reports direct measurements from running The Monster (Tables 2-4). The Section 3.3 'Monster Estimates' are explicitly labeled as estimates and are said to be 'based on these measurements and equipped with sensible regression curves,' so the extrapolated values are presented as model-based extrapolations, not as hidden fits renamed as predictions. The shortlog-lines regression is also checked against the independent all-github-commit-emails dataset (about 5.3 million vs. 5 million), which is an external benchmark rather than a self-referential validation. The person-matching rule in Section 2.2.2 ('same name or same email address') is an unvalidated heuristic that could inflate the 'compromised' statistics, but this is a validity and accuracy threat, not circularity: the reported numbers are computed from the data under an explicit assumption, not derived from the conclusion. No load-bearing self-citation, imported uniqueness theorem, or ansatz-by-citation appears. The central measurements therefore do not reduce to their own inputs by construction.

Assumptions & free parameters 5 free parameters · 5 assumptions · 0 invented entities

The central claim rests on the person matching rule, the definition of 'compromised', and the representativeness of the repository sample. The quantitative impact estimates additionally depend on regression curves fitted to the paper's own measurements. No new physical or conceptual entities are introduced.

free parameters (5)

Smallest 40% of repositories threshold = 0.4 (40%)
Section 3.2 states this is 'just a value that seems to be a good fit'; it determines which repositories are cloned and hence all measured statistics.
shortlogLines regression coefficient and exponent = 2000, 0.5
Section 3.3.2 fits shortlogLines approx 2000 times numRepos^0.5 to the seven measurement points and uses it to estimate 5.3 million lines at 7 million repositories.
totalPersons regression coefficient and exponent = 3310, 0.382
Section 3.3.2 fits totalPersons approx 3310 times numRepos^0.382 and extrapolates to 1.364 million persons at 7 million repositories.
Compromised percentage slope and intercept = 9.4, -11
Section 3.3.3 fits compromised-percentage approx 9.4 times log10(numRepos) minus 11 and extrapolates to 53% at 7 million repositories.
Total time factor = 0.1 seconds per repository
Section 3.3.1 states totalTime approx 0.1 seconds times numRepos, based on a linear fit and a specific 250 MBit/s network assumption.

assumptions (5)

domain assumption Two shortlog lines that share either the same author name or the same email address describe the same person.
Invoked in Section 2.2.2 as the person matching rule. It is load-bearing for the database size and for the 'compromised noreply' statistic, and it can merge distinct developers who share a name.
domain assumption A person with a GitHub noreply address and any other email address in the database has had their private email exposed despite using the noreply service.
Section 3.2.3 defines 'compromised' this way. False merges from the name-matching rule can create this combination without any actual leak.
domain assumption The set of top repositories by star count, restricted to the smallest 40%, is representative enough to extrapolate measurements to all public GitHub repositories (up to 7 million).
Section 3.3 extrapolates power-law fits from up to 55,000 repositories to 7,000,000. No justification shows that the repository selection does not bias the person counts, the noreply adoption rate, or the compromise rate.
domain assumption GitHub Search API queries with stars:>=5 return a complete and unbiased list of top repositories for the enumeration loop in Section 2.1.1.
The pagination strategy assumes the star-based ordering is stable and exhaustive; the authors note the threshold avoids incomplete_results responses, but they do not check coverage against an independent source.
domain assumption Phishing susceptibility rates measured in non-GitHub populations apply to the GitHub developer population.
Section 3.4 extrapolates click and credential-entry rates from general and academic populations to the collected developer database without a dedicated experiment.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Large-Scale-Exploit of GitHub Repository Metadata and Preventive Measures." pith.science (2026). https://pith.science/paper/PGIXB4VK

@misc{pith2026190805354,
  author       = {Pith},
  title        = {Pith review of: Large-Scale-Exploit of GitHub Repository Metadata and Preventive Measures},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PGIXB4VK}},
  note         = {Machine review of arXiv:1908.05354}
}

read the original abstract

When working with Git, a popular version-control system, email addresses are part of the metadata for each individual commit. When those commits are pushed to remote hosting services like GitHub, those email addresses become visible not only to fellow developers, but also to malicious actors aiming to exploit them. As a part of our research we created a tool that leverages the publicly available GitHub API to collect user data. Analysis of this data not only gives access to millions of email addresses in very little time, but is also powerful and dense enough to create targeted phishing attacks posing a great threat to all GitHub users and their private, potentially sensitive data. Even worse, existing countermeasures fail to effectively protect against such exploits. As a consequence and main conclusion of this paper, we suggest multiple preventive measures that should be implemented as soon as possible. We also consider it the duty of both companies like GitHub and well informed software engineers to inform fellow developers about the risk of exposing private email addresses in Git commits published publicly.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

16 extracted references · 16 canonical work pages

[1]

url: https : / / git - scm

Git Internals – Git Objects. url: https : / / git - scm . com / book / en / v2 / Git - Internals-Git-Objects

work page
[2]

url: https://bounty.github.com

GitHub Security Bug Bounty. url: https://bounty.github.com

work page
[3]

url: https://bounty.github.com/ineligible.html

Ineligible submissions. url: https://bounty.github.com/ineligible.html

work page
[4]

All GitHub Commit Emails. doi: 10 . 5281 / zenodo . 3370320. url: https : / / github.com/cirosantilli/all-github-commit-emails

work page
[5]

url: https://www.gharchive.org

GH Archive. url: https://www.gharchive.org

work page
[6]

url: https : / / github

GitHub Repository: igrigorik/gharchive.org – commit: sha1 email username instead of dropping the ﬁeld. url: https : / / github . com / igrigorik / gharchive . org / commit/c9ae11426e5bcc30fe15617d009dfc602697ecde

work page
[7]

url: https : / / developer

GitHub Developer – REST API v3 – Rate limiting. url: https : / / developer . github.com/v3/#rate-limiting

work page
[8]

url: https://developer

GitHub Developer – REST API v3 – Abuse rate limits. url: https://developer. github.com/v3/#abuse-rate-limits

work page

Show all 16 references

[9]

url: https://github.blog/2013-08-09-keep-your- email-private

Keep Your Email Private. url: https://github.blog/2013-08-09-keep-your- email-private

2013
[10]

url: https : / / github

Private emails, now more private. url: https : / / github . blog / 2017 - 04 - 11 - private-emails-now-more-private

2017
[11]

url: https://help.github

Accessing GitHub using two-factor authentication. url: https://help.github. com/en/articles/accessing-github-using-two-factor-authentication
[12]

url: https://qz.com/ 977085/as-long-as-humans-have-access-to-email-phishing-will-work

People will never stop clicking links in phishing emails. url: https://qz.com/ 977085/as-long-as-humans-have-access-to-email-phishing-will-work
[13]

url: https://www

The impact of usability on phishing: prevention eﬀectiveness. url: https://www. cyberdefensemagazine.com/the-impact-of-usability-on-phishing-prevention- effectiveness
[14]

Phishing in an Academic Community: A Study of User Susceptibility and Behavior

Alejandra Diaz, Alan T. Sherman, and Anupam Joshi. “Phishing in an Academic Community: A Study of User Susceptibility and Behavior”. In:arXiv e-prints, arXiv:1811.06078 (Nov. 2018), arXiv:1811.06078. arXiv:1811.06078 [cs.CR]

2018 arXiv
[15]

url: https://www.theverge.com/2018/1/23/16922500/gmail-users-two-factor- authentication-google

Over 90 percent of Gmail users still don’t use two-factor authentication. url: https://www.theverge.com/2018/1/23/16922500/gmail-users-two-factor- authentication-google

2018
[16]

url: https://help.github.com/en/articles/changing- author-info

Changing author info. url: https://help.github.com/en/articles/changing- author-info. IV

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [1]

url: https : / / git - scm

Git Internals – Git Objects. url: https : / / git - scm . com / book / en / v2 / Git - Internals-Git-Objects

work page

[2] [2]

url: https://bounty.github.com

GitHub Security Bug Bounty. url: https://bounty.github.com

work page

[3] [3]

url: https://bounty.github.com/ineligible.html

Ineligible submissions. url: https://bounty.github.com/ineligible.html

work page

[4] [4]

All GitHub Commit Emails. doi: 10 . 5281 / zenodo . 3370320. url: https : / / github.com/cirosantilli/all-github-commit-emails

work page

[5] [5]

url: https://www.gharchive.org

GH Archive. url: https://www.gharchive.org

work page

[6] [6]

url: https : / / github

GitHub Repository: igrigorik/gharchive.org – commit: sha1 email username instead of dropping the ﬁeld. url: https : / / github . com / igrigorik / gharchive . org / commit/c9ae11426e5bcc30fe15617d009dfc602697ecde

work page

[7] [7]

url: https : / / developer

GitHub Developer – REST API v3 – Rate limiting. url: https : / / developer . github.com/v3/#rate-limiting

work page

[8] [8]

url: https://developer

GitHub Developer – REST API v3 – Abuse rate limits. url: https://developer. github.com/v3/#abuse-rate-limits

work page