Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Indeed bcrypt is preferred but this is just a simple backend. My first ick was using CSV as storage as opposed to golang’s builtin SQLite support.

A SQLite connection can be made with just a sqlite://data.db connection string.



Golang does not have built in SQLite. It has a SQL database abstraction in the stdlib but you must supply a sqlite driver, for example one of these: https://github.com/cvilsmeier/go-sqlite-bench

However using the stdlib abstraction adds a lot of performance overhead; although it’ll still be competitive with CSV files.


Ok, one additional dependency to your go.mod - big deal. And by builtin I was referring to the database/sql module which was designed for this.


Most of the more common SQLite implementations for go require CGO and this is a pretty steep request, it's definitely more than a line in go.mod


Well the project goal seems to be extreme minimalism and stdlib only, and the choice of human readable data stores and manually editing the user list suggests a goal is to only need `vim` and `sha256sum` for administration


maybe this is why they used sha-256 too, it's in the stdlib whereas bcrypt is a package (even if "official")


The standard lib has pbkdf2 though.

I'm guessing the goal is that the file can be managed more easily with a text editor and some shell utils.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: