The “security.txt” proposal reached last step in the IETF process

Re:The “security.txt” proposal reached last step in the IETF... by wahern on Wednesday December 11, 2019 @05:25PM (#21767434)

You can still easily blow up memory with unions, which makes it easy to lock up Linux, which notoriously performs poorly under memory pressure.

[ Parent | on HN ]

Re:The “security.txt” proposal reached last step in the IETF... by lilyball on Wednesday December 11, 2019 @05:45PM (#21767606)

A non-backtracking regex engine like re2 should be linear with respect to the regex size and can be configured with a memory budget.

[ Parent | on HN ]

Re:The “security.txt” proposal reached last step in the IETF... by wahern on Wednesday December 11, 2019 @06:01PM (#21767708)

The number of DFA states can explode exponentially. It's a real problem, especially if you're compiling untrusted expressions off the internet.

Evaluation is linear, but you're just evaluating your own password. In this scenario, it may make sense to just use a simple backtracking implementation, though as you alluded to early there aren't many simple ones around.

[ Parent | on HN ]

Re:The “security.txt” proposal reached last step in the IETF... by pjscott on Thursday December 12, 2019 @01:19AM (#21769687)

RE2, at least, will fall back to an NFA-based matcher if things get too pathological.

[ Parent | on HN ]

Re:The “security.txt” proposal reached last step in the IETF... by saagarjha on Wednesday December 11, 2019 @05:41PM (#21767568)

Just set a memory limit on the process.

[ Parent | on HN ]