Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security.txt

securitytxt.org

Post reply on HN
Print view View original

71–80 of 148 posts

Re: Security.txt

#71

Post by IncRnd »

hw wrote: post #54
IncRnd wrote: post #37

This site is horribly complex for creating a plain-text file with four fields . Perhaps, the complexity comes from having 10 contributors . _Not everything needs to be a large project._ A template right on the webpage would have the same value. That raises the point that a blog post about the RFC would have greater utility.

There are people out there who spend the time and effort to create a good looking site, even for something as simple as generating a plain text file with 4 fields. Your comment would have greater utility if it was actually about the subject of the site itself, and not about how it was designed.

That's a fair point.

In practicality, I don't see a need for this .txt file to be present. There are other .txt files, such as humans.txt, that don't have widespread adoption, due to lack of generated value.

While there are many issues inherent in reporting vulnerabilities, this .txt file will not solve them. Not only is the file's existence error-prone from a maintenance perspective, but my experience has shown me that such a file is not needed.

Due to these factors, I believe that the existence of such a file is unwarranted complexity without a corresponding level of benefit.

Re: Security.txt

#72

Post by gerdesj »

Spivak wrote: post #63
gerdesj wrote: post #59

Earlier quoted context omitted.

There's also Netscape's (?) email autodiscover mechanism with a .xml file served from there that describes how to do POP/IMAP/SMTP etc. However, despite /.wellknown/ being a bit of a standard, you'd be amazed at how many mechanisms you have to support to get autodiscover to work for all email clients. As it turns out SRV DNS records are also a bit of a standard for publishing pointers to services, and TXT records, an…

SRV records are extremely popular outside of the web. I really wish they would get more adoption. It's such a clean solution. We could have avoided the entire need for SNI if browsers supported service records.

I love SRV records but they are really just TXT with an API! PTR is A in a weirdly named domain ...

SNI avoidance is a weird one and you are probably right but SNI is only important (hah!) if you consider that we should all be using IPv6 by now and have billions of address per host to play with 8)

The rest of the world gets uptight about TLDs but there is one - relating to ENUM - that no one seems to mention and get upset about. If they did, instead of crapping on about whether Brazil or a US company owned "amazon" for example, then I'll give you (nearly) free telephone calls and a load of big Telcos will implode. Except they wont and the world will move on to the next logical step where all internet connections are no longer considered a sub-function of a telephone connection and the notion of a "leased line" is an anomaly.

Whoops, got carried away there. As you say - SRV should get more love.

Re: Security.txt

#73

Post by theandrewbailey »

jacquesm wrote: post #56

https://securitytxt.org/.well-known/security.txt Gives a 404 but https://securitytxt.org/security.txt Has the file... maybe they should either follow their own advice or update the text of the advisory? Like this it appears a bit inconsistent.

Seems to be fixed?

Re: Security.txt

#74

Post by subcosmos »

disconnected wrote: post #70

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.

Re: Security.txt

#75

Post by raimue »

jacquesm wrote: post #65
TheSwordsman wrote: post #58

Earlier quoted context omitted.

Per the Draft RFC `security.txt` is meant to be akin to `robots.txt`, in that it's at the root of the path. So yeah, it's a bit inconsistent.

That is going to cause some problems with a very large percentage of webservers being configured to never allow the fetching of any dotfiles to avoid accidentally exposing stuff that wasn't meant to be in the web tree in the first place.

/.well-known/ is defined in RFC5785 and paths under this prefix can be registered with IETF. For example, /.well-known/acme-challenge/ is used by ACME, the domain verification protocol used by Let's Encrypt.

https://www.ietf.org/rfc/rfc5785.txt

It should not be too hard to make an exception for this path in your web server configuration. Also note that URLs do not have to match the local filesystem, so you could as well use an alias to a different local path.

Re: Security.txt

#76

Post by skybrian »

mjw1007 wrote: 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?

Re: Security.txt

#77

Post by jacquesm »

theandrewbailey wrote: post #73
jacquesm wrote: post #56

https://securitytxt.org/.well-known/security.txt Gives a 404 but https://securitytxt.org/security.txt Has the file... maybe they should either follow their own advice or update the text of the advisory? Like this it appears a bit inconsistent.

Seems to be fixed?

It is now present at both urls... well, at least it is there :)

Re: Security.txt

#78

Post by manigandham »

libeclipse wrote: post #19
fbnlsr wrote: post #11

I think humans.txt ( http://humanstxt.org/ ) fits more, and already exists.

> It's an initiative for knowing the people behind a website. It's a TXT file that contains information about the different people who have contributed to building the website. Not sure why you linked that, it doesn't fit at all. They're solving completely different problems.

Neither are solving any actual problems.

Re: Security.txt

#79

Post by hitekker »

This entire page reads as a stream of consciousness.

This one line is particularly egregious:

"Security.txt defines a standard to help organizations define the process for security researchers to securely disclose security vulnerabilities."

> Defines a X to help Y define a Z for Q to W.

> Securely close security vulnerabilities.

Ick.

Re: Security.txt

#80

Post by manigandham »

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.
Post reply on HN