influxdb: Error when installing Influx 1.8 from Debian repo

We’re in the process of rotating our GPG keys and re-generating all the signature files. I’ll leave this issue open until the process is complete.

@psteinbachs The blog post indicates that the signing key was changed. That’s fine, but if I were to make a suggestion, you probably shouldn’t re-sign all your RPMs when the signing key changes. That changes their bits, and makes a perfectly fine release artifact signed using an older key look like it has been subsequently compromised. Even reverting back to the old key will not fix the issue, if it is re-signed, because the timestamp when signed the second time will be different from the first and the bits will be different, even with the same key.

If you need to re-sign, I recommend bumping the version or appending a 1-up sequence to the file name (for RPMs, this can be done with the standard RPM naming convention of [name]-[version]-[release].[arch].rpm and bumping the Release: sequence number in the SPEC file), so the previous release artifact’s bits don’t change for a given file name, and the same file downloaded at different times will always have the same bits. This is how Fedora tags release artifacts; each one only gets signed once, and any change and re-sign needs to have a version/release bump.

See also: apache/fluo-muchos#381 and apache/fluo-muchos#391

Same goes for Ubuntu 20.04:

Err:3 https://repos.influxdata.com/ubuntu focal InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 684A14CF2582E0C5
Reading package lists... Done
W: GPG error: https://repos.influxdata.com/ubuntu focal InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 684A14CF2582E0C5
E: The repository 'https://repos.influxdata.com/ubuntu focal InRelease' is not signed.

Honestly, I can’t believe InfluxDB still doesn’t know how to correctly sign artifacts, and continues to re-sign old release artifacts when keys are rotated, but without bumping the version of the release artifact. This makes their artifacts look like they have been compromised when a particular version’s bits change. I would have thought this would be fixed at some point in the past 2 years since it was reported here, but I guess not. It seems the goal is to have all their downloads signed with the current key, but that’s not how anybody else on the internet manages old release artifacts, and it’s highly suspicious… because users can’t easily tell if something changed or it was just re-signed. Honestly, this is really dumb behavior.

@mephmanx @beinbliss

@ctubbsii

Hello, I rotated the signing keys in our package repositories this time which included re-signing the RPMs. Our initial thought was that re-signing the packages with the new key would signal that “InfluxData trusts these packages.” However, I understand your perspective and I think it’s the correct one. I wanted to comment to let everyone know that I’m updating our procedure and documentation so that incrementing the package revision/release is part of the key rotation process.

I also would like to apologize for the issues that this has caused.

@jeffreyssmith2nd you should probably update the install instructions on your website as they still use the old key. I just ran into this. Very frustrating when the install instructions don’t work

FYI if you’re like me and gave up on installing influxDB after this error, but you want to undo your mistake, you can delete /etc/apt/sources.list.d/influxdata.list.

Below are my personal thoughts, and not necessarily representative of InfluxData:

I believe that there are two scenarios. The first scenario is where the signing key expires and a new one is installed. In that scenario, we could just deprecate the old key and not re-sign the packages. The other scenario is where the signing key is compromised. As mentioned here, the CircleCI data breach is what incited this last key rotation. In this scenario, we will leave the original packages available (and untouched), but also provide a re-signed and package-revision incremented package.

I understand that this will cause some machines running to attempt an upgrade. However, I suspect that’s a minor nuisance compared to previous issue of mutating the package bits. If they’re not pulling the latest package already, they’re likely using a versionlock plugin. In which case, pushing a package-revision isn’t likely to cause an upgrade.

I notice the influxdb.key in https://repos.influxdata.com/ was modified a few hours ago, which probably isn’t a coincidence