Hmm...

~ main
❯ sq key list | head -1
- 5107E66D34788A93E3227C903AB05486C7752FE1

thread 'main' panicked at src/output/wrapping.rs:47:13:
Writing to output: Broken pipe (os error 32)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

And I thought Rust was memory-safe ;-)

@jarkko I think this is the problem with piping to head, not with sq itself. I observe the same with ntpd-rs.

@oleksandr, i.e. they don't correctly handle SIGPIPE :-)

@jarkko patches welcome :)

So keep in mind that the above was Trixie's stock version so might be already fixed ;-)

I tried as an experiment (don't know what I'm doing just based on help):

gpg --export | sq cert import
gpg --export-secret-keys | sq key import
sq pki link authorize --unconstrained -- <key ID> --all

And then I did:

sq key list > l1.txt # YubiKey detached
sq key list > l2.txt # YubiKey attached

Now, when I diff them I see this pattern:

- - @gpg-agent/default: not available, locked
+ - @gpg-agent/default: available, locked

So based on "sq key import" it really does import smarcard backed keys and marks them with a stub (or any blob identifying private key w/o actually possessing it). This is already much further I had presumed and probably Trixie's sq is not the very latest.

I.e. it uses gpg-agent to be delegate for private key operations? This arises some ideas and questions:

1. I think that in order sq to be a practical tool it would need to speak directly to pcscd i.e., replace the combined functionality of gpg-agent and scdaemon with its own internal shenanigans. Otherwise, there's two keyrings to manage, right?
2. We would need sq-agent that provides ssh-agent shim. Does this already exist or not?

So probably least friction route would be to implement sq-agent that would encompass 1 and 2. That would be easiest to drop-in-replace where gpg-agent sits now, or that's my guess at least.

It's amazing how much you can get just by running couple of commands + toggling yubikey in and out :-)

@neverpanic, @sequoiapgp, @vbabka @oleksandr

@oleksandr Sure, I just like to pinpoint these, as otherwise a typical reaction if you try to say anything bad about Rust's memory managent is like...

@jarkko Is this particular thing about memory management even?

@oleksandr lol not at all :D i mean memory safety, which i guess is that stuff that is not inside unsafe?

@jarkko Sequoia supports talking to cards directly, but it's disabled by default because GnuPG's agent likes to grab them exclusively and in a transition period re-using gpg-agent provides a better user experience. If you go for outright removal of gpg-agent and enabling the `sequoia-keystore/openpgp-card` feature in sequoia's keystore crate, you can talk to them without GnuPG in the picture at all:

```
- @openpgp-card/0006:10938965: available, locked
```

Cc: @sequoiapgp @vbabka @nwalfield

@neverpanic AFAIR you don't need a GnuPG keystore to use gpg-agent with a smartcard, so even with gpg-agent in the picture, you don't need to maintain two keyrings.

There's no SSH agent talking to the Sequoia Keystore yet — that's also something that's still blocking me from dropping gpg-agent completely. There is https://gitlab.com/sequoia-pgp/ssh-agent-pks which uses an older protocol (and no longer works) but can maybe be updated or serve as an inspiration for a new one.

@jarkko @sequoiapgp @vbabka @nwalfield