Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow already created files to be served by us #62

Open
joker314 opened this issue May 11, 2019 · 3 comments
Open

Allow already created files to be served by us #62

joker314 opened this issue May 11, 2019 · 3 comments

Comments

@joker314
Copy link
Collaborator

We could add a validator which will take an existing security.txt file (which may or may not be signed), validate it, and host it at both the well-known path and the root.

Thoughts?

It solves the issue of not giving our library the private key.

@lirantal
Copy link
Owner

Can you fill me in on what's the context of the private key that need to be provided to our lib? I think I'm missing a feature of a signed security.txt file.

@joker314
Copy link
Collaborator Author

Currently, our library generates the security.txt file based on an object representing it. Previously, there used to be a "Signature" directive which was a URI to an external signature file: I'm not sure exactly what the format of it was, but it allowed the signing process to be external to our library since the user was responsible for creating a signature file. The purpose of signing the security.txt file is that if an attacker somehow manages to take control of the security.txt file, security researchers will not trust the file at all and pretend it doesn't exist, so as to make sure vulnerabilities aren't reported to attackers, etc.

In more recent versions, signatures have to be inline. Yet if we are generating the security.txt file like we are now, then if someone wants to sign the security.txt file and we are generating the files on the spot, then we need the private key to do the signing.

To get around this, I propose that if someone does want to sign their security.txt file, they can do that themselves (keeping the private key needed for signing far away from the security.txt host) and then feed the signed file to us.

Our library already validates the security.txt objects fed to it and we can do that for these static signed files too. Our library will also be responsible for hosting the file in two locations: /security.txt and /.well-known/security.txt. The only part that our library won't be doing is generating the signed file, because I think that would have security-related problems.

@lirantal
Copy link
Owner

Thanks for the elaborate explanation @joker314 👌

Completely agree. So we would actually receive the input for the file to display rather than generate on the fly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants