#1131028 trixie-pu: package golang-github-tillitis-tkeyclient/1.3.0-1~deb13u1 (pre-approval)

#1131028#5
Date:
2026-03-17 08:36:55 UTC
From:
To:
[ Reason ]
Hi!  Upstream has provided an advisory:

https://github.com/tillitis/tkeyclient/security/advisories/GHSA-4w7r-3222-8h6v

While this could be handled by a security patch, due to the complexity
of upstream's recommended solution (involving patches to
'tkey-ssh-agent' too) and low impact, it was suggested on
#debian-security to use the proposed-updated mechanism instead to just
update both packages to latest upstream version.

I'm attaching the debdiff between 1.2.0 and 1.3.0 and I suggest
something similar could be uploaded to trixie-proposed-updates.

What do you think?  Is this an acceptable way to resolve this?

If so I can prepare a similar debdiff bug report for 'tkey-ssh-agent'
for your additional review.  These two would have to go together.

[ Impact ]
If this isn't adopted, one out of 256 users that provides a USS secret
will not actually make use of the USS, thus possibly lowering their
perceived security.

[ Tests ]
This is upstream patches, so presumably well tested.

[ Risks ]
There is always a risk upstream's patches are buggy and cause unrelated
problems.

[ Checklist ]
  [ ] *all* changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in (old)stable
  [ ] the issue is verified as fixed in unstable

[ Changes ]
(Explain *all* the changes)

[ Other info ]
(Anything else the release team should know.)

#1131028#12
Date:
2026-07-13 08:31:21 UTC
From:
To:
Hi,

Please go ahead with the necessary debian/changelog entry added.

Thanks,

#1131028#19
Date:
2026-07-13 10:02:30 UTC
From:
To:
I looked into making a proper debdiff now, and found a problem.

Upgrading golang-github-tillitis-tkeyclient from 1.1.0-2 (trixie) to new
upstream 1.3.1 depends on a newer version of
golang-github-ccoveille-go-safecast.  Trixie has version 1.6.0-1, but at
least the upstream v2.0.0 is required (already in testing).

We COULD back-port golang-github-ccoveille-go-safecast too, but when
looking into that I realized that upgrading
golang-github-ccoveille-go-safecast from 1.6.x to 2.0.x breaks reverse
builds of not only golang-github-tillitis-tkeyclient (which is expected
and part of the plan) but another unrelated package in trixie:
golang-github-smallstep-certificates-dev.

I stopped looking there, we could back-port
golang-github-smallstep-certificates-dev too.  It only has one reverse
build dependency in trixie: caddy.  I didn't check if caddy in trixie
builds with a more recent golang-github-smallstep-certificates-dev; if
not, back-porting a fix to caddy is required too.

I think this is getting messy.  I'm not convinced this is a reasonable
plan for stable-updates any more.

I'll ask upstream if they could provide a proper back-port of the
security fixes to the golang-github-tillitis-tkeyclient v1.1.0 release
(and the related tkey-ssh-agent v1.0.0 release) without the unrelated
golang-github-ccoveille-go-safecast version bump.

/Simon

Jonathan Wiltshire <jmw@debian.org> writes: