This is a non-sequitur, even if you use SSH certificates you still need a public/private keypair, hosts just authorize the key by checking the signature from a trusted CA on the public half of the user key. The OP is about a way to store the private key part of the user key that can't be extracted even with physical access to the machine. So, this is an equivalent/alternative to using a YubiKey, that is conveniently built in to a popular piece of hardware; not something orthogonal to using SSH certificates.
It's not really a non-sequitur. The idiom for SSH certificates is to be issued extremely short-term certificates in response to MFA authentication. You don't get long-term secrets in most SSH CA schemes.
You're certainly more of an authority on it than I, so I trust when you say most schemes don't keep long-term keypairs around; but of the two companies I've worked at that use SSH CAs: one used Teleport, and the other had long-lived keypairs, but fairly-short-lived certificates -- you had to get your public key re-signed each day. They used Yubikeys to store (or maybe just unwrap?) the private key material during the SSH handshake; much as a TPM or the Secure Enclave could be used to do this.
My experience (over maybe 10 years of using SSH-CAs) was similar, I mean by using long-term key pairs (mostly for humans) and shorter certificates. I can imagine secretive to be a very useful tool for SSH-CAs and other uses. I also like the fact that you can't import a key, makes it pretty clear that A- it's a specific device, and B- there is a human adding their bio info to unlock it.
Your experience of SSH CAs is different from mine (that doesn't make it wrong). My experience is that the major motivation for SSH CAs is linking SSH authentication to MFA SSO. The long-lived secrets here are the MFA secrets.
Very useful to know, thanks for explaining more. I am curious to know (if you happen to remember) if this was an off-the-shelf product, and if so which one? I assume the product was either an MFA device or an SSH/SSO solution or both.
I've worked with teams that did bespoke versions, but Teleport is the most popular implementation of the idea right now. The underlying idea is trivial, right? You have an SSO RP that is a CA, and issues short-lived certs based on SSO IdP logins; the simple SSH certificate machinery makes this work across your fleet.
The certs are just an alternative to managing the authorized_keys server-side. That's it. What you said about MFA and not getting long-term secrets is some extra thing on top of it and not invalidating your parents point.
I understand what you're trying to say, but "The certs are just an alternative to managing the authorized_keys server-side" is just not correct. Certs can do things plain authorized_keys can't.
Yes! They will receive an email with the message, and some boilerplate explaining that it was sent from Radiopaper and that if they reply to the email the message will be published. They'll also receive a link to view the post on the site if they prefer.
It's helpful feedback that this isn't as discoverable as it should be. If you hover your cursor towards the bottom of the explore page, some links show up.
You can change your _display name_ on your profile page, and that's what appears publicly on the site (your email doesn't appear publicly, even if you log in by address!).
Today to get a custom profile URL like radiopaper.com/Dave, you just need to ask and we'll create an alias for you. There isn't a self-serve alias mechanism available today, but we're thinking about how to provide one. Any profile can be linked by the URL radiopaper.com/uid, for instnace my profile can be reached at https://radiopaper.com/user/AwQLwnOgQFdyDfNoYfNCSSsVdx43, "Dave" is just an alias.
Clearly having separate concepts of login method vs display name vs profile URL is all a bit confusing, this is helpful feedback!
Being able to change your email address is a known gap, sorry about that. For now if you want to use a different email you'll need to make a second account. We plan to make account merging possible in the future.
A short-sighted technical decision on my part: we use the Firebase Auth UIDs as our internal user IDs, but Firebase Auth does not allow you to have multiple email auth-providers on a single account. So we need to add a layer of indirection in our data model.
Thank you! The inability to change the email address is OK, but it should still appear somewhere so I know what it is and that it's not my username. Maybe a note of "you can't change this yet, sorry!" would be nice too.
Hacker News has definitely pushed us out of the free tier for today, but these services are still impressively cheap. We may have a $5 cloud bill this month.
The ability of the OP to accept or ignore replies is in addition to, not instead of, regular spam filtering techniques. Certainly we'll want to automatically block bots and other bad actors that violate our policies to reduce the burden on users.
My personal opinion here. We (NodeBB) decided to go with categories from the get go because it was a form of hierarchy that worked well for YEARS, and you don't go breaking things that work fine.
IIRC Discourse started without categories. The whole "bucket of messages" shebang. It did not go well, in the sense that I believe people kept asking for categories.
There's something special about a curated list of folders to slot messages into, that tags and labels don't quite capture.
Currently, the user is being presented with most things, so I think my framing matches the actual user perspective with better accuracy than a cheerier wording. ;)
