Pagure: 22 title matches and two kinds of API token
Pagure is a self-hosted git forge. A public instance can expose repositories, issues, pull requests, project settings, user profiles, and API tokens. The product is small enough that a handful of title matches may represent most of the indexed population, but each instance still has a significant trust boundary.
ZoomEye count-only measurements on 2026-11-09 between 23:46 and 23:47 UTC returned 22 assets for title="Pagure", 181 for http.body="pagure.io", and zero for app="Pagure". The query used sub_type=all, page 1, and page size 1. The body query is a domain-marker search, not a proof that every host runs the forge.
The title count is narrow. The body count is broader because documentation, links, and generated pages may contain the project domain. The zero application count means the public index does not provide a dedicated Pagure fingerprint for this sample. An operator should verify the service by its login and API paths rather than relying on the name.
The token distinction that matters
Pagure's man page documents project-specific tokens and project-less tokens. A token created in a project's settings can be restricted to that project. A token created in the user's settings can act across multiple projects. The token can also carry ACLs for actions such as opening a pull request, changing a ticket, or modifying project settings.
The token's scope extends beyond its expiration date. A user may create a key for a script, then reuse it for a second repository because the first one worked. A project-specific token reduces the blast radius. A project-less token with broad ACLs is closer to a password for the user's forge identity.
The review should include token description, owner, project scope, ACL list, creation date, last use, and revocation status. It should also check SSH keys, deploy keys, and webhooks that can trigger actions in CI. A forge is valuable because it connects source code, issue data, build triggers, and often secrets.
Measurement method
The counts were obtained with the ZoomEye SDK count-only path, requesting one result per dork with sub_type="all", page 1, and page size 1. No asset records were downloaded. The public search link uses the body marker because the title and application fingerprints are both sparse. The operator should treat a body match as a candidate and confirm the Pagure-specific paths before adding it to inventory.
The measurement does not prove that any instance is public, unpatched, or misconfigured. It only records that the name or domain marker appears in the index.
A practical forge review
List the projects and their owners. Identify projects that are archived but still reachable, forks that are not included in the normal backup, and users who left the organization but retain project access. Review group membership and the permissions attached to project-less tokens.
Set a policy for token creation. Prefer project-scoped tokens for automation. Require an expiry date where the forge supports it. Revoke tokens after failed migrations and when a project changes ownership.
Check public exposure separately. A public repository can be intentional while an administrative endpoint remains unsafe. Restrict the management interface, require TLS, and review the reverse proxy for header-trust assumptions. Do not infer that the whole forge is private because the login page is the first indexed result.
Run a controlled authorization test. With a project-scoped token, try to read a second project and modify a project setting. Both operations should fail. Then confirm that the same token can perform the documented operation on its intended project. Record the results with the token identifier and project, never the token value.
What the count can support
The 22 title matches and 181 body matches do not prove that every result is a distinct Pagure instance. They do show that the product and its domain marker are visible in public data. The missing application fingerprint is a reason to use stronger verification, not a reason to ignore the candidates.
For a small forge population, quality matters more than scale. One project-less token with broad ACLs can expose multiple repositories even if the server count is low. The inventory should therefore connect the public title to a token and permission review inside the organization.
Top comments (0)