isc-dhcp is EOL and marked as not security supported.  It should not be
released with trixie.

See
https://lists.isc.org/pipermail/dhcp-users/2022-October/022786.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035972

Bastian

I wonder why you filed a serious bug report so late in the release process.
We all know the EOL of isc-dhcp, but what alternatives should be used,
without the need of major changes?

I guess we have other packages that are stalled upstream, but that
does not mean, that we must remove them from testing.

Please provide an alternative we can use.

El 19/05/25 a las 22:26, Bastian Blank escribió:

While I consider that users of isc-dhcp-{client,server} should migrate
to alternative implementation, I think it is too late now to ask for the
removal of isc-dhcp, being so close to release trixie.

It is to note that, TTBOMK, there is currently no substitute for
isc-dhcp-relay.

https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#deprecated-components
reads:

"The security team will support the isc-dhcp package during the bookworm
lifetime, but the package will likely be unsupported in the next stable
release, see bug #1035972 (isc-dhcp EOL'ed) for more details."

That doesn't mean that it will be remove in trixie.

debian-security-support/trixie already reflects the above.


The severity of this bug could be risen again after the release.  Or the
release team could also tag it ignore-trixie.

Cheers,

So you will support this package?

Bastian

Control: severity -1 serious

It's dead. Except for fai-quickstart all reverse dependencies have MRs.
I am all for getting it removed.

Cheers

Okay, only libguestfs has a MR. But still …

What is the alternative implementation for isc-dhcp-relay?

Greetings
Marc

Hi,

isc-dhcp is the reference implementation of a DHCP server and still
used by nearly 8000 users (see popcon), but the main replacement
called kea has only around 180 installations.

It seems that our users did not yet migrated and therefore we should
not remove this package SO LATE in the release process.

There are more packages that are dead upstream for a much longer time
(e.g. htdig last release 2004, last apt-rdepends upstream release
2005) and these packages are orphaned (both for more than 6000 days)
but we do not remove them.

The priority are our users, and I'm sure experienced sysadmin (that
use isc-dhcp) know that they should migrate to a replacement.

Let's keep the package for trixie.

dnsmasq appears to have an DHCP relay implementation. I have not
tried it.

Best,
Chris

Hi,

isc-dhcp is the reference implementation of a DHCP server and still
used by nearly 8000 users (see popcon), but the main replacement
called kea has only around 180 installations.

It seems that our users did not yet migrated and therefore we should
not remove this package SO LATE in the release process.

There are more packages that are dead upstream for a much longer time
(e.g. htdig last release 2004, last apt-rdepends upstream release
2005) and these packages are orphaned (both for more than 6000 days)
but we do not remove them.

The priority are our users, and I'm sure experienced sysadmin (that
use isc-dhcp) know that they should migrate to a replacement.

Let's keep the package for trixie.

I think that we (Debian) should be able to give an answer to those
questions before pulling ISC DHCP.

Greetings
Marc

+1 from me.

Greetings
Marc

+1 from me.

Greetings
Marc

El 22/05/25 a las 20:34, Bastian Blank escribió:

Support in which terms?  As mentioned already, it won't have security
support:
https://salsa.debian.org/debian/debian-security-support/-/blob/c6f47cb42decabe13f064c8ab0aba75dd5be9b1c/security-support.deb13#L23

There are non-security bugs to be fixed, yes.  But users cannot expect
security issues to be fixed.

Hi all,

chiming into the discussion around the isc-dhcp removal.

The Debian Edu mainserver heavily depends on isc-dhcp-server, esp. its
LDAP-backend feature. A last-minute removal will break the Debian Edu
mainserver installation that we currently have.

I can target the Debian 14 release cycle to port over to KEA (or with
love accept an MR to switch Debian Edu mainserver over to KEA). But on
such short notice, I think that the request is problematic for our
users.

Please reconsider!
Mike

Hi,

this bug also affects more packages that are not in the reverse dependency.
Several packages call dhclient and sometimes with options that are
only available for the isc dhcp client, like -lf ,-pf, -sf

