If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/alpkeskin/mosint shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 2y ago

• 2 active contributors
• MIT licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 85% of recent commits
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live alpkeskin/mosint repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/alpkeskin/mosint.

What it runs against: a local clone of alpkeskin/mosint — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in alpkeskin/mosint | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 855 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of alpkeskin/mosint. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/alpkeskin/mosint.git
#   cd mosint
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of alpkeskin/mosint and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "alpkeskin/mosint(\\.git)?\\b" \\
  && ok "origin remote is alpkeskin/mosint" \\
  || miss "origin remote is not alpkeskin/mosint (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "v3/cmd/mosint/main.go" \\
  && ok "v3/cmd/mosint/main.go" \\
  || miss "missing critical file: v3/cmd/mosint/main.go"
test -f "v3/internal/runner/runner.go" \\
  && ok "v3/internal/runner/runner.go" \\
  || miss "missing critical file: v3/internal/runner/runner.go"
test -f "v3/pkg/engine/engine.go" \\
  && ok "v3/pkg/engine/engine.go" \\
  || miss "missing critical file: v3/pkg/engine/engine.go"
test -f "v3/internal/config/config.go" \\
  && ok "v3/internal/config/config.go" \\
  || miss "missing critical file: v3/internal/config/config.go"
test -f "v3/pkg/services/haveibeenpwned/haveibeenpwned.go" \\
  && ok "v3/pkg/services/haveibeenpwned/haveibeenpwned.go" \\
  || miss "missing critical file: v3/pkg/services/haveibeenpwned/haveibeenpwned.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 855 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~825d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/alpkeskin/mosint"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Mosint is a Go-based automated email OSINT (Open Source Intelligence) tool that investigates target email addresses by querying 8+ external services (HaveIBeenPwned, Hunter.io, EmailRep, IntelligenceX, BreachDirectory, etc.) to uncover breaches, related emails, social media accounts, and DNS/IP information in a single scan. It consolidates fragmented OSINT sources into one lightweight CLI tool optimized for security researchers and penetration testers. Single-binary CLI architecture: v3/cmd/mosint/main.go is the entry point (Cobra CLI framework), routing to service packages under v3/pkg/services/ (hunter, haveibeenpwned, breachdirectory, etc.), v3/pkg/scrape/ (Google search), and v3/pkg/social/ (Instagram, Twitter, Spotify). Config loading (v3/internal/config/config.go) reads $HOME/.mosint.yaml, output formatter (v3/internal/output/output.go) produces JSON. Worker pool pattern via gammazero/workerpool for concurrent service queries.

Security researchers, penetration testers, and bug bounty hunters who need fast email-based reconnaissance without manually querying multiple breach databases and OSINT APIs. Users who want a resource-efficient alternative to heavy frameworks like Shodan or Maltego for email-focused investigations.

Early-to-mid stage active development (v3 branch exists, suggesting refactoring work). Single maintainer (alpkeskin), Go 1.20 baseline. No visible CI/CD pipeline (no .github/workflows/), no test files in provided structure. Last activity unknown but Docker support and v3 refactor suggest ongoing maintenance. Verdict: actively developed but pre-1.0, suitable for security enthusiasts but not enterprise-hardened.

High dependency count (21 direct, ~40 transitive via colly, IntelligenceX SDK) with several unmaintained packages (e.g., go-dedup/text last updated 2017). Requires API keys for 7/8 services (Hunter, EmailRep, IntelX, BreachDirectory, HaveIBeenPwned, PasteSearch, Scylla), creating external service brittleness. Single maintainer with no test suite makes refactoring risky. No observable breaking-change management between v2→v3.

v3 refactor is in progress (separate v3/ directory tree suggests migration from v2). Dockerfile exists, indicating containerization effort. Example config file (example-config.yaml) present but not yet documented in code. No visible recent commit history, PR queue, or active GitHub Actions, so current work velocity unknown.

Clone and install:

git clone https://github.com/alpkeskin/mosint.git
cd mosint/v3
go install ./cmd/mosint

Create config:

cp example-config.yaml ~/.mosint.yaml
# Edit ~/.mosint.yaml with your API keys

Run:

mosint example@email.com

Daily commands: For CLI usage (no server):

