Live data from Hacker News

Security.txt

securitytxt.org

81–90 of 148 posts

Re: Security.txt

#81

This is just "feel-good" bullshit that doesn't actually solve any real problem. In my life, I have only reported two different vulnerabilities to two different vendors. One of them didn't care at all. They were transmitting usernames and passwords in plaintext and I actually showed one of their engineers this, live, in person, and he just shrugged. The other one told me something to the effect of "yes, this is very s…

>In my life, I have only reported two different vulnerabilities to two different vendors. Interesting. I don't think this is for you. Ever have the task of needing to report a security issue to 10k sites and wish you could have any hope of automating it? I certainly haven't. More like 100k! Don't be so negative when people try to do good.

You needed to contact 100k sites about security? Do you have more details on this?

The example security.txt for this site currently has a twitter handle as the contact. How are you going to automate that?

Re: Security.txt

#82
Maybe if you contacted the liability lawyers first, they would have the power to force the fix. Maybe if there was a standard security.txt file that would cc the lawyers on all reports, the lawyers would force the standard to be used, and thus your biggest hurdle is solved.

your post was "feel-bad" bullshit that was much worse.

you're all idiots.

Re: Security.txt

#84
post #21

If you have a disclosure policy, chances are googling "company name + disclosure" will bring it up. Don't really see benefits of standardising this, not going to help any companies that previously had no disclosure policies decide to implement one and "discoverability of existing disclosure policies" doesn't really seem like a big issue.

The more you use a Google feature as a crutch, the less the web is semantic. Also, Google has increasingly made it difficult to automate searches, so the effort required to notify multiple websites increases quickly.

> ... the less the web is semantic.

Yes, predating this and .well-known, the principle exists as https://en.wikipedia.org/wiki/Semantic_URL

There was a website way back in the 90s which encouraged a standardisation of paths such as /about, /products, /services etc.

Re: Security.txt

#85
post #9

Should surely be .well-known/security.txt, or if not explain why not. rfc5785 "Defining Well-Known Uniform Resource Identifiers (URIs)" [edit: I see the FAQ says that, while the linked Internet Draft says it goes at top-level like robots.txt]

A bit off-topic, but I don't understand the popularity of hidden directories for what should be human-visible files. Why be intentionally obscure rather than discoverable?

To avoid namespace collisions. It's not discoverable in any case because no one has a directory listing as their homepage.

Re: Security.txt

#86

This is completely useless. Any company that cares about security enough to do this will already have security@, support@, abuse@ emails setup. Those are the well known contact endpoints. Bug bounty platforms also have contact info and messaging built-in.

what RFC describes that standard?

Re: Security.txt

#87

Earlier quoted context omitted.

>In my life, I have only reported two different vulnerabilities to two different vendors. Interesting. I don't think this is for you. Ever have the task of needing to report a security issue to 10k sites and wish you could have any hope of automating it? I certainly haven't. More like 100k! Don't be so negative when people try to do good.

You needed to contact 100k sites about security? Do you have more details on this? The example security.txt for this site currently has a twitter handle as the contact. How are you going to automate that?

One may want to notify many website owners at once that it’s a good time to apply a patch in response to a security vulnerability affecting a technology they are using. Ex: WordPress, node.js, MongoDB, etc.

Re: Security.txt

#88

This is completely useless. Any company that cares about security enough to do this will already have security@, support@, abuse@ emails setup. Those are the well known contact endpoints. Bug bounty platforms also have contact info and messaging built-in.

what RFC describes that standard?

Well, common sense for one, but also https://www.ietf.org/rfc/rfc2142.txt section 4!

Re: Security.txt

#89

This is completely useless. Any company that cares about security enough to do this will already have security@, support@, abuse@ emails setup. Those are the well known contact endpoints. Bug bounty platforms also have contact info and messaging built-in.

what RFC describes that standard?

cf. RFC2142

Re: Security.txt

#90

A bit sad that it does not allow for the file to be signed with OpenPGP.

What precludes you from including a comment with a link to the signed version of the file with ".asc" appended to the filename?
Post reply on HN