Linter / validator for RFC compliance and basic error checks?

[anroots]

I am currently adding security.txt to sites. It would be useful for me to have some sort of linter / validator utility, something like

$ security-txt validate sqroot.eu
Checking HTTP /security.txt redirect to /.well-known/security.txt... [ok]
Checking /.well-known/security.txt syntax compliance to the RFC... [ok]
Checking if linked Policy document URI resolves to HTTP 200... [ok]
Checking if Signature matches security.txt file hash... [failed]: security.txt signature does not match

Found 1 errors, 0 warnings.

...which would help me determine if I (and others whom I care about) have configured their servers correctly.

Would such an utility / service be useful to people? Any plans to provide it?

I realize this might be overkill. :) My use case is a bit unusual, as I'm trying to add security.txt from one frontend loadbalancer to all domains that sit behind it, including additional files, such as Signature and Policy document. A sort of "health-check" that could be automated would enable me to detect if something is misconfigured (a file is not served).

[andreasvirkus]

I'd like to take a crack at this, if that'd be OK. But I'd like to know some requirements up ahead, like what are the must haves (redir, linked files), what should be considered warnings and what should be counted as errors, etc?

Also would this be realised as a separate repo or under a directory of this one?

[anroots]

Most of the "requirements" could probably be gleamed from the RFC, as it is (SHOULD = warning, MUST = error). Also, differentiation of warnings and errors is a feature, the MVP would just be a bunch of scripts with tests. I literally started writing this as a sequential lines of curl commands in Bash.

I think a separate repo is best, because the tool is an add-on to the RFC. The repo could later be moved under the securitytxt org, if people agree that it is useful.

[austinheap]

A basic validator is available at https://securitytext.org/ but I fully agree with @anroots that we need a validator that's generated directly from the RFC's ABNF definition as to limit human interpretation of the spec.

@EdOverflow is the ABNF at a point where we give this a go?

[EdOverflow]

@austinheap, yes, I believe it should be doable using the latest Internet draft.

[eikendev]

I started working on sectxt to address a similar problem. Note that it will not give any guidance as to what exactly is invalid for a domain, but since the tool does parse the files, this feature could possibly be added in the future.

You can use the tool like so, where domains.txt is a file with newline-separated domains to be checked.

sectxt < domains.txt

I'm currently trying not to produce any false negatives, so some aspects of the specification are not strictly validated. Still, maybe this helps a bit.

[r4vi]

I have tried to generate a parser using the python abnf module and attempted to keep faithful to the ABNF definition in the RFC - however it's having trouble parsing the basic template. I'm not sure if it's an issue with the ABNF line rule or the module.

Would appreciate an extra pair of 👁️ on it.

Implementation: https://github.com/r4vi/security_txt_parser/blob/master/security_txt_parser/__init__.py

Running the following works:

node = Rule('line').parse_all("# Comment\n")

and returns the following parse tree

Node(
    name=line,
    children=[
        Node(
            name=comment,
            children=[
                Node(name=literal, offset=0, value="#"),
                Node(
                    name=WSP,
                    children=[
                        Node(
                            name=SP, children=[Node(name=literal, offset=1, value=" ")]
                        )
                    ],
                ),
                Node(name=VCHAR, children=[Node(name=literal, offset=2, value="C")]),
                Node(name=VCHAR, children=[Node(name=literal, offset=3, value="o")]),
                Node(name=VCHAR, children=[Node(name=literal, offset=4, value="m")]),
                Node(name=VCHAR, children=[Node(name=literal, offset=5, value="m")]),
                Node(name=VCHAR, children=[Node(name=literal, offset=6, value="e")]),
                Node(name=VCHAR, children=[Node(name=literal, offset=7, value="n")]),
                Node(name=VCHAR, children=[Node(name=literal, offset=8, value="t")]),
            ],
        ),
        Node(
            name=eol,
            children=[
                Node(name=LF, children=[Node(name=literal, offset=9, value="\n")])
            ],
        ),
    ],
)

which seems fine but when trying to parse a line which consists of a field it fails:

Rule('line').parse_all("Contact: mailto:[email protected]\r\n")

Traceback (most recent call last):
  File ./abnf/parser.py", line 350, in parse
    node, new_start = self.definition.parse(source, start)
  File "./abnf/parser.py", line 184, in _parse_value
    raise ParseError(self, start)
abnf.parser.ParseError: Literal('\x0a', case_sensitive): 31

[nightwatchcyber]

Not familiar with this library - can you provide more information about what character it is choking on?

[r4vi]

Not familiar with this library - can you provide more information about what character it is choking on?

It seems to be choking on the eol part in "line = [ (field / comment) ] eol".
I spent this morning hacking around with the grammar and I think it's related to the new line and the fact that the library doesn't support backtracking. see: declaresub/abnf#4

I will probably abandon this approach and write my own parser using pyparsing instead.

[declaresub]

abnf now supports backtracking, and includes an RFC 9116 grammar.

[r4vi]

@declaresub wow thank you for not only adding backtracking support but baking this RFC straight into your library!