Following packages may be affected by the removal of isc-dhcp from
trixie, because I couldn't find code that supports another dhcp
client/server in those packages:

- chkrootkit_0.58b-4/debian/tests/control
- chrony_4.6.1-2/debian/tests/time-sources-from-dhcp-servers
- cowdancer_0.90/initrd/quick-arm-init.sh
- debian-edu-config_2.12.46/share/debian-edu-config/isc-dhcp-server.service
- debian-edu-router_2.13.0~beta7/fai/config/hooks/instsoft.GATEWAY.sh
- dracut_107-1/modules.d/35network-legacy/module-setup.sh
- firejail_0.9.74-1/src/firejail/dhcp.c
- guix_1.4.0-9/gnu/services/networking.scm
- ifupdown2 in ifupdownaddons/dhclient.py
- ikvswitch_1.0.4/usr/bin/ikvswitch-setup
- madwimax_0.1.1-4/scripts/events/event.sh.generic.in
- octavia_16.0.0-1/octavia/amphorae/backends/utils/interface.py
- python-isc-dhcp-leases_0.10.0-3/isc_dhcp_leases/iscdhcpleases.py
- runit-services_0.9.1/debian/runit-services.runit
- sitesummary_0.1.60/sitesummary-nodes


- debian-edu_2.12.17/debian/control: recommends isc-dhcp-server

These packages use the network-legacy module of dracut which only
supports isc-dhclient:
- kiwi_10.2.22-1/test/data/description.buildservice/appliance.kiwi
- fai_6.4.3/bin/fai-make-nfsroot

Hi,

this bug also affects more packages that are not in the reverse dependency.
Several packages call dhclient and sometimes with options that are
only available for the isc dhcp client, like -lf ,-pf, -sf

Following packages may be affected by the removal of isc-dhcp from
trixie, because I couldn't find code that supports another dhcp
client/server in those packages:

- chkrootkit_0.58b-4/debian/tests/control
- chrony_4.6.1-2/debian/tests/time-sources-from-dhcp-servers
- cowdancer_0.90/initrd/quick-arm-init.sh
- debian-edu-config_2.12.46/share/debian-edu-config/isc-dhcp-server.service
- debian-edu-router_2.13.0~beta7/fai/config/hooks/instsoft.GATEWAY.sh
- dracut_107-1/modules.d/35network-legacy/module-setup.sh
- firejail_0.9.74-1/src/firejail/dhcp.c
- guix_1.4.0-9/gnu/services/networking.scm
- ifupdown2 in ifupdownaddons/dhclient.py
- ikvswitch_1.0.4/usr/bin/ikvswitch-setup
- madwimax_0.1.1-4/scripts/events/event.sh.generic.in
- octavia_16.0.0-1/octavia/amphorae/backends/utils/interface.py
- python-isc-dhcp-leases_0.10.0-3/isc_dhcp_leases/iscdhcpleases.py
- runit-services_0.9.1/debian/runit-services.runit
- sitesummary_0.1.60/sitesummary-nodes


- debian-edu_2.12.17/debian/control: recommends isc-dhcp-server

These packages use the network-legacy module of dracut which only
supports isc-dhclient:
- kiwi_10.2.22-1/test/data/description.buildservice/appliance.kiwi
- fai_6.4.3/bin/fai-make-nfsroot

...

I believe guix is a false positive. Guix does not use dhclient from
Debian, guix is a package manager that has references to dhclient as
packaged in guix itself.

live well,
  vagrant

On Thu, 22 May 2025 20:46:34 +0200 Sebastian Ramacher <sramacher@debian.org> wrote:

Hi Sebastian,

I'm a bit surprised about the timing of the removal, is this the final
call about the severity from Release Team?

What is the default replacement for the client? and for the server?
I looked at the discussion on -devel and I'm still unsure..
dhcpcd-base + dhcpcd and kea?
without this info I'm not able to decide what to do for runit-services;
there are 3 services for isc-*, two in bookworm, and none for
alternatives so I guess it will be a regression for runit users.

what about isc-dhcp-keama? are we going to remove that when a relevant
share of users still have to do the migration?

