Security.txt

I'd never enter in a paid interaction without some sort of escrow that will make sure I'm not screwed over for the crime of being a good citizen. The victim could just keep the cost of the report without ever refunding. Innocent people will keep getting caught by this even long after the company acquires a reputation for never providing refunds.

It’s a good platform, but it really doesn’t solve the time-sink problem, even if you pay for triage services. Triage can knock down well-known patterns of bogus stuff, but so can you; the real problem is the truly wacky stuff people come up with.

I just use GNUPG and encrypt it.

What does it mean when I enabled this on my personal (for fun) websites years ago on a whim? I don't have a bug bounty program.

Putting all of these files at root is going to be like have old rusty cars and stained mattresses in front of your house years from now.

The web is not a junkyard.

Their own security.txt also fails to do this

https://securitytxt.org/.well-known/security.txt

> # If you would like to report a security issue

> # you may report it to us on HackerOne.

> Contact: https://hackerone.com/ed

> Encryption: https://keybase.pub/edoverflow/pgp_key.asc

> Acknowledgements: https://hackerone.com/ed/thanks

In fact I think requiring an expiry date is a huge negative of the spec and will likely hinder adoption.

An expiry date brings along with it yet another maintenance burden for questionable benefit.

I was literally going to craft a file and plop it on my site until I hit the "required expiration". I understand why it is there but think it should be optional. I think a better idea would be to steal from DNS and use TTL and serial numbers (maybe just standard http last-modified is enough?) - the point is "this stuff might be stale, reprocess it".

The last thing I need is one more thing to have to remember and update.

By the looks of it, a few others feel it is non-critical and have just skipped it too.

Expires was optional until draft 10 (August 2020)

Serving a 'text file' from a web server module seems to overcomplicate things in my view.

More code || complexity == greater likelihood of bugs (including security bugs).

As ironic as a security bug in a security.txt serving module would be, it's probably best we avoid that possibility and let the ordinary, highly scrutinised file serving code handle it instead.

I think the text file generation is great - it is a standardized "syntax", so being able to just fill out your info in a webpage and getting the .txt to upload to a server (instead of having to "learn" the couple of keys to use for your values) really does make it painless.

That would make things much easier especially to have the expiration date automatically update. But also to set a default for all sites on a server.

It would also be nice to have libraries for the popular frameworks

A lot of people have web hosting packages that don't give them direct access to the webserver configuration, but do let them upload arbitrary text files to their webroot.

Yeah, worst part is when some support engineer asks you to please post the bug to a bug tracker, but the bug tracker requires an account, and when you try to sign up they make you wait for someone to review your account, and at some point you wonder if these people ever get a single bug report from a customer.

You're right, that would work.

Though the UX designer in me thinks that if the policy is important, it would be better to put in up on a webpage and slap that into the ‘contact’ field—as a neighbor comment suggests. At least when the whole process turns out to sidestep email completely.

Ah! Indeed, I missed that alternative.

It's likely some kind of caching issue. tools.ietf.org at 4.31.198.62 responds with the draft, but 64.170.98.42 404s

This one works for me:

https://datatracker.ietf.org/doc/html/draft-foudil-securityt...

It did that for me at first, but it was due to my impatience.

I tried again and waited, and after 10 or 15 seconds, the page finally loaded.

Same here, but the it started working once I opened Developer Tools and refreshed the page.

Right, which is why putting this file under .well-known is a small inconvenience.

It's increasingly common for server configurations to have a reverse proxy routing requests to internal containers or servers. Things like SSL renewals are often handled by the reverse proxy (because reasons [1]), so those requests don't get routed to the internal hosts by default.

Site-specific stuff, like this file, probably belongs in the site's root directory.

This is a bit bike-shedding though. It's only a small aggravation to work around.

[1]: Because you want to automate as much of the configuration as possible, so when a new hostname is added to a container or internal server, an SSL certificate just magically happens for it. This requires changes to the reverse proxy's configuration, and that's not something you want the internal containers doing, so it falls to the proxy to handle these itself. Letting the containers handle their own SSL setup means you have to have some kind of privileged communications channel from the container up to the reverse proxy, which is undesirable.

My point exactly - validation usually involves write permissions to put a challenge or something else as required by the protocol (ACME in your example). If I put the security.txt file there and certbot gets compromised, there goes my security policy. Putting security.txt up one level so only root (I.e. me) can update it allows me to keep .well-known writable by robots only.