Stéphane Glondu <[email protected]> writes: > Hi, > > Le 14/09/2026 à 10:14, Simon Josefsson a écrit : >> I don't want to do multiple jumps for these Tillitis packages. On every >> compiler bump, the device owner of a Tillitis key gets a new private key >> when the firwmare changes. [...] >> [...] There should not be any functional changes to the >> firmware depending on if it is compiled with clang 19, 21, 22 or 23. > > This sounds wrong to me. Is there an actual rationale for this?
It is an upstream Tillitis decision. The Tillitis device runs apps uploaded from the host and derives the user's private key from the app (and hopefully some entropy). If you change the app uploaded into the device, you will get another SSH private key. This wouldn't be all that terrible if the 'tkey-ssh-agent' supported loading user-provided apps into the device, so that you can keep multiple app blobs around and still get access to your old private key. Progess on implementing that is slow: https://github.com/tillitis/tkey-ssh-agent/issues/125 My perception is that upstream is not strictly against solving this, so it is a matter of human cycles to implement the feature. Fixing that would not solve the underlying problem that any app rebuild, that isn't bit-by-bit identical, leads to a different private key. Allowing the user to control her private keys would solve that concern: https://github.com/tillitis/tkey-device-signer/issues/9 Yes, this set of packages is a corner-case use-case of pinning to clang-19, but nonetheless a bit interesting. That the architecture of the device is not a Debian host architecture, and that the packages needs to ship binaries for that architecture, makes it weird too. Embedding the app binary inside a Debian host binary adds to the weirdness. If anyone has ideas (or code) how to improve this, that would be nice. This situation is a deal-breaker for me personally to use the Tillitis device for most of my production setups (since there is no way for me to audit the private key generation method or entropy), which is a shame since the device otherwise appears to have nice properties. Further, the gap to fix the problem is relatively small. /Simon
signature.asc
Description: PGP signature
