Dear Maintainer,

We would like to remove llvm-toolchain-19 from the archive.
Please update to 21.

Thanks
Sylvestre

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 <sylvestre@debian.org> writes:

Sylvestre Ledru <sylvestre@debian.org> writes:

We believe that the bug you reported is fixed in the latest version of
tillitis-tkey-libs, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1124063@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon Josefsson <simon@josefsson.org> (supplier of updated tillitis-tkey-libs package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 23 Jul 2026 14:44:58 +0200
Source: tillitis-tkey-libs
Architecture: source
Version: 0.1.2-3~exp0
Distribution: experimental
Urgency: medium
Maintainer: Debian Security Tools <team+pkg-security@tracker.debian.org>
Changed-By: Simon Josefsson <simon@josefsson.org>
Closes: 1124063
Changes:
 tillitis-tkey-libs (0.1.2-3~exp0) experimental; urgency=medium
 .
   * Standards-Version: 4.7.4
   * Drop Priority: optional
   * Drop Rules-Requires-Root: no
   * Modernize Salsa CI
   * Add lrc.config
   * Use llvm/clang 21 (Closes: #1124063)
   * Use gbp debian-branch experimental
   * Use watch v5
   * Use compat 14
Checksums-Sha1:
 9ae27929e7d192dca8f85336f6772dfdbcea7bdf 2362 tillitis-tkey-libs_0.1.2-3~exp0.dsc
 1858ff693efc8fcf6f539afceadc26f2d6d5789a 3756 tillitis-tkey-libs_0.1.2-3~exp0.debian.tar.xz
 94b359adddbe7b86a28f105123e708a8ac9a31dd 89236 tillitis-tkey-libs_0.1.2-3~exp0.git.tar.xz
 65c932ecb2948351ad0547d1473a3899f2ca9a26 17610 tillitis-tkey-libs_0.1.2-3~exp0_source.buildinfo
Checksums-Sha256:
 676aafda97142f1f6c7b56855144bc4d0f7e1aca8390e714daf3cffec8c90896 2362 tillitis-tkey-libs_0.1.2-3~exp0.dsc
 44c9a2941c03c985aa06f808bfb78a48ee72bc779d2be4974805812a12f4591b 3756 tillitis-tkey-libs_0.1.2-3~exp0.debian.tar.xz
 0c5b7e014d856ce3cbb204807f8ec6e4a80b70309a633ae223c83010dc1c973c 89236 tillitis-tkey-libs_0.1.2-3~exp0.git.tar.xz
 b6c4ba6ebc48a94066704dfc2d0a28b4fe45afb89de0f9189fd7c0fc38f02f30 17610 tillitis-tkey-libs_0.1.2-3~exp0_source.buildinfo
Files:
 c292d9837496fc25de9b039a8fa4e39b 2362 libs optional tillitis-tkey-libs_0.1.2-3~exp0.dsc
 95c86a5389d079dd51d9c6c53d5f72fc 3756 libs optional tillitis-tkey-libs_0.1.2-3~exp0.debian.tar.xz
 4bed5bef4b3a76acebd241ef0e2c0df9 89236 libs None tillitis-tkey-libs_0.1.2-3~exp0.git.tar.xz
 dd7cf7b436b1adfd9981cab6e652c7ff 17610 libs optional tillitis-tkey-libs_0.1.2-3~exp0_source.buildinfo
Git-Tag-Info: tag=aef4e5188b735d7bc2792db4b14ca7a4ae94b66d fp=a3cc9c870b9d310abad4cf2f51722b08fe4745a2
Git-Tag-Tagger: Simon Josefsson <simon@josefsson.org>
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEN02M5NuW6cvUwJcqYG0ITkaDwHkFAmpiElUACgkQYG0ITkaD
wHl1KA//Xb65A2i8c2IGgRZOb4QZm2rVrn1VMcXyUBr6SwkuxSvf0En6IiNcSkG0
szu9kThBczRb7e4HWIif4DVzAq/thQjoqEdT65do5YaadCostJsDDHPiyMPXQkpy
OHKWmiIEOZ+LNC+yaIhcgrr3y8oh65FjEQC6lx65gBVpiWyNbsIeiCqkvxJCg6X0
pSVodCZ/b5JmL3WqI2rs90KHyjN8puoj4hsMU6GnqDi7BgEQ3aQzCYY7jMQLOJOy
h9h9voH+zNVqtxqB69ig/2Za2NtMNVUhV3cQOiNz9hhozAtXpwTgRjUU8BoN/81A
a+VGA5ZVnjN48pH1tgVPZN+Ixf09HrLcWGEFJZP4pbJ/wvf6Ic5G9eKCDtOFi+rz
yZuwUSVqlw3/TZIyBOuHBEG/k0ZGSBb3DcoONt7u/+qwZfjUwU/heyKnMy9aSnSN
xyL307Mwimx/xnS/I/O0MCfrg1f22K55gl7WbQHbFxhyZRbCGTDayF4Zwu4/y8Wu
/qhKijh3D+Vp1KYTEhPYmhbGo/ghrmgqnpWVVxLUcMQvl6ODvcMsAedjKXgRyYHO
YYEDCimLqzRayBuRIHY7J5nlXo2NoxZaRKBsvHS1xy92vkONd/9Mo2Uicd30NyZT
7gx4kDpitf9JiGCUJhwgHR4COsIFdr6YZZ9A/xrAjy278omvhX8=
=/32D
-----END PGP SIGNATURE-----

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 <simon@josefsson.org> writes: