Comment by sitkack | Hacker News Reader

Comment by sitkack | Hacker News Reader

I love this idea.

This is mostly just raw data, it isn't that useful (yet).

The security issues with using curl directly to my terminal feel a bit dangerous. I'd rather use my browser and be able to see the results over a json tree. Providing raw access to ES has a high risk to reward.

The search results for https://dontbeevil.rip/search?q=python%20context%20manager%2... are non-topical hits on SO records. I even put the name of the python package (from stdlib no less) in the query string.

I was able to find what I needed on devdocs.io in less than 10 seconds.

https://devdocs.io/python~3.10/library/contextlib#contextlib...

In no way am I trying to discourage you, but until the basics are in place, search over arxiv abstracts is way less useful than just SO and docs (language and libraries).

I would recommend returning text/plain by default and .json if someone asks for it (in the url), no everyone can set headers. I'd also put an about page at the root of your site, plain text is fine.

Thanks for the feedback. I'm considering making searching for language docs a special use case, maybe even with its own index.

> Providing raw access to ES has a high risk to reward.

I'm not quite that foolhardy :). The only thing that gets passed to ES is a sanitized simple_query_string.query. Should be relatively safe. I'm sure someone will prove me wrong though.

All this curl script does is print strings in the terminal. Are you saying that printing strings is dangerous? I think you may be confusing it with executing the output of curl which is not what this script is doing.

Escape codes could be leveraged to RCE the terminal. That said, every CLI you install on your computer can do code execution and could potentially couple that with remote instructions. There's two vectors there, in one where you don't trust the server and another where you don't trust the connection between the client and the server.

> one where you don't trust the server

And you can't trust the server here because its publishing 3rd party content in the way of search results.

The risk reward ratio of mentioned above is to far in the risk for my liking

Which escape codes?

What security implications does running curl have that wouldn't be present in a browser?

I’m wondering the same. You’re not piping them into a shell.

There have been instances of terminal vulnerabilities via terminal escape codes, as bad as an RCE in iterm2: https://blog.mozilla.org/security/2019/10/09/iterm2-critical.... I suppose the OP is thinking of something like that.

Yea, I was wondering about that; but the risk feels similar to a browser RCE to me. Maybe it's higher because browsers are more widely used/analyzed; but then again, a browser RCE has a much wider range of targets with more opportunities to exploit

Even just having the potential for the terminal to interpret escape codes is frustrating. Always pipe remote output to `less` or `less -R` (not `less -r`).

And this is exactly why I’m always playing the damp squid when people advocate for more features being supported via shell escape codes.

> The security issues with using curl directly to my terminal feel a bit dangerous.

What?

Then don't use a privileged terminal to run curl.

I don't think that's a satisfactory mitigation. For example, there is a terminal escape code to change the title of your terminal. Your windowing system, which is very privileged, then displays that.

I think it's fine to be paranoid here, the attack surface is massive.

Reply on news.ycombinator.com