Package Timestamp Change

By Tim Hall / Product
Aug 20, 2021

Navigate to:

What happened?

On August 16, 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
[influxdb]
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
EOF
$ 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
./influxdb.s3.rpm:
    Header SHA1 digest: OK (911f8471b1220ae2ea615a4415b791164f254b3a)
    MD5 digest: OK (fc25eacdd74fd71f019e4128a3f19308)
$ rpm -Kv ./influxdb.repo.rpm/influxdb-1.8.9.x86_64.rpm
./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 we 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 our standard procedure. We have since patched the logic error that triggered this undesirable behavior.