Explanation of recent package timestamp changes on repos.influxdata.com

What happened?

On August 16th 2021 at approximately 17:30 UTC, we initiated a change via automation that is used to keep our package repositories updated. An edge case in the logic caused an unexpected, non-idempotent change to signatures for InfluxDB, Telegraf, and Chronograf RPM packages. These signature changes were timestamp related only, and the contents of the packages themselves did not change.

Which specific packages were affected?

  • chronograf-1.9.0…rpm for x86_64, arm64, armel, i386
  • influxdb-1.8.9…rpm for aarch64, x86_64, armel, armv7hl, i386
  • influxdb2-2.0.8…rpm for aarch64, x86_64
  • telegraf-1.19.2-1…rpm for aarch64, x86_64, armel, i386

How do I verify packages?

An example of how this can be verified:

# Using influxdb 1.8.9 on Centos 7 for this example
# Download the rpm from the package repository
$ cd /home/centos
$ cat <<EOF | sudo tee /etc/yum.repos.d/influxdb.repo
name = InfluxDB Repository - RHEL \$releasever
baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
$ sudo yum install --downloadonly --downloaddir=/home/centos/influxdb.repo.rpm influxdb

# Download rpm from dl.influxdata.com
$ curl -o influxdb.s3.rpm https://s3.amazonaws.com/dl.influxdata.com/influxdb/releases/influxdb-1.8.9.x86_64.rpm

# Use rpm to check and compare the signatures on each file
$ rpm -Kv ./influxdb.s3.rpm
    Header SHA1 digest: OK (911f8471b1220ae2ea615a4415b791164f254b3a)
    MD5 digest: OK (fc25eacdd74fd71f019e4128a3f19308)
$ rpm -Kv ./influxdb.repo.rpm/influxdb-1.8.9.x86_64.rpm
    Header V4 RSA/SHA256 Signature, key ID 2582e0c5: OK
    Header SHA1 digest: OK (911f8471b1220ae2ea615a4415b791164f254b3a)
    V4 RSA/SHA256 Signature, key ID 2582e0c5: OK
    MD5 digest: OK (fc25eacdd74fd71f019e4128a3f19308)

What are you doing to prevent this from recurring?

Under normal circumstances, we will not re-sign packages unless we are rotating our signing keys as part of standard procedure. We have since patched the logic error that triggered this undesirable behavior.