Security

How to report a security problem in any phpboyscout project, what happens to your report, and how to verify a signed release.

Everything here is public and I maintain it on my own. That shapes what this page can sensibly promise. There is no security team behind it, no rota, and no bounty. What there is, is a private route to me that costs you nothing to use, and a reply from a person who read what you sent.

Reporting something

Email [email protected].

That address opens a confidential ticket in a private tracker. Nobody else can see it, and the address you write from is kept so I can reply to you directly by email. You do not need an account anywhere, and you do not need to work out which of the hundred-odd repositories is affected. Tell me what you found and I will route it.

Please don’t open a public issue for a security problem. A public issue is visible to everyone the moment you file it, including whoever would use it.

If you have them, these help:

  • what the problem is, and what it gets an attacker
  • which project, and which version or commit
  • how to reproduce it
  • anything you already ruled out

What happens next

I aim to acknowledge within five working days. Realistically most things are quicker than that, but I would rather set a number I can keep on a bad week than one that looks good on a page.

After that: I will tell you whether I can reproduce it, what I think the severity is, and what I intend to do. If I disagree with your assessment I will say so and explain why, rather than going quiet. If it turns out to be a real problem, I will credit you when it is fixed unless you would rather I didn’t.

What is in scope

Anything under gitlab.com/phpboyscout, the published container images, the CI/CD components, the OpenTofu modules, and this site.

Not all of it is finished, and each repository’s description tells you which is which. Where a description says spike, or spec-gated, or not yet built, that is exactly what it is: something being worked through in the open rather than something anyone should be running. I would still like to know if it is dangerous, but treat a missing safeguard there as expected rather than as a finding.

One thing that is not worth your time: a dependency with a published CVE and an upstream fix already available. Renovate is watching those and will raise the bump before either of us gets to it.

What I’d rather you didn’t send

There is no bounty, and that is on purpose. When curl closed its programme I wrote about why the cash prize was the accelerant rather than the AI that produced the reports. The expensive half of a vulnerability report has always been verification, and nothing has made that half cheaper.

Which means a report nobody has checked costs me as much to disprove as a real one costs to fix. If you have not actually reproduced it, saying so plainly is far more useful than sounding certain. “Static analysis flagged this and I could not trigger it” is a fine thing to send. The same text with the hedge removed is not.

Verifying a release

Release artefacts are signed, and the verifying keys are published over WKD, so gpg can fetch one by address without you trusting a keyserver:

gpg --locate-keys [email protected]

ffmpeg-wasi signs with its own key, at [email protected].

If you would rather not hand-roll the check, sigillum is the tool I built for exactly this, and it does not care what language the project you are verifying was written in.

Built with Hugo · Theme Stack designed by Jimmy