Overall I think it would work better if the removal is done at the
beginning of the forky cycle.  A release note could help pushing users
towards alternatives and leave us a proper time to test the new
defaults. Could you reconsider?

Best,
Lorenzo

Hi,

Santiago wrote:
 > While I consider that users of isc-dhcp-{client,server} should migrate
 > to alternative implementation, I think it is too late now to ask for
 > the removal of isc-dhcp, being so close to release trixie.

I very much agree with the above.

Sebastian wrote:
 > Except for fai-quickstart all reverse dependencies have MRs.

This is unfortunately, not correct. I don't have an MR for ikvswitch for
example. It may be not so hard to fix, but it's still annoying and
dangerous to have to rush it. This may lead to unforeseen bugs.

Thomas Lange wrote:
 > isc-dhcp is the reference implementation of a DHCP server and still
 > used by nearly 8000 users (see popcon), but the main replacement
 > called kea has only around 180 installations.

Switching to Kea is really not strait forward. Its configuration file is
very different from isc-dhcpd. Same with dnsmasq: it's completely different.

At the end, it's IMO a decision that Santiago should be taking. He's the
only one that can have a clue if it's possible to support isc-dhcp for
security for even more time, and without support from upstream. And he
seems to be ok with the idea. So why not? It wouldn't be a first time
that Debian takes care of a package without upstream support.

Also, I don't think we'll be alone. I wouldn't be surprised, if major
other distros would also publish patches if there was a CVE, considering
the current number of users.

Cheers,

Thomas Goirand (zigo)

related upstream (stalled) PR:

https://github.com/CumulusNetworks/ifupdown2/pull/253

note that ifupdown2 currently only Suggests isc-dhcp-client, while DHCP
support is optional in a technical sense (Recommends might still have
been a better fit), it is quite important for many setups, so dropping
it altogether is not really an option IMHO.

I'll try to get progress on that (or a similar) PR going again to allow
ifupdown2 to drop its usage of isc-dhcp-client in favor of one or more
more suitable client implementations for Forky, but I think there is no
(reasonable) solution for Trixie other than keeping isc-dhcp-client
around (with no security support).

Hi,

ifupdown2 doesn't have any plan to provide support for a new DHCP client.
We are open to community proposal/PR to add support for a new client.

Julien

this is only used for autopkgtesting, any other dhcp server could be
used (i wont bore you with the details) -- given the lack of time, and
need for a sponsor, id just drop that bit of the test for trixie

having said that, i agree with the several others who have said it
seems clearly better for users to leave isc-dhcp as unsupported in
trixie and give a clearer message in release-notes that it will be
gone in forky: if someone is using isc-dhcp for their network i'd
imagine it would make them rather unhappy to find out they need to
transition as part of an upgrade

Hi

Bug severity and removal are two different topics. But unless the
security team re-evaluated their position on support for isc-dhcp, this
is a bug of serious severity. Security team, has your viewpoint on
isc-dhcp changed?

Depends(tm). Since runit-services also contains a service for
network-manager, the answer could also be "the network-manager internal
DHCP client".

The source package could be changed to only build that source package.

Cheers

Hi,

the FAI packages would be affected by an isc-dhcp removal as follows:

- for fai-quickstart the dependency can easily be removed
- For almost all FAI environments we need to create the nfsroot which
  uses the network-legacy module of dracut, that needs dhclient.
  Without a nfsroot most things will not work.
- The default FAI installation environment is a network installation which
  uses the network-legacy module, that needs dhclient.
  dracut supports other network modules for e.g. systemd-networkd,
  but currently FAI is sticked to network-legacy.
- The FAI installation additional calls dhclient using the option -sf for
  calling a FAI specific script file to receive optional settings without
  setting the network. Not sure if other dhcp clients support this and
  if the FAI specific script will still work.
- FAI provides a ready-to-go config script for a FAI server (inlcuding
  a sample ISC dhcpd.conf) that sets up the ISC DHCP server. This
  example would not work any more.

client: dhcpcd-base
relay: dnsmasq
server: dnsmasq or kea

