This evening the ROS GPG keys inadvertently expired and caused apt failures for a number of users. In our response to a security incident two years ago we deployed a new GPG key with a 2 year expiration however; we neglected to set a reminder to extend the expiration date of a GPG key prior to its expiration. A full description of the security breach and the remediation can be found in this ROS Discourse post.
The expired GPG key is used in a number of places, including the ROS 1 and ROS 2 build farm. A quick solution to this problem is to simply extend the expiration date of the offending key, however, this also requires issuing a new public key for the extended private GPG key. This is where the issue impacts users, re-issuing the public GPG key requires that users also download, install, and use the public key. Thankfully, this issue represents only a temporary service outage, and has no significant security implications.
Due to the necessity of updating the public key several other ROS services were impacted by this issue. Public keys had to be updated on build.ros.org, build.ros2.org, ROS infrastructure, ROS buildfarm, ROS distro, packages.ros.org, and the Ubuntu key server. While these changes were trivial, issuing and reviewing the pull requests, redeploying the services, and allowing the changes to propagate takes some time.
At this time all of the changes have been deployed and tested and are now working. The new GPG key is set to expire in five years (and more than one reminder has been set). To fix this issue users need to update the public key used for ROS apt repositories. To do this for ROS 1 installations you need to run a single command:
curl -s https://raw.githubusercontent.com/ros/rosdistro/master/ros.asc | sudo apt-key add -
For ROS 2 installations you will need to run this command:
sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg
Complete example instructions for Rolling can be found here.
We apologize for any inconvenience this may have caused ROS users over the long holiday weekend. While the impact of this issue is broad, we hope the remedy for our end users is fairly straightforward. In the coming days we will post a full post-mortem of the incident along with the corrective actions we plan to take to prevent this from happening again. The Open Robotics team values our users, and we strive to provide safe, secure, and reliable binary packages to the ROS community.