Ironvale Foundation

Program overview

Hello. We are thirteen volunteers and two grant-funded part-timers looking after three pieces of software that far too many people depend on: ironvale-tls, a TLS implementation; ivpkg, a package manager; and Anvil, a build tool. They ship inside operating system base images, phone firmware and a long list of places nobody has ever told us about.

The part everyone asks first, answered first: there is no money. We have never paid for a report and we are not about to start. The foundation lives on roughly 190,000 USD a year in grants and small donations, which covers infrastructure, two part-time salaries and the annual accounts. A bounty line would empty that in a quarter.

What you get instead is a fast and completely public process. We have been a CVE Numbering Authority since September 2024, so the identifier is assigned by us, usually within a working day. Your name goes in the advisory, the release notes and the commit trailer, spelled the way you ask. You go on the hall of fame permanently. Stickers and a shirt go in the post. For a Critical finding there is a travel grant, which has sent four people to a conference so far.

If that is not worth your weekend we understand, and we would rather you knew now than after a fortnight of fuzzing.

Testing rules and expectations

Nearly everything here is source code, so nearly everything happens on your own machine. Clone it, build it, fuzz it, take it apart. You need no permission from us and there is nothing we could revoke.

The exceptions are the three hosted systems: the forge, the registry and the release pipeline. Those are real servers with real state, so tread lightly. Use your own account. Publish test packages under a name beginning zz-test- and delete them when you are finished. Do not push into a namespace that is not yours, even to prove that you can; if you find a way to publish under somebody else's name, screenshot the furthest state you reached and stop there. No load testing. The registry runs on three modest machines and our uptime is a point of pride.

We would rather have a rough report on Tuesday than a polished one next month. A crashing input and a stack trace is a complete report. You owe us no patch, and if you send one anyway we credit you twice.

Proving write access

If you find a way to write, do not prove it by causing damage. Prove it with the smallest change that can be attributed to you and undone in the same minute.

• One or two punctuation characters. Delete a full stop, add a comma. Nothing longer, nothing visible, no payload, no changed number or amount.
• Only on a record you created yourself. Never another user's record, never site content, never anything the public can see.
• Revert within sixty seconds, in the same run, without being asked.
• Capture four states: before, after the change, after the revert, and an independent re-read confirming the revert held.
• If it cannot be reverted, do not change it. Report the write primitive and stop. A row count and a column list already prove database access.

Every request must carry headers that let us separate your traffic from a real attack in our logs:

X-Bug-Bounty:        ironvale
X-Research-Account:  <the account you submit the report under>
X-Authorisation-Ref: <engagement or report reference>
X-Request-Id:        <unique per request>
User-Agent:          sentinel-research/<handle> (+<this page>)

scripts/proof_of_write.py performs exactly this sequence, refuses any host outside the scope above, refuses a diff longer than two characters, always attempts the revert, and writes a timestamped evidence file. Run it without --execute first, then attach the evidence to your report.

Safe harbour

You may analyse, reverse engineer, fuzz, decompile and generally dismantle anything we publish, for any reason, for as long as you like. Our licences already allow most of that and this policy confirms the rest.

For the hosted services: stay inside the rules above, tell us what you found, and give us the chance to ship a fix before the world hears about it. Do that and we will never bring a claim. We are a small association with no legal department and no wish to build one. What ends the protection is short and obvious: destroying or taking other people's data, tampering with published artifacts, asking us for money to stay quiet, or handing a working exploit to somebody who plans to use it.

Reward decisions

There is no money to decide about. Severity still matters, because it sets how fast we move and how loudly we tell everyone.

We score with CVSS v3.1 and we argue about it in the open, in the advisory thread, where you can push back. Reachability in a default build counts for more than the vector string. A heap overflow in certificate parsing that any peer can trigger is Critical. The same bug behind a build flag that a dozen known deployments enable is High, and we will say so rather than quietly inflate it.

Duplicates go by the timestamp on the security mailbox. When two arrive in the same week, which happens more often than you would expect, both names go in the advisory.

Disclosure policy

Ninety days from the day we acknowledge your report, or the day the fix ships, whichever arrives first. We have asked for a second extension once in eight years, and we explained what was blocking the fix when we did.

The sequence: acknowledge, reproduce, patch against the maintenance branches, assign the CVE ourselves, notify the distributor pre-notification list under a seven-day embargo, publish the advisory and the signed release together, push the commits to the public tree.

The embargo exists so packagers can build and stage updates. It does not exist so we can manage the story, and when it breaks we do not pretend otherwise. In October 2025 details of a pending advisory turned up on a public list four days early; we published the advisory and the fix three hours later and removed one member from the list. That is the rule, written down before it was needed and followed when it was.

Write up your own findings once the advisory is out and we will link to it. Not before, please, and redact any credential you stumbled across on the hosted services.

Report quality

• The exact commit hash or release tag, with the target triple and compiler version you built with.
• The reproducing input attached as a file rather than pasted as hex.
• A sanitiser trace if you have one. Address, memory and undefined behaviour sanitisers are all welcome.
• Where untrusted data enters and which function it reaches, a sentence each.
• Whether the path is reachable in a default build, and if not, which flag opens it.
• The name you want credited, spelled the way you want it.
• Whether you plan to write it up publicly, so we can plan around your timeline.