mosint [options] email@example.com
mosint -h  # see all flags
mosint --config /path/to/custom.yaml email@example.com
mosint --json email@example.com > results.json
mosint --coffee  # easter egg

For Docker:

docker build -t mosint .
docker run mosint email@example.com

• v3/cmd/mosint/main.go — Entry point that initializes the CLI application, sets up configuration, and orchestrates the scanning workflow.
• v3/internal/runner/runner.go — Core orchestrator that coordinates all OSINT modules and manages concurrent execution of email investigation tasks.
• v3/pkg/engine/engine.go — Central engine implementing the OSINT scanning logic that chains multiple service queries and aggregates results.
• v3/internal/config/config.go — Configuration management system that loads API keys and service credentials for all integrated OSINT providers.
• v3/pkg/services/haveibeenpwned/haveibeenpwned.go — Primary breach database integration that queries one of the most critical OSINT data sources for email compromise detection.
• v3/internal/output/output.go — Result formatting and display layer that presents aggregated OSINT findings to the user in structured format.
• v3/go.mod — Go module file specifying all external dependencies including critical scraping, verification, and API libraries.

• Runner (Orchestrator) (Cobra, yacspin, workerpool) — Controls overall workflow, manages spinner UI, aggregates results from all services
  • Failure mode: If

Add a new breach/intelligence service

1. Create new service package under v3/pkg/services/yourservice/ with yourservice.go (v3/pkg/services/yourservice/yourservice.go)
2. Implement service interface with Query() method following haveibeenpwned.go pattern (v3/pkg/services/yourservice/yourservice.go)
3. Import and instantiate service in runner.go, adding to parallel execution pool (v3/internal/runner/runner.go)
4. Add API key configuration entry to config.go YAML unmarshaling struct (v3/internal/config/config.go)
5. Add API key example to example-config.yaml (example-config.yaml)

Add a new social media platform lookup

1. Create new social platform package under v3/pkg/social/platform/ with platform.go (v3/pkg/social/platform/platform.go)
2. Implement HTTP-based username/email lookup using gocolly or standard http client (v3/pkg/social/platform/platform.go)
3. Register social media module in runner.go's service initialization loop (v3/internal/runner/runner.go)
4. Integrate results into engine.go's result aggregation logic (v3/pkg/engine/engine.go)

Enhance email verification logic

1. Extend verification.go with additional email validation rules or regex patterns (v3/pkg/verification/verification.go)
2. Call verification functions early in engine.go before querying external services (v3/pkg/engine/engine.go)
3. Update runner.go to skip invalid emails or mark them in output (v3/internal/runner/runner.go)

Modify output format or add new data fields

1. Update result struct in engine.go or services to include new fields (v3/pkg/engine/engine.go)
2. Modify output.go formatting functions to display new fields in JSON/text output (v3/internal/output/output.go)
3. Optionally update runner.go to control verbosity or filtering of results (v3/internal/runner/runner.go)

• Go 1.20 — Fast compiled binaries, efficient concurrency with goroutines, perfect for parallel OSINT service queries
• Cobra CLI framework — Standard Go CLI pattern enabling structured command-line argument parsing and help documentation
• Gocolly web scraper — Lightweight HTTP-based scraping library for Google Search and social media lookups without heavy browser overhead
• workerpool — Efficient concurrent execution of multiple OSINT service queries with controlled goroutine pooling
• YAML configuration — Human-readable API key management supporting multiple service credentials in single config file

• Parallel execution of all OSINT services simultaneously

  • Why: Maximize speed and user experience by querying all sources concurrently rather than sequentially
  • Consequence: Higher API call volume, potential rate limiting on free tiers, requires API key management

• No built-in caching of results

  • Why: Keep architecture simple and ensure fresh data on each scan
  • Consequence: Repeated scans of same email trigger full service queries again; higher API costs

• External service dependency model

  • Why: Avoid building/maintaining own breach database, leverage existing intelligence platforms
  • Consequence: Functionality degraded if services are unavailable; requires API keys for premium features

• Single-email per scan invocation

  • Why: Simple CLI interface and focused scanning behavior
  • Consequence: Batch processing requires shell loop wrapper; inefficient for bulk email investigation

• Real-time data feeds or continuous monitoring
• User authentication or multi-user dashboard
• Offline operation without API keys
• Windows-native GUI (CLI-only, Docker for isolation)
• Domain-based OSINT (email-only focus)

