With CGO disabled, it only reads /etc/passwd, while the glibc getpwnam(3) can query LDAP etc.
HN user
dchest
Dmitry Chestnykh, founder of Coding Robots, a tiny software company (productivity apps, currently: Mémoires, Video Mémoires). Created and maintaining "I Write Like" (https://iwl.me) and Calcish (https://calcish.com). Created BlogJet. Failed with StableLib (https://news.ycombinator.com/item?id=9342769).
Author of Password Authentication for Web and Mobile Apps (https://dchest.com/authbook/)
Based in Montenegro.
Email: dmitry@codingrobots.com
X: @dchest Bsky: dchest.com Mastodon: mastodon.social/@dchest
Website/blog: https://dchest.com
GitHub:
https://github.com/dchest
https://github.com/coding-robots
(CC-BY) All my comments on HN are licensed under Creative Commons Attribution 3.0 license.
Which uses libc via CGO or parses /etc/passwd with no CGO, which won't work for some cases.
https://github.com/tailscale/tailscale/blob/e4144230f410204a...
// userLookupGetent uses "getent" to look up users so that even with static
// tailscaled binaries without cgo (as we distribute), we can still look up
// PAM/NSS users which the standard library's os/user without cgo won't get
// (because of no libc hooks). If "getent" fails, userLookupGetent falls back
// to the standard library.I did something like this using fail2ban for some time, but 1) it didn't help much due to the larger number of IPs, 2) it blocked widely used VPN services.
Can be malware? Something like https://news.ycombinator.com/item?id=48667495
Being able to quickly reject invalid sessions identifiers is a useful property in some cases and is normally done by authenticating stateful session tokens with a MAC using a global app key. This can be used for DoS protection if the cost of a database lookup is more than the cost of MAC, and the complexity is justified. It ensures that the random numbers a user is trying to present as their session token are the numbers generated by the server if the key is not leaked.
Because you're trying to bolt things on top of JWT, you're creating a worse version of that stateful authentication pattern:
1. You lost the statelessness of JWT by making database queries. Your claim that "you don't need to verify against user's secret immediately" is false, as you need to do that in all cases immediately after verifying the JWT signature to get the benefits of your system (token invalidation). Sure, you reject completely invalid tokens early, but you still need the statefulness to authenticate users properly (if your goal is to be able to invalidate tokens).
2. In your version, getting a read-only access to the user database (leaking per-user secrets) completely destroys token invalidation, and all your authentication now depends on one key. If, in addition to that, the JWT signing key leaks, user authentication is completely destroyed and can be bypassed by the attacker, who now can sign in as any user. (A common way to leak all this is by failing to properly secure backups).
Compared to a stateful session system with split-tokens, where the database stores tokenId => verifier, where verifier is Hash(randomToken), and user's token is id||randomToken, read-only access to the database doesn't let the attacker authenticate as any user. If the tokens that users presents are in the form of id||randomToken||HMAC(serverKey, id||randomToken) for early rejection as above, leaking serverKey still won't allow the attacker to authenticate as any user. The attacker needs write access.
Is author's brain stateless -- my bad, I thought this was not reddit
I didn't realize that you were the author, I thought you were a reader who was misled by this blog post. Even better: you can go and edit it, removing "stateless" everywhere! It's fun to invent various protocols, but when someone points out the errors, surely you'd want to fix them -- no shame in making mistakes if you correct them.
Usually, when I think of a protocol, after writing down "Benefits" (as in your blog post), I write "Drawbacks" and then try to come up with downsides and compare it with existing protocols. I'd suggest you do the same.
PS. Find yourself in this picture: http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-...
WTF:
Each user has a secret: Stored securely in the database.
Stateless Validation: The core validation remains stateless. We only need to consult the database for the user's secret, which we'd likely do anyway for authorization checks.
Is "stateless" the same as "serverless" now? Is author's brain stateless?
Yeah, you made a revocation list but with time value instead of the token value.
It's interesting that most of the comments here are about using this feature to bypass security restrictions (whether valid or not). It says a lot about the attack surface of GNU utilities caused by featuritis.
Oops, of course, thanks for correction!
just a block cipher in the category of endofunctors
A block cipher is just a keyed pseudorandom permutation! :)
Imagine that we have arranged all numbers from 0 to 115792089237316195423570985008687907853269984665640564039457584007913129639936 (2^256-1) in an array and then shuffled that array 115792089237316195423570985008687907853269984665640564039457584007913129639936 (2^256) times uniquely, each time recording the resulting shuffled array.
Here's the Go-like type:
var perm [115792089237316195423570985008687907853269984665640564039457584007913129639936]uint256
This is an unkeyed permutation (we can already build a secure hash function like SHA-3 from it, e.g. SHA-3 uses [2^1600]uint1600 permutation, while Ascon-Hash uses [2^320]uint320. The best we can do with ours is 2^127.5 collision security).
A keyed permutation takes 2^256 of these arrays, again shuffled differently and uniquely, so we have:
var keyedPerm [115792089237316195423570985008687907853269984665640564039457584007913129639936][115792089237316195423570985008687907853269984665640564039457584007913129639936]uint256
A block cipher is just P[k][p] where k and p are indexes into the arrays. Let's call k the key and p the plaintext — first we select one particular permutation using the key, and then select the resulting number (ciphertext) using the plaintext.
A simple hash function built from this keyed permutation splits the message into 256-bit numbers and then selects permutations using the message as k, and previous value as p and adds them together:
h = (some starting number called IV)
h += keyedPerm[m[0]][h]
h += keyedPerm[m[1]][h]
This is SHA-2, SHA-1, MD5, etc, and with a slight variation and a larger block cipher, BLAKE(1,2,3).Of course, it's physically impossible to have that much memory for the arrays and it's physically impossible to shuffle that many times, so a block cipher is an approximation of that by smashing and rearranging bits, hoping to cause diffusion and confusion.
Did you use their volumes for node_modules or a shared dir? I mounted the whole project directory (with node_modules) inside the container and it seems to work fine (MBA M1 8 GB RAM).
The are not a "gatekeeper" under DMA (not enough users). Same as macOS.
That's almost what it does? It's in the article:
"When a contact calls you and you're both using Phone by Google, their device sends a silent confirmation signal in real time to your device to verify the call is legitimate and truly coming from the contact's device," Google writes in a blog explaining the new feature. "Because this digital handshake uses end-to-end encrypted Rich Communication Services (RCS) technology, it is completely private."
They'll just tell you to clear cookies and use Chrome.
"RT kernels"
Well, obviously, software can't do things that the author didn't write code for. But AppKit components do get updated with some new features even if the original software didn't have support for them originally.
For instance, an app can't start using Apple Intelligence if it's compiled with an older version of the SDK that doesn't know that such a thing exists.
That's not true, it became available in all NSTextViews by default, although with a bit different look.
Fun fact: the original iPhone's UITextField and UITextView were backed by WebKit (https://x.com/kocienda/status/1400484168199401477)
How does a high-reliability system have a broken /dev/random? You're better off fixing it rather than trying to fix every downstream component that uses it. You can put your AES-128 counter there if you can count reliably.
That was after IAC:
"Additional acquisitions in 2006 included ShoeBuy.com,[46] which the company later sold to Jet,[47] and Connected Ventures including CollegeHumor and Vimeo".
Colin, if I remember correctly, you first ran Tarsnap servers on Ubuntu before you made FreeBSD work on EC2. At what point were you confident enough to switch to FreeBSD?
They are a marketplace for model providers, which is quite a nice business model.
https://webmachinelearning.github.io/prompt-api/
Already in Chrome as an origin trial: https://developer.chrome.com/docs/ai/prompt-api
Traffic encryption with 2048-bit TLS, the successor to SSL
With 65537 exponent, the successor to 3.
I just downloaded the ODS version and it comes with .pdf extension, had to rename it. It also uses Aptos Narrow font (from MS Office), which gets substituted.
Note that this isn't a study of actual workplaces, it's based on cognitive tests, so "bad at their jobs" may be a stretch. For example, "overconfidence in one's intellectual and analytic abilities" may be good for business, e.g. when dealing with US government contracts in 2026.
Yes, it can -- to all questions.
8 GB M1 MacBook Air does support Apple Intelligence.
Why can nearly every big tech take care of their supply chain? :)
Clearly, the maintainer doesn't want to do this job anymore, and it's not a requirement when releasing your code to also do stuff unrelated to programming.