Martin-Éric

Am Tue, Jun 03, 2025 at 09:44:42AM +0200 schrieb Sebastian Ramacher:

We marked it as unsupported a long time ago, but whether this means
that it not should not be part of trixie is an orthogonal question.
We have other packages in trixie and earlier releases which are not
covered by security support (e.g. qtwebkit/qtwebengine).

Anyone using it can make their own call what the lack of security
support means for their deployment, there's certainly some use cases
where a lack of security updates is still perfectly fine.

Any for anyone who this isn't, there's the possibility to move from
ISC DHCP to Kea within bookworm given it ships both.

From my PoV this could also be handled by
- tag #1106121 trixie-ignore
- maybe add a specific note to the release notes to make the lack
  of updates more visible than just src:debian-security-support
- update the package to just build the DHCP relay shortly after
  trixie is released (to avoid having the same discussion two months
  before the forky release). And remove it for good when a replacement
  has emerged for the DHCP relay.

Cheers,
        Moritz

    > We marked it as unsupported a long time ago, but whether this means
    > that it not should not be part of trixie is an orthogonal question.
Thanks for this info.
So there's not strict rule to remove the package, esp. so late in the
release process.
I've collected some feedback from users of FAI that uses ISC dhcp, and
most are afraid of the complexity of KEA and only one started slowly
the migration to dnsmasq. See
https://lists.uni-koeln.de/pipermail/linux-fai/2025-May/thread.html

I think the best solution for the users would be to not remove the
packages from trixie.

    >> From my PoV this could also be handled by
    > - tag #1106121 trixie-ignore
Perfect. Who can/should set this tag? The package maintainer or only
the release team?

    > - maybe add a specific note to the release notes to make the lack
    >   of updates more visible than just src:debian-security-support
Also a good point.

    > - update the package to just build the DHCP relay shortly after
    >   trixie is released (to avoid having the same discussion two months
    >   before the forky release). And remove it for good when a replacement
    >   has emerged for the DHCP relay.
I'm not sure if that helps, if it's worth to keep the dhcp relay but
not the server. The popcon of isc-dhcp-relay is 80 compared to 8000 for
isc-dhcp-server.

Am Tue, Jun 10, 2025 at 02:22:18PM +0200 schrieb Thomas Lange:

It's up to the release team.

Kea doesn't implement a DHCP relay functionality, hence the trimmed
down source package.

Cheers,
        Moritz

Hi,

I agree with all three point. The previous Release Notes also covered it
[1] and already predicted it would be unsupported security wise, so
people have been warned. <sarcasm>Somehow I have the feeling not
everybody reads and remembers the Release Notes.</sarcasm>

Paul

[1]
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#deprecated-components

As far as I can tell, also the debian-installer is involved.

Contents-udeb-amd64.gz has this:
usr/sbin/dhclient
debian-installer/isc-dhcp-client-udeb
usr/sbin/dhclient-script
debian-installer/isc-dhcp-client-udeb

Paul

Hi Lorenzo et al.,

I don't think runit-services needs to do anything except remove at
leisure the service definitions for packages that have already been
removed from the archive?

A service directory for the server replacements would be nice instead of
fallback to initscript of course. Personally I'm not using the
replacements so don't have one to contribute yet.

And I wouldn't expect new clients to get added unless they have service
definitions for other init systems, as ifupdown etc. are the way to use
them generally - hence the disablement of the dhclient service directory
previously.

I'm glad this seems to have been the decision lower down the thread.

Personally I will miss both the server and the client. I don't like the
way the replacement client (so far as I am aware) combines IPv4 and IPv6
behaviour when they are mostly independent concerns.

Andrew

Hi debian-boot,

I hope you are aware that isc-dhcp is EOL and this is not news to
you.

I have no idea what the status is here. Does d-i still use the
isc-dhcp-client udeb? Can it be dropped?

Best,
Chris

Hello,

Chris Hofstaedtler, le lun. 05 janv. 2026 21:16:15 +0100, a ecrit:

