Package Timestamp Change
By Tim Hall / Aug 20, 2021 / Chronograf, InfluxDB, Telegraf, Release Notes
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.