influxdata-archive-keyring creates influxdata.list with compat key on modern Debian (.sources users)

1

Hi InfluxData team,

First of all, thanks for maintaining the Debian packages — I’m writing this in the hope of clarifying what looks like a packaging edge case on modern Debian systems, and to check if the behavior is intentional or a bug.

Environment

•	Debian 13 (Trixie)

•	APT configured using the modern *.sources* format

•	InfluxData repository configured with *Signed-By pointing to influxdata-archive.gpg*

Observed behavior

When installing or upgrading influxdata-archive-keyring, the package creates a file named:

“/etc/apt/sources.list.d/influxdata.list”

This file references the repository using influxdata-archive_compat.gpg.

On systems that already have a .sources entry for the same repository using influxdata-archive.gpg, APT reports a Signed-By conflict and fails. This also breaks unattended-upgrades.

Why this is confusing

According to your own documentation on key rotation (Package Signing Key Rotation blog), users should always use influxdata-archive.key unless running an older distribution that does not support verifying subkeys (for example Debian Buster, Ubuntu 18.04, or RHEL/CentOS 7).

Debian 13 fully supports subkey verification and should not require the _compat key.

Additional observations

If the file influxdata.list is deleted once by an administrator, dpkg later reports:

“Not replacing deleted config file /etc/apt/sources.list.d/influxdata.list”

and stops recreating it on that host.

This means dpkg eventually stabilizes per system, but fresh systems or systems that never had the file deleted still encounter the conflict, especially during unattended-upgrades.

Questions

1\. Is the creation of *influxdata.list* intentional on modern Debian systems when a *.sources* file already exists?

2\. Is the use of *influxdata-archive_compat.gpg* on Debian 13 expected behavior?

3\. Would it make sense to either skip creating *influxdata.list* when a *.sources* entry exists, or to use *influxdata-archive.gpg* on modern Debian releases?

I’m happy to provide package versions, logs, or extracted maintainer-script snippets if helpful. I mainly wanted to check whether this behavior is known or expected.

Thanks for your time, and appreciate any guidance.

2

Hi @RikaRD looking into this internally.

3

Excellent, thank you for your feedback!

1 Like
4

Debian 13 is definitely supposed to be using the non-compat key. This was tested on Debian 13 before publishing and I am unable to reproduce now:

$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.2
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

$ wget https://repos.influxdata.com/packages/influxdata-archive-keyring_2025.12.08_all.deb
$ sudo dpkg -i ./influxdata-archive-keyring_2025.12.08_all.deb 
Selecting previously unselected package influxdata-archive-keyring.
(Reading database ... 24206 files and directories currently installed.)
Preparing to unpack .../influxdata-archive-keyring_2025.12.08_all.deb ...
Unpacking influxdata-archive-keyring (2025.12.08) ...
Setting up influxdata-archive-keyring (2025.12.08) ...
Creating config file /etc/apt/sources.list.d/influxdata.list with new version

$ cat /etc/apt/sources.list.d/influxdata.list
deb [signed-by=/usr/share/keyrings/influxdata-archive.gpg] https://repos.influxdata.com/debian stable main

The code to decide on which key to use is in /var/lib/dpkg/info/influxdata-archive-keyring.postinst. On this system, I can see it working like so:

$ sudo sh -x /var/lib/dpkg/info/influxdata-archive-keyring.postinst configure 2025.12.08
+ set -e
+ dpkg-query -W -f=${Version} apt
+ apt_version=3.0.3
+ [ configure = configure ]
+ is_apt_version lt 1.4
+ dpkg --compare-versions 3.0.3 lt 1.4
+ get_influxdata_lists
+ compat=
+ is_apt_version lt 1.8
+ dpkg --compare-versions 3.0.3 lt 1.8
+ proto=http
+ is_apt_version lt 1.5
+ dpkg --compare-versions 3.0.3 lt 1.5
+ is_installed ca-certificates
+ + grep -q ok installed
dpkg-query -W -f=${Status} ca-certificates
+ proto=https
+ echo /usr/share/influxdata-archive-keyring/influxdata.list-https
+ ucf /usr/share/influxdata-archive-keyring/influxdata.list-https /etc/apt/sources.list.d/influxdata.list

What is the output of this command (sudo sh -x /var/lib/dpkg/info/influxdata-archive-keyring.postinst configure 2025.12.08) on your system? If the command output looks the same, I suspect that you may have configured the system sometime in the past to use /etc/apt/sources.list.d/influxdata.list with the compat key (this was the documented procedure up until August of this year) and when ucf prompted on this file when influxdata-archive-keyring was installed, ucf was told to keep the old version (in which case, the package is operating correctly).

5

Thanks — I unpacked the 2025.12.08 package and confirmed the shipped templates are correct on Debian 13:

influxdata.list-https uses signed-by=/usr/share/keyrings/influxdata-archive.gpg and only the *_compat templates use _compat.gpg.

On affected hosts we must have had an older /etc/apt/sources.list.d/influxdata.list (or ucf kept an old version) using _compat.gpg, which then conflicts with our .sources entry using archive.gpg.

So the problem seems to be legacy/ucf state + the package always managing a .list file, even when a .sources file already exists.

Would you consider updating postinst/ucf logic to detect an existing .sources entry for repos.influxdata.com and skip creating/modifying influxdata.list to avoid duplicates?

6

We had considered this, but the problem with this is that it will usually only delay the problem for people since the updated keys are in a location that existing configuration is unlikely to be using and therefore when the existing key expires (which is happening in January), apt will break in a different ways for people. What is present at least guides people to using the managed influxdata.list and if people don’t want that, they can opt out.

7

Thanks — that rationale makes sense, especially with the upcoming expiry in January and the risk of people using older key locations.

In our case we’re intentionally using the modern .sources format and Signed-By with the managed keyring path under /usr/share/keyrings/ (so we do benefit from the keyring package updates). The issue we hit was duplicate source definitions (our .sources plus the managed influxdata.list), and on some hosts legacy influxdata.list content caused a Signed-By conflict.

Would you consider one of these small improvements to make the “opt out” path more robust for modern setups?

  1. If a .sources entry already exists for repos.influxdata.com (or an influxdata.sources file exists), skip creating/updating influxdata.list to avoid duplicates.

  2. Provide a documented opt-out mechanism such as a sentinel file (e.g. “/etc/default/influxdata-repo disable”) that causes postinst to not call ucf for influxdata.list.

This would keep the safe default for most users, while preventing modern .sources users from getting duplicate entries or Signed-By conflicts.

Happy to share exactly what we see in postinst (it currently uses ucf unconditionally and doesn’t detect .sources) and our reproduction steps if useful.

8

influxdata-archive-keyring 2025-12-22 was updated to add information to the file in sources.list on how to opt out of the behavior.