Skip to content

Instantly share code, notes, and snippets.

View andrew's full-sized avatar
🚙
I may be slow to respond.

Andrew Nesbitt andrew

🚙
I may be slow to respond.
View GitHub Profile

State of OSS Funding: Jun 2025 vs Jun 2026

Comparing state-of-oss-funding (data from Jun 2025) against a fresh pull (2026-07-01).

ecosyste.ms scale (from ecosyste.ms homepage)

metric Jun 2025 Jun 2026
Packages 12.1M 14.4M
Repositories 287M 293M

git-pkgs: Upstream & Downstream

Overview

Two complementary projects under the git-pkgs umbrella that together allow any project, forge, registry, or researcher to understand their place in the dependency graph without relying on a single centralised index.

  • Upstream — A feed reader for your dependencies. Subscribes to standardised feeds from packages you depend on, stores entries locally, and makes dependency activity queryable and actionable.
  • Downstream — An ATProto client library for publishing and indexing dependency relationships. Enables decentralised reverse-dependency discovery by letting projects declare their dependencies as signed, structured records that anyone can index.

Both projects share a local-first, sqlite-backed architecture. They meet in the middle at the git-pkgs proxy, which serves as both an upstream feed aggregator and a downstream record publisher.

Ecosystem hash/digest availability

Survey of which package registries expose a content hash (sha256, sha1, digest, integrity, checksum) for package versions, based on app/models/ecosystem/*.rb and test/fixtures/files/*.

Currently extracting hash into integrity field

Ecosystem Source field Algo Code
adelie C apk checksum adelie.rb
alpine C apk checksum alpine.rb

pacslock

Statically detectable package capabilities

Like capslock but for detecting capabilites in package metadata and archive structure rather than callgraph analysis.

Package capability detection ideas

Ruby (RubyGems)

  • C extensions declared (extensions field in gemspec)
@andrew
andrew / brief-prd.md
Created March 14, 2026 11:44
`brief` is a single-binary CLI tool written in Go that deterministically detects a software project's toolchain, configuration, and conventions, then outputs a structured report of what the project is and how to work with it.

brief — Project Recognition & Inspection Engine Format

Overview

brief is a single-binary CLI tool written in Go that deterministically detects a software project's toolchain, configuration, and conventions, then outputs a structured report of what the project is and how to work with it.

It lives in the git-pkgs GitHub org alongside forge, git-pkgs, and shared Go modules that provide low-level ecosystem mapping — manifest parsing, package URL handling, version range resolution, and ecosyste.ms API integration. By building on these shared modules, brief launches with support for 30+ package ecosystems from day one.

The first consumer is Upkeep, the Forgejo-based autonomous package maintenance bot swarm. brief is one of several deterministic tools that Upkeep runs to provide structured context to AI coding agents before they begin work — replacing the trial-and-error exploration loop that burns turns and tokens. Beyond Upkeep, brief is useful for any AI coding agent (Claude Code, Copilot, Cursor

Adding proxy cache to forgejo using git-pkgs/proxy internals

Context

Forgejo has a package registry that handles 23 ecosystems. Packages are uploaded directly -- there's no pull-through cache from upstream registries like npmjs.org or crates.io. git-pkgs/proxy is a standalone caching proxy for 16 ecosystems that already solves this problem. The question is what can be reused.

Prior art / related issues

This has been requested multiple times in the Gitea tracker (forgejo inherits these):

The Commission's call for evidence rightly identifies European reliance on non-EU digital technologies, but focuses primarily on cloud infrastructure, AI, and end-user applications. There's a critical layer missing: the dependency intelligence infrastructure that sits between source code hosting and application deployment.
Open source software underpins 70-90% of all code in the digital economy. But the infrastructure that tracks, analyses, and secures that software is almost entirely US-controlled: package registries, vulnerability databases, dependency graphs, software composition analysis tools, and automated update services. A European company can self-host Forgejo for code hosting and still depend entirely on US services for vulnerability scanning, dependency updates, license compliance, and SBOM generation.
The M×N Problem
Package management has an M×N problem. Every tool implements support for every ecosystem separately. When a new language ships a package manager, it goes to the back of every queue
require "net/http"
require "json"
require "uri"
require "digest"
require "fileutils"
INSTANCE = "https://mastodon.social"
USERNAME = "andrewnez"
CACHE_DIR = File.join(__dir__, ".cache")

git-pkgs+ gittuf integration investigation

This document explores how git-pkgs and gittuf could integrate to enable dependency-aware security policies for Git repositories. The goal: let gittuf enforce policies like "adding new runtime dependencies requires two approvals" or "block dependencies with critical CVEs" by leveraging git-pkgs' understanding of package ecosystems.

What git-pkgs does

git-pkgs is a Git subcommand for tracking package dependencies across git history. It answers questions like "when was this dependency added?", "who added it?", and "what changed between these two commits?" with a unified interface across 40+ package ecosystems.

git-pkgs was recently rewritten from Ruby into Go, partly to enable this kind of integration (importable as a Go library) and partly to simplify deployment as a single binary. It's in early development and can be adapted to work well with gittuf based on feedback.