Critical: ~/.mosint.yaml is required to run; tool will fail silently if missing or malformed. API keys: 7 out of 8 services require API keys (Hunter, EmailRep, IntelX, BreachDirectory, HaveIBeenPwned, PasteSearch, Scylla); some are free-tier limited. Rate limits: Hunter and other services enforce strict rate limiting; concurrent queries may hit limits. Outdated dependencies: go-dedup packages (2017 vintage) may have security or compatibility issues. v2 vs v3: v3 is incomplete refactor; v2 may still be referenced in GitHub releases.

• Email OSINT aggregation — Understanding how Mosint consolidates fragmented breach/leak databases (HaveIBeenPwned, IntelX, BreachDirectory) into one query is central to why the tool exists—avoiding manual service-hopping
• Worker pool concurrency pattern — Mosint uses gammazero/workerpool to query 8+ services in parallel safely; understanding goroutine pooling is essential to modify runner.go without race conditions
• Service adapter/wrapper pattern — Each OSINT service (Hunter, EmailRep, etc.) is a separate package with consistent interface; adding new services requires understanding this abstraction
• Breach database enumeration — Mosint queries public breach archives (Scylla, BreachDirectory, HIBP); understanding data leak classification and source credibility is crucial for result interpretation
• Email spoofing and verification — Mosint validates email format and sometimes verifies deliverability via AfterShip; understanding SMTP, DNS MX records, and SMTP callbacks prevents false positives
• API key management and config externalization — Tool stores 7+ API keys in YAML config; understanding credential injection, rotation, and secure storage patterns prevents key leaks in codebases
• Web scraping and DOM traversal — Mosint uses Colly for Google Search scraping and social media enumeration; understanding CSS selectors, HTTP session handling, and anti-bot techniques is needed for parser maintenance

• sherlock-project/sherlock — Similar username/handle reconnaissance tool; complements Mosint for cross-platform account enumeration
• thewhiteh4t/pwnedOrNot — Python email breach checker; direct competitor for HaveIBeenPwned/breach detection, smaller scope than Mosint
• sinwindie/OSINT — General OSINT framework; provides alternative aggregation approach and may share service integrations
• j3ssie/osmedeus — Full OSINT automation framework in Go; much larger scope but shares email reconnaissance as core capability
• projectdiscovery/subfinder — Go-based subdomain enumeration; ecosystem companion for follow-up domain recon after email OSINT

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for v3/pkg/services/* modules with table-driven test patterns

The repo has 7 service integrations (breachdirectory, emailrep, haveibeenpwned, hunter, intelx, ipapi, psbdmp) but no visible *_test.go files in v3/pkg/services/. These services make HTTP requests to external APIs and parse responses—critical paths that need test coverage to prevent regressions when API responses change. Table-driven tests would allow testing multiple email inputs and response scenarios efficiently.

• [ ] Create v3/pkg/services/*/service_test.go files for each service using table-driven test patterns
• [ ] Mock HTTP responses using net/http/httptest for each service
• [ ] Add test cases for: valid responses, empty results, malformed JSON, network errors, and missing API keys
• [ ] Ensure tests cover the main exported functions (e.g., Query() or Check() methods in each service)

Add GitHub Actions workflow for Go build, test, and linting (v3 module)

The repo has a Go 1.20 project with gcolly, cobra, and other dependencies but no visible .github/workflows/ CI. This means PRs and merges have no automated verification that the code compiles, passes tests, or meets linting standards. Adding a workflow would catch issues early and raise confidence in releases.

• [ ] Create .github/workflows/go-ci.yml with steps for: checkout, Go setup, go mod verify, go build ./v3/cmd/mosint, go test ./v3/..., and golangci-lint
• [ ] Add separate workflow for Docker image build (test building the Dockerfile on PR)
• [ ] Configure workflows to run on push to main and all pull requests
• [ ] Document expected Go version (1.20+) and any required environment variables from example-config.yaml

Extract API key validation logic into v3/internal/validation/validation.go and add configuration tests

