Privacy notice
What PkgFire collects, why, who else receives it, how long it is kept, and what you can ask for. It covers the hosted service at pkgfire.org, the pkgfire CLI when it talks to that service, and the PkgFire GitHub App. A self-hosted copy of PkgFire is run by whoever operates it, and this notice does not apply to it.
Who is responsible
PkgFire is run by Caio Ricciuti, a sole trader established in Spain. He is the controller of the personal data described here.
Contact for anything in this notice, including requests to exercise your rights: me@caioricciuti.com. No data protection officer has been appointed.
What is collected and why
| Data | Why | Legal basis (GDPR art. 6) |
|---|---|---|
| Account. Your email address, the name you choose to show (optional), and when you last signed in. | To give you an account and send you sign-in links. | Contract, 6(1)(b) |
| Waitlist (only while sign-up is by invitation, and only for an address with no account). The email address entered on the sign-in page, when it first and last asked and how many times, and whether and when it was let in. Nothing is sent to the address when it joins; it gets one email when it is let in. | To offer that address an account when there is room, and to tell the operator who is waiting. | Steps taken at your request before a contract, 6(1)(b) |
| Organisations and members. The accounts you belong to, their names, your role in each (owner or member) and when you joined. Everyone in an account sees its members' email addresses and roles. | So a team can work in one account and its owners can manage who belongs to it. | Contract, 6(1)(b) |
| Invitations. When an owner invites someone: the address invited, the role offered, who invited them, and when it was sent, accepted, declined or withdrawn. The invited person receives one email. | To deliver the invitation and let the invited person join. | Legitimate interest of the inviting account in adding the people it chooses, 6(1)(f) |
| Sign-in and sessions. Each sign-in link is stored only as a hash, with the IP address that asked for it. Each session is stored as a hash of its cookie, with the browser's user agent and IP address at sign-in. | To sign you in, keep you signed in, and limit abuse of the sign-in form. | Contract, 6(1)(b); legitimate interest in security, 6(1)(f) |
| Passkeys (only if you add one). The passkey's public key and id, the name you give it, whether it is synced between devices, a signature counter, and when it was added and last used. The private key stays on your device or in your password manager and never reaches PkgFire. A passkey sign-in is recorded in the activity log like any other. | To let you sign in without an emailed link. | Contract, 6(1)(b) |
| API keys. A name and description you choose, a short display prefix, and a hash of the key. The key itself is shown once and never stored. | So the CLI and CI can use your account. | Contract, 6(1)(b) |
| Projects and scans. Project names; the repository URL, branch and commit the CLI reads from your checkout; the dependency list you submit (package names, versions, download URLs and integrity hashes, as in your lockfile), kept as submitted; and what the scans found: findings, verdicts and the scanners' results. | To check your dependencies and show you the results and their history. | Contract, 6(1)(b) |
| CLI context. CLI version, operating system, architecture, package manager, the name of the CI system if one is detected, and the install command line as you typed it. Keep credentials off that command line: it is stored as written. | To record what was installed, and to debug reports. | Contract, 6(1)(b) |
| GitHub App (only if you connect it). The installation, the names and ids of the repositories you connect (only ones you administer), pull request numbers, the commit hashes at the head and base of each pull request, and the dependency files read at those commits. The short-lived token GitHub issues while you authorise the app is used once and not stored. | To check pull requests and report the result as a check on GitHub. | Contract, 6(1)(b) |
| Activity log. Actions taken on an account, such as sign-ins, policy changes, API key changes and members invited, joining, changing role or leaving: who did it (their email, or the API key's name), the IP address, and for a sign-in the browser's user agent. Every member of the account can read its log. | So you can see who changed what, and to investigate misuse. | Legitimate interest in security and accountability, 6(1)(f) |
| Credits. The account's credit balance and the ledger of what each scan reserved and used, including the free monthly credits given to personal accounts. If paid credits are offered: an order record, with payment handled by Stripe. Card details go to Stripe and never reach PkgFire. | To run the credit system and keep accounts. | Contract, 6(1)(b); tax records are a legal obligation, 6(1)(c) |
| Server logs. IP address, time, requested address and user agent of each request, in the web server's and the application's logs. The address of a sign-in link, including its token, appears in the web server log. That token works once and expires after 15 minutes. | To run the service, and to detect and investigate attacks. | Legitimate interest in security, 6(1)(f) |
Cookies. PkgFire sets one cookie, the session cookie that keeps you signed in. It is strictly necessary for the service you asked for. There are no analytics, advertising or third-party scripts on pkgfire.org.
No decisions about people are made automatically. A verdict is about a package, not about you.
Who else receives data
- Hetzner Online GmbH hosts the server, in Finland (EU). Everything above is stored there. PkgFire's email is sent from its own mail server, also hosted by Hetzner in Finland: the recipient's address and the message, which is a sign-in link, an invitation to an account, or an alert that goes to every member of the account it is about.
- GitHub, only if you connect the GitHub App: PkgFire reads pull request data through GitHub's API and writes the check result back. GitHub is a US company.
- Stripe, only if you buy credits: Stripe handles the payment. Paid credits are not offered at the moment.
Where a provider is outside the European Economic Area, the transfer relies on that provider's data protection terms. Data is not sold, and it is not shared for advertising. Nothing is sent to an AI provider.
Package lookups in public services
To check a package, PkgFire asks public services about it by name and version, and downloads its published archive. Those services receive package names and versions from PkgFire's server, never your account details:
- npm:
registry.npmjs.organdapi.npmjs.org - Go:
proxy.golang.organdsum.golang.org. The Go toolchain can also contact a module's source host directly. - Rust:
index.crates.ioandstatic.crates.io - Python:
pypi.organdfiles.pythonhosted.org - Google's
deps.devand the OSV vulnerability database,osv.dev - Vulnerability feeds (NVD, EPSS and similar) are downloaded or queried by advisory. They receive advisory identifiers, not package lists.
Private package names. Names you list under Private packages in your policy (an npm scope or name, a Go module path or host) are not sent to any of the services above, as long as your lockfile resolves them from somewhere other than the public registry. A private Go module is not analysed at all; a private npm package is downloaded from the registry your lockfile names and analysed from there. A package you have not listed is looked up by its name like any other, even if it comes from a private registry, so list your own names before you scan them. A listed name that your lockfile resolved from the public registry is treated as public and looked up, and the scan blocks it, because that is how a dependency-confusion attack looks.
How long data is kept
There is no automatic deletion yet for accounts, projects, scans, submitted dependency lists, findings, install records or the activity log. They are kept until you ask for them to be deleted. Deleting a project in the dashboard removes the project and its policy, but its scans remain in the account, unlinked from it. Closing an organisation in the dashboard removes its members, API keys, invitations and alert destinations at once; its scan and credit records are kept, because the credit ledger is an accounting record, and are deleted on request like any other account's.
These are deleted automatically:
- sign-in links, 7 days after they expire (a link expires 15 minutes after it is sent);
- sessions, 30 days after they expire;
- live scan progress events after 7 days, and completed background jobs after 14 days;
- sign-in rate-limit counters after a day;
- a waitlist entry, as soon as its address has an account. To be taken off the waitlist before then, write to the address below.
Server logs are rotated by size, so older entries are overwritten. Nightly database backups are rotated too, so deleted data can remain in a backup for up to 14 days after it is deleted.
Invitations that were not accepted are kept with the account's records. To have one removed, the invited person can write to the address below. To delete your account and its data, write to me@caioricciuti.com from the address you sign in with. Account deletion is not self-service yet.
Your rights
Under the GDPR you can ask for access to your personal data, and for it to be corrected, deleted or handed over in a portable form. You can also ask for its processing to be restricted, and object to processing based on legitimate interest. Write to me@caioricciuti.com. You will get an answer within one month.
You can also complain to the Spanish data protection authority, the Agencia Española de Protección de Datos, at aepd.es, or to the authority where you live.
PkgFire is a tool for software developers and is not directed at children.
If this notice changes, the date at the top changes with it.