Live data from Hacker News

Security.txt

securitytxt.org

51–60 of 148 posts

Re: Security.txt

#51

Earlier quoted context omitted.

I've never heard of this. I wonder how many websites implement this. I tried a bunch of sites, but the only one I could find that had a humans.txt file was google: Google is built by a large team of engineers, designers, researchers, robots, and others in many different sites across the globe. It is updated continuously, and built with more tools and technologies than we can shake a stick at. If you'd like to help us…

I do! https://redfern.me/humans.txt It should really be human.txt...

A redirect to LinkedIn definitely isn't a proper implementation.

Re: Security.txt

#52

Nice idea, but a little inconsistent. Even their own site doesn't comply with their own RFC.

Yeah, the RFC seems very vague too.

I could see some value in meta-data for automated reporting of security issues.

But the spec would have to be less informal.

Re: Security.txt

#53
post #51

Earlier quoted context omitted.

I do! https://redfern.me/humans.txt It should really be human.txt...

A redirect to LinkedIn definitely isn't a proper implementation.

I agree. It was meant to be a bit... cheeky. Honest question though, is your issue with the fact that LinkedIn isn't plain-text, or the nature of the information that LinkedIn provides?

Re: Security.txt

#54
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.

Re: Security.txt

#55
post #28

I can't seem to find a definition of "Partial disclosure" on either the website or the IETF RFC draft.

Yeah, I was looking for the same. All the draft [1] says is: 2.5. Disclosure: Specify your disclosure policy. This directive MUST be a disclosure type. The "Full" value stands for full disclosure, "Partial" for partial disclosure and "None" means you do not want to disclose reports after the issue has been resolved. The presence of a disclosure field is NOT permission to disclose vulnerabilities and explicit permissi…

Explicit permission must be saught (sic)? How does that work?

Re: Security.txt

#57
Should have a section for which software license the website code is under

Also for any runtime JavaScripts

And should alsonspecofy how private data is stored

And how private data is collected, processed and for how long it is retained

Re: Security.txt

#58

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.

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.

Re: Security.txt

#59
post #43
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]

Ahhh. That explains why lets encrypt does it!

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, and RANDOMLY_NAMED_RECORDS because updating your server n resolver to support another record type is such fun.

I actually think we are almost there now: DNS to find it and /.wellknown/ to describe it.

Re: Security.txt

#60

....because security teams have great working relationships with all the the owners of all the content platforms in an org... Just make an abuse@ or security@ catch-all for your mail server and point all your domains' MX there. If you're worried about spam, build in a bounce-back that asks for a signed email to make it past the bounce. Security researchers can figure that out.

> If you're worried about spam, build in a bounce-back This is really bad advice. Always disable spam filtering outright on abuse@ and postmaster@, never filter them, never bounce anything . Read every one. I'm not saying hook those mailboxes up to automatically make a JIRA case on each inbound -- there is screening to be done. However, the idea of abuse@ is that spam is often forwarded directly to it if it's origina…

So much this.

I recently ran a port scan of a subset of the internet on a single port. (To get an estimate how many servers with a certain old protocol version were still running, as I wanted to drop it from a client I was working on)

I previously messaged the contact email given by the AS of every affected subnet.

I got over 4 weeks not a single complaint or request to be excluded.

Then I did the scan, and got tons of complaints – and once I pointed out the email I sent them, most got very quiet, but one continued to complain and tell me I should have tried harder to contact them.

Post reply on HN