[teh]

Super useful tool but need to be aware that this is reading potentially untrusted input (e.g. in the case of http request logs) and written in c++, so a possible attack vector. I use lnav where I trust the logs, but do wish a safe implementation existed.

[fireflash38]

Memory safety doesn't mean it's safe. And C++ doesn't mean it's unsafe.

Browsers are in C++, do you not use them? Curl is in C, do you not use it? Kernel is C...

[tobias12345]

"Memory safe" means that there are no memory safety issues. One of the most critical areas targeted by exploits is just gone. And this in turn leads -- according to the numbers published by Google -- to a severe reduction of exploitable issues.

C++ means you can not know whether code is safe or not. That does not mean it is unsafe, but assuming it is is the only sane way to handle this. Incidentally this is exactly what browsers do: They typically require two out of these three to be true for any new piece of code: "written in a memory-safe languge", "sandboxed" and "no untrusted inputs". This blocks C++ from some areas in a browser completely.

[teh]

Chrome uses sandboxing and a lot of safe tooling (wuffs, rust) for untrusted data.

curl is heavily fuzzed and you still mostly control what you are downloading unless the target is compromised.

With logs the attacker controls what goes into your logs.

And you don't need to really look very hard, there are a fair number of very recent stack and heap overflows: https://github.com/tstack/lnav/issues?q=is%3Aissue%20heap%20...