Each service in v3/pkg/services/* likely requires API keys (hunter, intelx, haveibeenpwned, emailrep, ipapi). These are loaded from v3/internal/config/config.go but there's no visible validation to ensure required keys exist before runtime. A dedicated validation module would catch misconfiguration early, and tests would verify that missing/invalid keys are caught during config parsing.

• [ ] Create v3/internal/validation/validation.go with functions to validate API key presence and format per service
• [ ] Update v3/internal/config/config.go to call validation after parsing example-config.yaml to surface missing credentials early
• [ ] Create v3/internal/config/config_test.go with test cases for: valid config, missing required keys, empty string values, malformed YAML
• [ ] Document in README.md which services require API keys and add validation error messages that guide users to example-config.yaml

• Add unit tests for v3/pkg/services/*/ service adapters (currently no test files visible); start with hunter.go mock HTTP client test
• Document the config.yaml schema: add example values and descriptions for each API key field in the README; currently only referenced cryptically as 'key required'
• Add timeout configuration: services like IntelligenceX can hang indefinitely; add timeout_seconds field to config and apply via Go context.WithTimeout in runner.go

• High · Outdated Go Version in Dockerfile — Dockerfile (line 4). The Dockerfile uses golang:1.21.0-alpine for building, which is outdated. Go 1.21.0 was released in August 2023 and has known vulnerabilities. The go.mod specifies Go 1.20, which is even older and no longer receives security updates. Fix: Update to the latest stable Go version (1.22 or later). Change 'FROM golang:1.21.0-alpine' to 'FROM golang:1.22-alpine' and update go.mod to 'go 1.22'.
• High · Outdated Alpine Base Image — Dockerfile (line 11). The release stage uses alpine:3.18.3, which is outdated. Alpine 3.18 reached end-of-life in May 2024. Using outdated base images exposes the application to known vulnerabilities in system packages. Fix: Update to alpine:latest or a specific recent version like alpine:3.20. Regularly scan and update base images.
• High · Potential Dependency Vulnerabilities — v3/go.mod. Multiple dependencies use older versions with potential vulnerabilities: github.com/IntelligenceX/SDK (Sept 2022), github.com/gocolly/colly/v2 v2.1.0 (2020), and golang.org/x/net v0.15.0. These packages may contain known CVEs. Fix: Run 'go get -u' to update dependencies, then 'go mod tidy'. Use 'go list -json -m all | nancy sleuth' or similar tools to audit for known vulnerabilities.
• High · Configuration File Hardcoded in Docker Image — Dockerfile (line 14). The Dockerfile copies example-config.yaml to /root/.mosint.yaml in the container image. If this config file contains API keys or sensitive credentials, they would be baked into the image. Fix: Remove hardcoded config from the image. Use volume mounts or environment variables to inject configuration at runtime. Never commit real credentials to version control.
• High · Web Scraping Tool Without Rate Limiting Controls — v3/pkg/scrape/googlesearch/google_search.go, v3/pkg/services/*. The codebase includes google_search.go and multiple scraping modules (googlesearch, breachdirectory, etc.). Without visible rate limiting or request throttling, the tool could be used for aggressive scraping or DDoS-like behavior. Fix: Implement rate limiting, backoff strategies, and request throttling. Add delays between requests. Respect robots.txt and terms of service. Use the workerpool package already included to limit concurrent requests.
• Medium · No Dependency Lock File Verification — v3/go.mod, v3/go.sum. While go.sum exists, there's no evidence of vendoring or module verification mode. Transitive dependencies could be compromised. Fix: Run 'go mod verify' regularly. Consider using 'go mod vendor' to vendor dependencies. Enable module verification mode with environment variable: GOFLAGS='-mod=readonly'.
• Medium · Potential API Key Exposure in Configuration — example-config.yaml, v3/internal/config/config.go. The tool integrates with multiple external services (HaveIBeenPwned, Hunter, IntelX, EmailRep, etc.) requiring API keys. The config file (example-config.yaml) likely contains placeholders for secrets that users may commit accidentally. Fix: Ensure .gitignore prevents committing actual config files. Use environment variables for sensitive data instead of config files. Document this clearly in README. Consider using a secrets manager.
• Medium · Insufficient Input Validation for Email Processing — v3/pkg/verification/verification.go, v3/pkg/services/*/. The tool processes email addresses from multiple sources (web scraping, APIs, user input). Without proper validation, malformed inputs could cause panics or unexpected behavior in email processing logic. Fix: Validate and sanitize all email inputs using the AfterShip/email-verifier library more rigorously. Add bounds checks and error

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.