Hacker Newsnew | past | comments | ask | show | jobs | submit | berryton's commentslogin

Nice! It is easier for me to have multiple SSH keys backed by my Yubikey than GPG keys (only 1 GPG key per Yubikey).


I find it weird that GPG/PGP leans so heavily into "one key per person". Why shouldn't I be encouraged to have 2 or 4 or 10 identities if I want to? If my "web of trust" is diluted as a result, then that's on me (and I don't much care).


>I find it weird that GPG/PGP leans so heavily into "one key per person".

It does?

>Why shouldn't I be encouraged to have 2 or 4 or 10 identities if I want to?

What is stopping you?


> It does?

At least the OpenPGP smart card specification kind of does, yes.

It uses a "single private key stored on the card" (ok, actually three keys) model, whereas FIDO (including SSH‘s security key implementation) uses key handles, which theoretically support an unlimited number of keys per authenticator.


A key handle seems to be the real private key encrypted with a static key from the hardware key.

You can achieve that yourself, for example, using Pass. Encrypt theoretically unlimited number of password and secret keys with the master password in the hardware token.


> A key handle seems to be the real private key encrypted with a static key from the hardware key.

It can be, but it‘s essentially just a binary blob. It can also be entropy to deterministically re-derive a private or secret key from an internal root secret, or just a primary key to look up that key or entropy within the token.

> You can achieve that yourself, for example, using Pass.

How? With a hardware token, you can only do what its protocol allows you to in terms of key derivation.

That means that with a standard OpenPGP card, you will not be able to do key handle based key derivation, while with FIDO/CTAP you can.

You could obviously develop your own OpenPGP-compatible hardware token standard, but you‘d only be able to use it with a patched version of GPG, GPG agent etc, but a big advantage of OpenPGP smartcards (and even more so FIDO/CTAP tokens) is that they are widely supported without requiring driver installation.


The Rust book has a small discussion about his in chapter 9.3 (https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...).

I think it is good to have some references (the blog post and the book) for when the horde comes after you.


This is the right mindset.

Instead of arguing "we need to cut costs", why don't they work on an entry-level paid tier? Seriously, it is like they're not even trying to compete with GH at this level.


Since some comments are talking about alternatives, I'll leave this here: https://github.com/theonedev/onedev

I found out about it on a previous HN thread.

It can do automation, one of the missing points from Gitea.


You may be interested in Tauri: https://tauri.studio/


I was reviewing git hosting prices this week and Gitlab pricing really didn't make sense. The cheapest paid plan doesn't provide enough incentive to the majority of people who just want to host small/personal projects.


While I despise this kernel level bs, do you know how it is going to be implemented on Linux?

As far as I understand, it is coming via Proton/Wine, so these programs would need some kind of kernel level access as well (if they don't have it currently)? Or maybe they're just emulating Windows kernel calls or something like that. I mean, less intrusive (but also less effective) in a Linux system.


Just to make sure that no one reads this and believe in that "Great Barrington" claim, the numbers (as of today) are:

Total Signatures 920,477

Medical & Public Health Scientists 15,707

Medical practitioners 46,412

The rest fall under "concerned citizens" category.


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

Search: