Is this repository safty to access our private key

[fqdeng]

Is this repository safety to access our private key?
I don't know how to code javascript.

[fqdeng]

and who knows Handshake how to access our github.com public key?

[rithvikvibhu]

Is this repository safety to access our private key?

I can say that it's safe, but you'll have to ask someone you trust to verify the code :)

and who knows Handshake how to access our github.com public key?

GitHub returns the public keys at /.keys. For example, your public key is here: https://github.com/jonwinters.keys

[fqdeng]

Is this repository safety to access our private key?

I can say that it's safe, but you'll have to ask someone you trust to verify the code :)

and who knows Handshake how to access our github.com public key?

GitHub returns the public keys at /.keys. For example, your public key is here: https://github.com/jonwinters.keys

thanks

[bsl]

I think the short answer is no, there's no way to provide the password to your SSH private key to a huge pile of javascript in a way that most people would be OK with, and that's sad, because the people who wrote this tool may be trying to do something very nice with nothing dodgy going on. But IMO this tool simply should not have been written this way. Nobody should be giving this thing their password. Sorry.

[natevw]

Given the lack of progress on #31 it seems it is technically infeasible to claim the airdrop without [potentially] compromising one's private key.

The goal of course is to claim the airdrop but not have the airdrop "claiming" you back.

AFAICT, the practical options (perhaps in combination) would be to:

1. remove the public key from Github and anywhere else it may have been trusted before exposing the [now pre-emptively considered burnt/leaked] private key to this tool — I'm assuming this works as afaict it's not the current state of Github that matters but rather a snapshotted state from 2019 [xref Wait, so this only works if you decided you shouldnt ever rotate your github ssh keys?  #134 (comment)].
2. attempt to prevent any communication from the tool starting the moment before it has access to the private key (e.g. air gapped machine, VM, Docker… see How to run pseudo-airgapped hs-airdrop using Docker #106) and immediately shredding that host environment as soon it has been used to make a claim — note that this assumes no private key material is leaked out via the claim itself and so might be best only as an additional line of defense beyond the first step (e.g. in case key was trusted somewhere you forgot to clean up, or Github has a bug that accidentally keeps trusting old keys, etc.…)

[pinheadmz]

@natevw thanks for your comment, I agree with everything. Just to answer your question yes the airdrop is based on a snapshot from 2019 and so you are right, the most secure action would be to remove and replace that key from github before using hs-airdrop, and the original key from 2019 is the correct key to sign with.

[emanuele]

In principle, would it be possible to avoid giving the private key to hs-airdrop but instead just sign an hs-airdrop generated message externally, e.g. via gpg? Why is mandatory to give the key?

[bsl]

Now that I search for it, I do see ways of signing messages with SSH keys using OpenSSL tools that I didn't know about. I think that would have been a better way to do things, but it still seems tolerable to burn the old key and use a new key instead. I needed to move to ed25519 anyway.

[pinheadmz]

@emanuele @bsl you might be interested in tracking this issue: #31

It's technically possible to use your own software (or well-reviewed legacy software like OpenSSL) but there may be a few extra steps for example decrypting the nonce with your private key.