It is still used in the hurd case (porting dhclient is in progress), but
we fetch it from the unreleased suite, not sid, so concerning hurd-any,
it's fine to remove it from sid.

Samuel

Hi,

Chris Hofstaedtler <zeha@debian.org> (2026-01-05):

Very quick note without checking the whole bug log or actual history…

    Package: netcfg
    Depends: ${shlibs:Depends}, ${misc:Depends},
    […]
            isc-dhcp-client-udeb [kfreebsd-any hurd-any],

which would match my vague recollection: this was only ever a non-Linux
port thing, while udhcpc (found in busybox-udeb) is used on Linux.

Dropping would lgtm.


Cheers,

Hi Cyril, Samuel,

Thanks, I should have spotted that somewhere.

To avoid dropping it right now and breaking the hurd installer,
maybe isc-dhcp-client-udeb can be ignored in the key package set
calculation. Then src:isc-dhcp can fall out of testing when
"possible".

Paul - can you take a look at that option?

Best,
Chris

Hi,
See below the output of dak when I try to remove src:isc-dhcp from
testing. The only reason why it's not removed seems to be that it's a
key package. Without reverse dependencies, the only reason it can be a
key package is because of the udeb. With the d-i blessing for removal
from testing, I'll add it to the list of explicit non-key packages and I
expect autoremoval to happen soon.

Paul

elbrus@coccia:~$ dak rm --no-action -RB --suite testing isc-dhcp
Will remove the following packages from testing:

isc-dhcp-client | 4.4.3-P1-8 | amd64, arm64, armhf, i386, ppc64el,
riscv64, s390x
isc-dhcp-client-ddns | 4.4.3-P1-8 | amd64, arm64, armhf, i386, ppc64el,
riscv64, s390x
isc-dhcp-client-udeb | 4.4.3-P1-8 | amd64, arm64, armhf, i386, ppc64el,
riscv64, s390x
isc-dhcp-common | 4.4.3-P1-8 | amd64, arm64, armhf, i386, ppc64el,
riscv64, s390x
isc-dhcp-dev | 4.4.3-P1-8 | amd64, arm64, armhf, i386, ppc64el, riscv64,
s390x
isc-dhcp-keama | 4.4.3-P1-8 | amd64, arm64, armhf, i386, ppc64el,
riscv64, s390x
isc-dhcp-relay | 4.4.3-P1-8 | amd64, arm64, armhf, i386, ppc64el,
riscv64, s390x
isc-dhcp-server | 4.4.3-P1-8 | amd64, arm64, armhf, i386, ppc64el,
riscv64, s390x
isc-dhcp-server-ldap | 4.4.3-P1-8 | amd64, arm64, armhf, i386, ppc64el,
riscv64, s390x

Maintainer: Debian ISC DHCP Maintainers <isc-dhcp@packages.debian.org>
------------------- Reason -------------------

----------------------------------------------

Checking reverse dependencies...
No dependency problem found.

images.

More precisely: "debci setup" uses lxc-templates to build the
autopkgtest LXC images, and the lxc templates wants to install
isc-dchp-client. So that breaks the daily build of eg. Salsa CI's
autopkgtest LXC images:

https://salsa.debian.org/salsa-ci-team/autopkgtest-lxc/-/pipelines/1021471

I suppose ci.debian.net is affected as well.

I've found that replacing isc-dhcp-client with dhcpcd-base (as it
Provides: dhcp-client, just like isc-dhcp-client) _seems_ to work. Maybe
others can comment if they think it's the right solution, and in that
case it's an easy fix in the package lxc-templates.

I also noticed that the Debian builds at
https://jenkins.linuxcontainers.org/job/image-debian/ broke as well.

These builds use distrobuilder, the modern replacement for
lxc-templates, and they still install isc-dhcp-server. However I looked
at the recipes and I have the impression that these images use
systemd-networkd, so maybe isc-dhcp-client shouldn't be installed at
all, after all. I have opened an issue upstream to clarify:

https://github.com/lxc/lxc-ci/issues/956

Best,

Hi,


There is bug #1125011 for that, maybe follow up there?

Paul