Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BCHS: OpenBSD, C, httpd and SQLite web stack

learnbchs.org

Post reply on HN
Print view View original

121–130 of 158 posts

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#121

Post by adamrezich »

teleforce wrote: post #54

SQLite author is an avid Tcl user and he recently introduced a small, secure and modern CGI based web application called wapp [1],[2]. [1] Wapp - A Web-Application Framework for TCL: https://wapp.tcl.tk/home [2] EuroTcl2019: Wapp - A framework for web applications in Tcl (Richard Hipp): https://www.youtube.com/watch?v=nmgOlizq-Ms

this is very cool. I only have a passing familiarity with Tcl, but I've been building my own toy web framework and this is a fantastic reference! they made a lot of the same choices I made API-wise but the way they went about it is worth studying.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#122

Post by da39a3ee »

RTFM_PLEASE wrote: post #58
da39a3ee wrote: post #18

I’d like to love man pages but - I feel that they are linux only. On my MacOS system I can’t rely on man x being the man page for the right version of x. I know that in principle there are environment variables that make sure i’m getting the gnu core utils version or the base homebrew version rather than the system BSD version, but it’s too many moving parts. Furthermore even if I get it right, I can’t expect people…

OpenBSD pages ( https://man.openbsd.org/ ) absolutely rock and other, proper BSDs do quite well. Also, man pages are for more than just system utilities (man(1)). Which binary should hold pledge(2) ( https://man.openbsd.org/pledge ), exactly? Your man pages should be updated when the associated tool is updated. You are describing a MacOS issue, with its terrible package management, and frustrating toolchains.

You seem to be missing my point which is that, as a maintainer of a command line tool, I need to and want to cater to users of all OSs. And in fact, I will allocate my efforts more towards popular OSs. I genuinely am sure that your BSDs are a nice environment, but surely you understand how fringe they are? The majority of my users are MacOS+Windows, with substantial Linux also.

In fact MacOS has an excellent package manager -- it's called homebrew. I don't really want to argue about it but you're the one who made an unjustified assertion about an OS which I bet you don't use. People like you insist that it's bad but no-one who uses it knows why. I maintained my own Linux laptop for 10 years, and for the last 10 years I've used homebrew on a Mac. It has literally never given me any problems! I've never even searched the issues on Github for a problem as far as I can remember.

Honestly I think that the thought processes of most Linux/Unix enthusiasts like you who criticize homebrew are

1. We hate MacOS because childish anti-capitalist ideologies

2. Therefore we will not admit that a nice command-line development environment can be created on MacOS

3. Therefore homebrew is bad

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#123

Post by da39a3ee »

enriquto wrote: post #107
da39a3ee wrote: post #96

Earlier quoted context omitted.

Yes, it is. But MacOS (and Windows) are popular OSs for laptop users. I'm the maintainer of a command line tool that is reasonably popular and I believe that the majority of my users are MacOS. So the question is quite concrete for me -- should I provide documentation in the form of a man page? I do not currently, for the reasons I gave above (although I made a mistake in saying Linux when I meant Linux and *BSD for…

> should I provide documentation in the form of a man page? Yes, and this may be a much smaller effort than you suspect. Only by writing the output of --help in a certain order, you can use the "help2man" tool to generate a beautiful manpage automatically. Notice that your users do not need to have help2man installed, you run it yourself as part of your build process, to create the manpage from the latest source code…

It would be cool if help2man worked perfectly. In fact the output needs a few fixups -- it looks like it has problems with non-ASCII characters?

But if those fixups can be made automatically it's not bad and I agree might be worth adding to the build.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#124

Post by littlestymaar »

WesolyKubeczek wrote: post #70
_ofdw wrote: post #56

Earlier quoted context omitted.

If we'd just rewrite all of the things in Rust we could solve computer bugs forever, and world hunger too.

And end mortality!

The last time someone promised to free the Men from the gift of Ilúvatar, it did not go well for them. A good reason never to use Rust!

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#125

Post by enriquto »

da39a3ee wrote: post #123
enriquto wrote: post #107

Earlier quoted context omitted.

> should I provide documentation in the form of a man page? Yes, and this may be a much smaller effort than you suspect. Only by writing the output of --help in a certain order, you can use the "help2man" tool to generate a beautiful manpage automatically. Notice that your users do not need to have help2man installed, you run it yourself as part of your build process, to create the manpage from the latest source code…

It would be cool if help2man worked perfectly. In fact the output needs a few fixups -- it looks like it has problems with non-ASCII characters? But if those fixups can be made automatically it's not bad and I agree might be worth adding to the build.

Yes, the output of help2man is not perfect. My main gripe is that it imposes a rather strict format for the manpage, and not all manpage markup is available. But it is better than not having a manpage at all.

The problem with non-ascii characters can be solved, though. Just add an option like "-L en_US.UTF-8" to the help2man call.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#126

Post by kloch »

jimbob45 wrote: post #21
dleslie wrote: post #3

I'd be fine with this, even totally on-board, if C weren't so awful with respect to text. You don't even have to worry too much about free()ing your malloc()s if you design around short-lived processes. But this is just asking for security concerns among the tangled web of string and input processing your bespoke C routines are likely to develop into. Pair it with a better, more modern, and safer native-compiled lang…

Why would you ever choose C anymore? The killer feature of C++ is “you don’t pay for what you don’t use”. There’s virtually no reason ever not to use C++.

The last time I looked at c++ (mid-1990's) it generated hugely bloated binaries and was generally slower at runtime than plain C. Is that still true today?

Is there any language (other than assembly) that is faster at runtime than C today?

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#127

Post by theamk »

rossy wrote: post #46
theamk wrote: post #2

It seems pretty crazy to write web-facing apps in C, with no memory safety at all. (They do have "pledge" but even in the most restricted case, this still leaves full access to database)

It seems like the database libraries they recommend for security, ksql and sqlbox, mitigate the risk with process separation and RBAC, so the CGI process doesn't have full access to the database. It's definitely contrary to modern assumptions about web app security, but it's interesting to see web apps that are secure because they use OS security features as they were designed to be used, rather than web apps that do…

ksql exports "ksql_exec", while sqlbox exports "sqlbox_exec" -- both of those allow execution of arbitrary SQL.

So no, the web apps cannot be made secure via OS support alone, because the OS security features are not adequate for high-level problems. Any sort of code exploit allows attacker to trivially access the entire database -- either to read anything, or to overwrite anything.

"pledge" and "unveil" can prevent new processes from being spawned, but they cannot prevent authentication bypass, database dumpling or database deletion.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#128

Post by kloch »

dleslie wrote: post #3

I'd be fine with this, even totally on-board, if C weren't so awful with respect to text. You don't even have to worry too much about free()ing your malloc()s if you design around short-lived processes. But this is just asking for security concerns among the tangled web of string and input processing your bespoke C routines are likely to develop into. Pair it with a better, more modern, and safer native-compiled lang…

I wrote my first web app in 2000 using C/mysql. It was Insanely fast but very awkward to implement. I used C because it was (and still is) the only language I knew well.

At least if you are going to use C, you (should) know to be extremely paranoid about how you process anything received from the user. That doesn't remove the risk but at least you are focused on it.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#129

Post by theamk »

rkeene2 wrote: post #64
theamk wrote: post #2

It seems pretty crazy to write web-facing apps in C, with no memory safety at all. (They do have "pledge" but even in the most restricted case, this still leaves full access to database)

How about a web-facing she'll that allows arbitrary code execution ? [0] There's nothing fundamentally insecure about allowing C or any arbitrary code to execute on behalf of a user -- this is basically what cloud computing (especially "serverless") is. As you identify, though, you need a Controlled Interface (CI) which accounts for this model for all resources and all kinds of resources and many tools do not (yet) a…

The big difference is that with bash (python, perl, php etc..) exploits, all you need is to upgrade a package, and you are secure. No need to touch any of the application code.

Compare it with C, where the bugs are likely unique per app, and require non-trivial effort to detect and fix.

Execution of user-specific code by serverless services requires non-trivial isolation, and is predicated on "each user has its own separated area" to work. This is not the case with most websites. Take HN for example -- there is a shared state (list of posts) and app-specific logic of who can edit the posts (original owner or moderator). No OS-based service can enforce this for you.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#130

Post by tinus_hn »

kloch wrote: post #128
dleslie wrote: post #3

I'd be fine with this, even totally on-board, if C weren't so awful with respect to text. You don't even have to worry too much about free()ing your malloc()s if you design around short-lived processes. But this is just asking for security concerns among the tangled web of string and input processing your bespoke C routines are likely to develop into. Pair it with a better, more modern, and safer native-compiled lang…

I wrote my first web app in 2000 using C/mysql. It was Insanely fast but very awkward to implement. I used C because it was (and still is) the only language I knew well. At least if you are going to use C, you (should) know to be extremely paranoid about how you process anything received from the user. That doesn't remove the risk but at least you are focused on it.

This is the same in any language. You can cause security issues in other languages as well if you trust the user/attacker.
Post reply on HN