6 ms·
> 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
by francislavoie 5y ago
> 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 https://github.com/msteinert/pam) so implementing auth via Caddy's module system is the way to go for this project.
- candiddevmike 5y agoMemory safety won't save you from logic bugs, which is extremely prevalent in authentication exploits.
- francislavoie 5y agoNo arguments there, but it's still much safer to start with a memory-safe language as a base.
- viraptor 5y agoWhile 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.
- deleted 5y ago[deleted]
- gunapologist99 5y 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.