We’ve been using the ROS gpg key for many years now and unfortunately it’s now considered obsolescent due to advancements in encryption technology.
At OSRF we use the ROS key to sign the debian repositories. This is the key that you need to import before you can apt-get install ROS packages. We are planning to generate a new more modern key following the new standards.
There are several different ways to deploy the key however. The two methods that we have come down to are as follows.
- Replace the existing key and resign the repos as they stand w/o changing anything.
- Create a new repository next to the existing repository for new packages (Kinetic and newer) and sign the new repository with the new key.
There are tradeoffs to both. Here are some of the highlights as follows.
Approach 1 Tradoffs
- The existing repositories will be more secure.
- All existing users will be required to add the new key on any existing system.
- New users will simply use the new key when installing.
Approach 2 Tradeoffs
- The existing repositories for jade and older will be unchanged.
- Existing users will not have to do anything.
- The security of the old repository will not be improved.
- New users will follow slightly different installation instructions for kinetic. (new source path and gpg key)
- Kinetic beta testers will need to update their apt sources and install the new key.
- We would take this opportunity to follow a more standard repository directory structure and naming conventions.
Request for feedback
Overall 1 is more secure, but more disruptive. Option 2 will change things going forward in a non-disruptive way but the cost of that lack of disruption is to not make installation on existing systems more secure.
We’d like to know your thoughts on whether we should use approach 1 or 2.
If you’d like to know more about the underlying issue here are some links:
- https://juliank.wordpress.com/2016/03/14/dropping-sha-1-support-in-apt/ Enforced on newer versions of apt
- https://wiki.debian.org/Teams/Apt/Sha1Removal We’re not the only repo with issues.
- https://en.wikipedia.org/wiki/SHA-1 General overview of SHA-1
- https://blog.qualys.com/ssllabs/2014/09/09/sha1-deprecation-what-you-need-to-know Related to SSL certificates (related but not the same)
- https://konklone.com/post/why-google-is-hurrying-the-web-to-kill-sha-1 Another readable summary of the implications wrt to SSL