OSGINT turns a GitHub username into the public profile behind it

Two directions of lookup, one public data source

OSGINT is described as an OSINT tool to find information about a GitHub user, and the repository description names the directions explicitly: email2username, username2email and creation date. The README states the goal in one line, to retrieve public information about a GitHub username or email address.

The feature list is four items. Finding a GitHub username from an email address. Finding email addresses associated with a GitHub username, with the honest caveat that this is not always available. Finding public profile information, namely the account creation date, public gists, the numeric ID, GPG keys and SSH keys. And scanning a list of GitHub usernames and saving the results as JSON.

The fourth feature is the one that changes how you would use the tool. The -i input option takes a text file with one GitHub username per line, and the results are written to output.json. That turns a script into a batch job, which is the difference between looking up one account and building a dataset.

The tool is a single file, osgint.py, with a requirements.txt that pins one dependency, requests at exactly 2.34.2, and a tests/ directory. The licence is MIT and the project is by Hippie.

How the username to email direction actually works

The How does it work section is short and worth reading closely, because it explains what you are actually getting.

To find email addresses associated with a username, OSGINT checks the user's public commits, email addresses included in the user's public GPG keys, and the GitHub user API. All three are public sources, which means the tool reports what a careful reader could assemble by hand, just more quickly.

To find a GitHub username from an email address, the README lists two mechanisms. The first is the GitHub user search API, which is the straightforward path and only finds accounts where the email is publicly visible on the profile. The second is marked as work in progress in the README, both by the construction signs around it and by the explicit label, and it involves spoofing a commit with the email and then checking the name in the commit history. The README claims this works every time, and also flags it as unfinished.

That combination is worth thinking about. A mechanism that is described as always working and simultaneously as in progress is a mechanism whose behaviour may change, and it is the one that involves writing to a shared third-party system rather than reading from it.

The project credits its inspiration to Zen, which is linked in the README as the project it was inspired from.

The CLI takes one target and prints a labelled result

The usage is a standard argparse interface with three mutually exclusive targets. The -u and --username option takes a GitHub username, the -e and --email option takes an email address to search for a GitHub username, and the -i and --input option takes a text file of usernames and saves JSON results to output.json. A --json flag switches the output format.

The plain text output is a list of labelled fields, which is convenient for reading in a terminal and for piping:

$ ./osgint.py -u hippiiee
[+] login : hippiiee
[+] id : 41185722
[+] avatar_url : https://avatars.githubusercontent.com/u/41185722?v=4
[+] name : Hippie
[+] blog : https://hippie.cat
[+] bio : Hi !
[+] public_repos : 10
[+] public_gists : 0
[+] followers : 8
[+] following : 9
[+] created_at : 2018-07-13T08:28:00Z

The fields cover the public profile surface: the numeric account ID, the avatar URL, the display name, the blog URL, the bio, the public repository and gist counts, the follower and following counts, and the account creation and update timestamps. The creation date is the field the repository description calls out, and it is the one with the most obvious use in profiling, since it dates the account's existence rather than the activity on it.

With --json the same data is emitted as a JSON object, which is what you want when the output feeds into something else.

What the JSON output shows about email and keys

The JSON example in the README is the most instructive part of the documentation, because it shows how much identifying detail a single public profile can carry.

Alongside the profile fields, the JSON output includes the GPG key URL, the GPG key ID, the public gists URL, and an email array with two addresses:

    "blog": "https://hippie.cat",
    "created_at": "2018-07-13T08:28:00Z",
    "email": [
        "[email protected]",
        "[email protected]"
    ],
    "followers": 8,
    "following": 9,
    "id": 41185722,
    "login": "hippiiee",
    "name": "Hippie",
    "public_gists": "https://gist.github.com/hippiiee",
    "public_repos": 10,
    "updated_at": "2022-08-21T13:11:36Z"
}

The two addresses come from different places in the pipeline. A GPG key uploaded to a GitHub account is published at a predictable URL and carries the identity that was in the key when it was created, which is why the key ID and the address are usually related. A commit email is the other source.

That is the practical point about this tool, and it generalises beyond it. A GitHub account is not a single identifier, it is a set of them, and the correlation between a commit email, a GPG key, a blog URL and an account creation timestamp is often what identifies a person across services. A tool that gathers those fields in one call saves the reader the effort of looking in four places, and the same effort is what makes the result useful.

The reverse direction returns only what the search API can confirm, which in the README's example is a single username field for an email address.

Scanning a list, and the limits of a script with one dependency

The bulk mode is documented with a simple example. The input file holds one username per line, and the README notes that empty lines and surrounding whitespace are ignored:

hippiiee
torvalds

You then run it against that file:

$ ./osgint.py --input usernames.txt

The combined JSON result is printed and saved to output.json.

What the tool does not do is throttle. The requirements are Python 3.10 or newer and a single pinned dependency, requests at exactly 2.34.2, and there is no mention of rate limiting, delays, caching, proxy rotation or authentication in the documentation. The GitHub user API and the search API are both rate limited, and a script that fires a request per username per lookup will hit those limits quickly, and the search API in particular is the stricter of the two.

The other constraint is the one the README states about the email direction, where the fallback path is marked as work in progress. If your workflow depends on resolving an email to a username, the API path is the reliable one and the commit spoofing path is the one to verify before you build on it.

The final point is the release history. The listed release is 1.0.3 from 2022-08-22, and the last push to master was on 2026-09-13. So the code is being touched, but the published artefact is old, which for a script this small matters less than for a library, since there is no API surface to break.

Editorial conclusion

Adopt OSGINT if your work involves correlating public GitHub profiles with email addresses, since it covers both directions, outputs JSON, and handles a list of usernames in one pass. Do not adopt it for anything involving private accounts, since it only touches public data, and treat the email to username direction with care, because the README itself marks the commit spoofing step as a work in progress. Before you rely on it, check the requests pin in requirements.txt, which is a single exact version, read the section on how the tool finds addresses, and note that the last release was 1.0.3 in August 2022 while the last push to master was on 2026-09-13.

Frequently asked questions

Official sources

1. hippiiee/osgint on GitHub
2. Issues
3. License: MIT
4. README
5. Releases