undefined | Better HN

0 pointsfrancislavoie4y ago0 comments

> It's funny how people keep reinventing things.

That's not exactly fair. The entire point of this exercise is to move away from C code, by implementing it in a memory safe language (Go).

Since PAM uses shared-libraries to operate, that's fundamentally incompatible here since Go is statically compiled (unless you use some CGO like in https://github.com/msteinert/pam) so implementing auth via Caddy's module system is the way to go for this project.

0 comments

4 comments · 2 top-level

candiddevmike4y ago· 2 in thread

Memory safety won't save you from logic bugs, which is extremely prevalent in authentication exploits.

francislavoieOP4y ago

No arguments there, but it's still much safer to start with a memory-safe language as a base.

viraptor4y ago

While it's true, most languages we move to today as memory-safe system languages do help with logic bugs. Full struct initialising, actually typed and checked enums, pattern matching, ADTs, etc. make logic bugs less likely.

gunapologist994y ago

> That's not exactly fair. The entire point of this exercise is to move away from C code, by implementing it in a memory safe language (Go).

Ok, I'll go along with that, but being memory safe is no panacea either.

> Go is statically compiled

As soon as you use os or net, you're almost certainly dynamically compiled unless you take deliberate steps not to be. (You can check your final binary with ldd to see if it's dynamic or not.)

Here's a few things you should do to be sure you're compiling statically:

    CGO_ENABLED=0 go build -tags osusergo,netgo

Also, you can't use the race detector or explicitly C libraries like SQLite. And, be careful -- if you use CGO and try to compile statically, then you might end up including glibc.

j / k navigate · click thread line to collapse