[Security] security.txt points at a different address than SECURITY.md #597
Labels
No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
LibreKAT/Ocideck#597
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found in the pre-publication security review.
Evidence:
curl https://librekat.nl/.well-known/security.txtreturnsContact: mailto:stichting@librekat.nl,Policy: https://librekat.nl/nl/contact/,Expires: 2027-07-15.SECURITY.md:20sends reporters to security@librekat.nl instead. There is noEncryption:field and no reference to this project SECURITY.md. The MX record exists (10 purrser.protectivecat.eu., SPFv=spf1 mx -all); whethersecurity@is actually delivered could not be established without sending a test message — unconfirmed.Why this matters now: a researcher following the standard route (RFC 9116) arrives at a different address than the repository prescribes, and nowhere is it stated that these are the same mailbox. For a time-critical report that is exactly the turning where a disclosure sits unread. The first impression is that publisher and project are not aligned.
Proposal: put
Contact: mailto:security@librekat.nlas the first line in security.txt (a secondContact:is allowed), and addPolicy:pointing at this project SECURITY.md. Send one test message tosecurity@to confirm delivery before publication.Filed for you rather than fixed by me:
security.txtlives onlibrekat.nl, not in this repository. There is no.well-known/here to change, so this one needs a hand on the website.What I can confirm from here, and what I cannot:
SECURITY.mdsends reporters tosecurity@librekat.nl, and every other reference in the repository now agrees with it —security-insights.yml,COMPLIANCE.md, and as of #654 the CHANGELOG entry that quoted the deadsecurity@vigilis.nlnow says outright that the address is not in use. A grep no longer turns up two live-looking addresses.security@is actually delivered. Establishing that needs a test message, and sending mail is not mine to do. Your issue already flags this as unconfirmed; it stays unconfirmed.The two changes on the website side, per your own proposal: add
Contact: mailto:security@librekat.nlas the first line (a secondContact:is allowed under RFC 9116), and aPolicy:pointing at this project'sSECURITY.md.Worth doing before publication rather than after: a researcher following the standard route arrives at a different address than the repository prescribes, and that is exactly the turning where a time-critical report sits unread.
Half done in #661; the other half is a website change I cannot reach.
Confirmed: delivery to
security@librekat.nlwas tested by the publisher on 2026-07-22. Your issue listed that as unconfirmed; it no longer is, andSECURITY.mdsays so with the date.Built: the web build now serves its own
/.well-known/security.txt. Everything underweb/is copied tobuild/web/, so wherever this app is hosted the standard discovery route answers — and points at the same mailbox this repository prescribes. That is the origin someone using the web version looks at first.The two files do not compete: the one on the site covers the foundation, this one covers this application.
It has a gate, because this is a file that rots quietly and nobody visits on purpose: the reporting address must match
SECURITY.md, the mandatory RFC 9116 fields must be present, the file must not be expired, andExpiresmay not sit more than a year out — that last one is postponing the check rather than doing it. An expired file fails the build on purpose; it reads as "nobody is home" at exactly the wrong moment, and the fix is one line.Still open, and yours:
librekat.nl/.well-known/security.txtnamesstichting@librekat.nland carries noPolicy. Per your own proposal: putContact: mailto:security@librekat.nlfirst (a secondContact:is allowed under RFC 9116), and addPolicy:pointing at this project'sSECURITY.md.Leaving this open for that.