Hi I noticed Debian now has clang 22 in testing already.
Is the intention to ship forky with clang 21 or 22? Or both? I'm in the process of uploading tillitis-tkey-libs and tillitis-tkey-device-signer using clang 21, first to experimental to allow some testing before an unstable upload. It is problematic to bump compiler too often as it results in different binaries (and hence private keys for users) so I'd like to minimize the number of uploads to sid before forky. For future reference, if anyone is chasing this: the upstream bug report has good discussion of compilers and hash values: https://github.com/tillitis/tkey-device-signer/issues/27 /Simon Simon Josefsson <[email protected]> writes: > Thanks, I'll have to discuss with upstream about this -- the problem for > these two (closely related) packages is that llvm/clang 21 does not (*) > produce the same code as llvm/clang 19. For these packages, that > results in users getting a different private key from their Tillitis > hardware device. This invalidate any public key configurations. If > they use trixie tkey device signer app and then upgrade to a forky > version (that were built with llvm/clang 21) their private keys will be > different, and they can't (easily) get their old trixie private key, > which pretty much locks them out of everything. > > I understand it is unreasonable to keep llvm/clang 19 in Debian for > these two packages, and mitigating this problem has an open upstream > request that I'm hoping will get some action before forky: > > https://github.com/tillitis/tkey-ssh-agent/issues/125 > > Will forky ship with llvm/clang 21? If we bump the compiler version and > expected hash checksum here, we'd rather not have to do it twice, since > this churn induce a ecosystem (and end-user) cost. If the code > generated by llvm/clang 21 changes before forky is released, this is > also problematic. So maybe we can prepare an change in experimental now > (to get a hash checksum for future comparison), and wait until shortly > before the forky freeze to upload it into unstable, hoping the expected > generated code stays the same. That means dropping it from testing, I > guess, which may be an acceptable price to pay. > > More thoughts on this rather odd situation is welcome, I don't care > strongly how we approach this as long as it is done carefully. > > /Simon > > (*) I did not confirm the produced code is different now, but I assume > it is, since it was when we decided to pin on llvm/clang 19 instead of > latest version, and I would be surprised if a later version of > llvm/clang than what was used back then somehow reverted to produce the > same code as version 19. > > Sylvestre Ledru <[email protected]> writes: > >> Source: tillitis-tkey-device-signer >> Severity: important >> >> Dear Maintainer, >> >> We would like to remove llvm-toolchain-19 from the archive. >> Please update to 21. > > Sylvestre Ledru <[email protected]> writes: > >> Source: tillitis-tkey-libs >> Severity: important >> >> Dear Maintainer, >> >> We would like to remove llvm-toolchain-19 from the archive. >> Please update to 21. >
signature.asc
Description: PGP signature
