#1108992 opendnssec: OpenDNSSEC is (almost) End-of-Life

Package:
src:opendnssec
Source:
src:opendnssec
Submitter:
Ondřej Surý
Date:
2025-07-23 10:25:01 UTC
Severity:
normal
#1108992#5
Date:
2025-07-09 07:16:12 UTC
From:
To:
Hi,

I am filling this as grave, but feel free to change the severity if you get an
agreement from the security team.

During the recent CENTR Jamboree 2025, NLNetLabs (upstream) announced that
OpenDNSSEC is essentially dead and they plan to announce EOL later this year:

https://nlnetlabs.nl/downloads/presentations/Nameshed-CENTR-Jamboree-20250522.pdf

The question is whether it makes sense to release Trixie with a security
software that's going to reach End-Of-Life shortly after Trixie release.

Ondrej

- -- System Information:
Debian Release: 12.11
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-37-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmhuFzxfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcKEYQ//UhpywqE7iqbswGYQ27gAVqP6nxKyibUVj1CD8fpyt2jIcF8AvjlgxfEf
tTGLCZDE/0idq5Ch/FmZ0nHYqiWt/RNRADYBOeAaAt5Km+dC5U74c8xQVhpQUfju
tGhc5HxSovwryOqEMfPbhVgfvwGj/9/5667VRmB4dxJdvkH8jeqghnTY8cuvzjRZ
UVxxred6+sPSAuQFPy3WYe6aYL4SOOFj1JurrjPy78XskcQucgYUewfNmlsK736Q
JKqb7mG7KxJB9EZwCQTUYp8nLz4BfLrE6JdxRb67ADyc3Pm6WWOFkeAXAdr/X7G4
jETswOz6HPw6IAAuB3kcu7vE0QZAXU7LLttGOvLjs5OGRezKBaNqY15VSQyAVJFi
ZaKw7QtWZEcihxEecg2g4rGpIgqxPXbTwINpkAA+Vp3N5hoFkuNMgux6BFz38pJg
zqbhsh5ORDxM0ZYAJWWXMV3RBsUggCiYt6OHDaYRRewrSrH5+3MZJOnvgk1WamB2
iRq7sS8cbEoXfTUBqbuntdyHq7cRMz+vJb2Rt05FSIJ2FHzJXAYOzm4vrGnFvZAn
Wg/9b2Aq/wQ4qk3hQuQtobSAbYC0HBCFIFd2EzszJAgANNyZ4yYjazW5kYwFA/0f
wakPFIT8L1JPlYhkXXG/DWOcxek73WEb2zJ0D7H3SN9EuvwzwWo=
=kftc
-----END PGP SIGNATURE-----
#1108992#10
Date:
2025-07-16 16:22:52 UTC
From:
To:
All of the reverse dependencies should be okay when #1109389 is fixed.
#1108992#15
Date:
2025-07-19 19:04:17 UTC
From:
To:
Bastian Germann <bage@debian.org> writes:

How do we stop the autoremoval from happening on 2025-08-22?  The
migration of golang-github-containers-ocicrypt from unstable to testing
won't happen before then.  Is this a situation where we should ask the
release team (?) to migrate that package to testing earlier?  Or should
the RC severity of 1108992 be lowered?  Or something else?

/Simon
#1108992#20
Date:
2025-07-19 20:31:33 UTC
From:
To:
Oh thank you!

/Simon
#1108992#25
Date:
2025-07-21 08:21:23 UTC
From:
To:
severity 1108992 normal
thanks

Bastian Germann <bastian.germann@gmx.de> writes:

It seems the autoremoval is more aggresive than the override permission,
with autoremoval removing a lot of packages tomorrow that (indirectly)
depends on opendnssec, but the release team override will come into
effect ~2 days later and only allow golang-github-containers-ocicrypt
into testing until after the autoremoval has removed a bunch of
packages.

I'm lowering the severity of this bug, to give
golang-github-containers-ocicrypt some time to enter testing first, so
that we can raise the severity of this bug again to trigger autoremoval
of the opendnssec package.

Is there a better way to handle this?  I hope this is okay.  I think the
original report is about removing opendnssec from trixie, not about
removing everything that depends on opendnssec by mistake, i.e.,
everything behind golang-github-containers-ocicrypt, which involves a
lot of packages:

podman
buildah
cosign
gitsign
gittuf
sigstore-go
...

I guess another way is to turn this bug into a release team request to
drop opendnssec from trixie?  And not use the autoremoval mechanism to
achieve this.  Then the release team can wait for
golang-github-containers-ocicrypt to enter testing, and then remove
opendnssec from testing.

/Simon
#1108992#34
Date:
2025-07-23 08:51:55 UTC
From:
To:
severity 1108992 grave
thanks

Bumping severity again since golang-github-containers-ocicrypt is now in
testing, so removing opendnssec from testing should be possible.  I
realized the summer heat caused me to confuse the autoremoval date of
2025-08-22 with 2025-07-22 so there were no real urgency here...

/Simon

Simon Josefsson <simon@josefsson.org> writes:
#1108992#39
Date:
2025-07-23 09:31:49 UTC
From:
To:
I believe the auto removal counter resets when there’s an activity on the bug. Or at least it was the case in the past (or my memory is failing me).

Ondrej
--
Ondřej Surý (He/Him)
#1108992#44
Date:
2025-07-23 10:05:46 UTC
From:
To:
Ah, right, although this bug would not necessarily have any activity
since the real issue was golang-github-containers-ocicrypt but that is
now fixed in testing.  And the autoremoval was for 2025-08-22, not
2025-07-22 which my summer heated brain incorrectly read it as...

However if the intention to keep 'opendnssec' out of trixie, maybe this
bug should be escalated into a removal request from the release team?
I'm not sure if autoremoval works during the final freeze?  The release
date is 2025-08-09 and the autoremoval trigger is now on 2025-08-07, but
probably this email will bump it further if your theory is correct...

/Simon

Ondřej Surý <ondrej@sury.org> writes:
#1108992#49
Date:
2025-07-23 10:12:51 UTC
From:
To:
* Simon Josefsson <simon@josefsson.org> [250723 12:11]:

The RM bug is #1109554.

Chris
#1108992#54
Date:
2025-07-23 10:18:38 UTC
From:
To:
Chris Hofstaedtler <zeha@debian.org> writes:

Great, all set then, and sorry for not being aware of progress here.

/Simon