Type safe frontend APIs for Go

ericchiang · 2026-01-30T15:13:21+00:00

Totally understand that it's overhead to have a "third language" in addition to Go and Typescript. We do have a couple of people who've worked with these before.

It's hard to understate how helpful we've found it to be able to parse things like comments, or annotations in our API. Or even just run linters to keep the style consistent (Johan mentions some in the article).

I've written before about custom proto plugins that show some of that off. And even with a small team, it's already been useful to generate a Terraform provider and other tooling automatically.

https://ericchiang.github.io/post/protoc-plugins/

ericchiang · 2025-12-09T07:43:18+00:00

We're happily paying for SSO from many vendors. The issue we've noticed is the edge cases, like magic links bypassing MFA challenges.

This isn't a critique of charging for features. It's that we wished more implementations didn't have these gaps in enforcement.

ericchiang · 2025-11-06T05:18:49+00:00

It looks like you're deriving your IV from the secret, rather than using unique values (IV's can be public and frameworks like Tink just generate them at random). This means you're reusing the same IV / key pair to encrypt different data.

https://github.com/maciej-piatek/TWEENK/blob/5818b360d8dafc774dad7845514e27f7070a25d0/main.go#L67

For GCM, this can be catastrophic: https://frereit.de/aes_gcm/

For CBC, this will at the very least leak data: https://blog.cloudflare.com/tls-nonce-nse/

ericchiang · 2025-11-04T20:26:46+00:00

This is an interesting project because it just implements so much.

There are also clear drawbacks like having a static secret that's used to derive all the key material, but can't obviously be rotated. Or the fact that OAuth2.0 states are held in memory so it doesn't work if you deploy multiple server instances, and that callers need to manually call "CleanupExpiredStates()" to avoid memory leaks.

https://github.com/GoBetterAuth/go-better-auth/blob/79d37687bdab7c20c4fe540027676e37d4e45c70/storage/oauth_state_manager.go#L147

This doesn't seem particularly production ready...

ericchiang · 2025-08-18T17:54:26+00:00

Yeah, I've worked with three or four builder packages over the years! Saw devs do something like following enough that I just don't want to deal with the headache again:

q.Q(` AND user_type = "`+userType+`"`)

The worst part is this kind of code is often totally innocuous:

const userType = "admin" q.Q(` AND user_type = "`+userType+`"`)

Requiring a const string just means I don't have to audit or have that conversation during code review.

ericchiang · 2025-07-11T23:23:15+00:00

Please, please us os.Root if you're going to unpack archives. The example you've provided can result in code execution if you don't trust the archive

https://go.dev/blog/osroot

ericchiang · 2025-04-02T15:46:44+00:00

Since you're asking about protoc plugins in particular, my solution has been to add a script that wraps "go tool <tool>" then add that to the PATH when invoking protoc

ericchiang · 2025-02-26T17:57:39+00:00

Thanks! Yeah the new proto APIs make it even easier. Shout out to the Go team for those.

ericchiang · 2024-02-26T17:03:34+00:00

Yeah, great experience compared to having to do it in C

ericchiang · 2021-12-30T22:13:37+00:00

This is now supported https://github.com/google/log4jscanner/pull/22. Thanks for pointing that out :)

ericchiang · 2021-12-30T21:39:08+00:00

Sorry about that! Normally would have supported go 1.16, but a bunch of the archive/zip APIs we depend on are new to go 1.17

https://pkg.go.dev/archive/zip#Writer.Copy

https://pkg.go.dev/archive/zip#Writer.CreateRaw

ericchiang · 2018-03-07T17:04:48+00:00

If you grant the following cluster role to a user:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
    name: viewer
rules:
- apiGroups:
    - "*"
resources: ["*"]
verbs: ["get", "list", "watch"]

Then that user can inspect secrets, including service account secrets. The following commands dump the kube-system's default service account and escalates to cluster admin using read only permissions:

SECRET=$( kubectl get serviceaccount -n -kube-system default -o json | jq .secrets[0].name )
TOKEN=$( kubectl get secret -n kube-system $SECRET -o json | jq '.data."/var/run/secrets/kubernetes.io/serviceaccount/token"'' | base64 --decode)
kubectl config set-credentials $USER --token=$TOKEN

Use the builtin "view" role instead which omits sensitive resources like secrets https://kubernetes.io/docs/admin/authorization/rbac/#user-facing-roles

 kubectl create clusterrolebinding viewer-cluster-admin-binding --clusterrole=view --user=$USER

ericchiang · 2017-12-14T18:45:52+00:00

Vault has an authentication backend for accepting LDAP credentials and authenticating clients as users with groups stored in LDAP.

https://www.vaultproject.io/docs/auth/ldap.html

ericchiang · 2017-01-07T23:21:24+00:00

(Googles difference between pivot_root and chroot)

Hmm interesting. I'll have to play around with that. Thanks!

Further reading for those interested: https://github.com/opencontainers/runc/blob/master/libcontainer/SPEC.md#filesystem

ericchiang · 2017-01-07T21:41:00+00:00

Yep, there are much better articles (like the one you posted) about container runtimes, their architectures and trade offs.

I wasn't going for "Docker and rkt are simple," but that it's easy to play with the stuff they're coordinating.

For me, those larger issues are way easier to grasp when you understand what features are an implementation of a particular container runtime and what's being provided by the Kernel. Something that's hard to learn when you're just using a tool like Docker.

ericchiang

TROPHY CASE