HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
michelp
pgsodium
C2018–2024
michelp / pgsodium

pgsodium

Modern cryptography for PostgreSQL using libsodium.

Data & DatabasesSecurity & PrivacyLibraries & SDKs
Explore on GitHubRead Hacker News discussions
7Distinct people
14Mentions
0Explicit recommenders
618GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Modern cryptography for PostgreSQL using libsodium.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year14 dated mentions

Observed mentions: 2018-04-04 03:25:36 UTC to 2024-01-31 16:05:14 UTC.

02462018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 2 submissions, 4 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC110
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC211
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC624
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC312
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

What Hacker News says

14 sources
michelpp·Jan 31, 2024
I like the "solve the now" perspective here, and having code examples is very helpful to understand some of the rational behind the approach. Having read your previous "tedious survey"[0] post on various token formats, I generally agree with a lot of your conclusions. Curious though about your thought process wrt macaroons vs biscuits. To me the one major downside of macaroons has always been the single shared root symmetric key. Many use cases are addressed by third party attenuation, but then there are the problems like key rotation, having to do online verification, no built in encryption, no peer-to-peer support through an "untrusted" fly.io, and no third party token verification without decryption like in signcryption[1] schemes. Of course this is traded off by having to do PK issuance and management so I can see the simplicity o
Read the rest
f it. Is fly.io scoping this pretty hard to just auth tokens with third party attenuation, or do you see further development and maybe moving to other token systems like biscuit when/if the need arises to address those known issues? fwiw I've done a bit of research work myself on a token format using signcryption [2] where I explored addressing some of these ideas (but not the attenuation side of it yet, which I get is a big deal here). [0] https://fly.io/blog/api-tokens-a-tedious-survey/ [1] https://github.com/jedisct1/libsodium-signcryption [2] https://github.com/michelp/pgsodium/blob/feat/signcryption-t...
In Macaroons Escalated Quickly
michelpp·Dec 16, 2022
> Is Vault something that can handle this without getting into my app code? Basically, if i gave a someone root access to my supabase instance is that encrypted data safe? The answer is slightly offset from your question, so let me start by pointing out that the Vault is about Encrypted Data At Rest. This is mentioned in the docs and in the blog and video, but it's something that I like to always mention first in discussions. The main purpose of the Vault is to store your data encrypted, so that it's encrypted on disk, and in backups. In SQL the decrypted secrets are available to you, because that's where you are using them and encrypted data must be decrypted to be useful. If someone roots access to your database, then yes they can access the decrypted secrets through the view. This is by design, the secrets must be decrypted to be u
Read the rest
seful in query code. This risk is similar to someone rooting your application code, they will see decrypted secrets via your environment key, so no it won't protect you against anyone rooting processes in your stack that need useful access to secrets and it's not meant to. Like all security you must take a layered approach, the Vault is just one storage level layer strategy. One big difference from the env var approach though is that the key Supabase uses to encrypt your secrets with the Vault is stored outside the database, it is inaccessible to SQL, which is an enhancement over sticking the raw key into an environment variable or a table that is accessible to your application. Instead of revealing the raw key, pgsodium has a feature called [Server Key Management](https://github.com/michelp/pgsodium#server-key-management) where you do not have access to the raw key, but instead reference keys by an key identifier. It is safe to store this identifier alongside the data it encrypts. The raw key itself is never stored. I'm very intentionally overusing the word "store" here, because that's specifically the layer of security that the Vault provides.
In Supabase Vault is now in Beta
kiwicopple·Dec 16, 2022
yes - it's open source here: https://github.com/supabase/vault This wraps pgsodium (https://github.com/michelp/pgsodium), which wraps libsodium (https://doc.libsodium.org/). > I'm using Postgresql for a service and I'd love to use this feature. Maybe I should just use supabase as my backend... We'll try to get the other big clouds to adopt some of these extensions we're developing (including pg_graphql). Vault is still in beta, but once it's stable I think it's a no-brainer for them. it can work with secure-enclaves, so it ties in nicely with their other offerings (read: more economically interesting for them). That said, we'd love for you to try supabase.
In Supabase Vault is now in Beta
michelpp·Jan 10, 2022
Hey HN, I shared an earlier prototype version of pgsodium but I just released 2.0 and felt this could be a good opportunity to share some updates! [pgsodium](https://github.com/michelp/pgsodium) 2.0.0 is a postgres extension that uses the [libsodium](https://doc.libsodium.org/) library to provide high-performance, modern cryptography support for PostgreSQL 10+. 2.0.0 includes a ton of new feature and a few bug-fixes: * Support for [XChaCha20-SIV](https://github.com/jedisct1/libsodium-xchacha20-siv) deterministic nonce-free encryption, this is useful for one-time workflows sacrificing a bit of speed and larger key size without worrying about nonce-handling issues. * Support for [SignCryption](https://github.com/jedisct1/libsodium-signcryption) Sign & Encrypt identity verification. Signcryption goes beyond public key verification to provid
Read the rest
e identity verification, and negotiating a shared-secret key between two parties to use fast streaming encryption of the payload. * Key id support for HMACSHA 512/256, generichash, and shorthash. This extends support for pgsodium's key management feature to these useful hash functions. * Support for low level [XChaCha20 streaming](https://libsodium.gitbook.io/doc/advanced/stream_ciphers/xch...). This is if you want to support your own low level algorithms on top of XChaCha20 for example, PASETO. * More tests, docs, and small bug fixes in argument parsing * In-memory key now protected with [sodium\_malloc](https://libsodium.gitbook.io/doc/memory_management), now the key has additional protection from over/underflow memory attack. Check it out at: [https://github.com/michelp/pgsodium](https://github.com/mich... Please feel free to submit any issues you may have and as usual pull requests are greatly appreciated!
In Show HN: Pgsodium – A Crytographic PostgreSQL Extension

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.