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
[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 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.
