The announcement of ROS ESM made me wonder: is Canonical essentially forking Kinetic, Melodic and Noetic?
The Ubuntu blog wasn’t completely clear about it. It states:
Even if your ROS distribution hasn’t reached its End-Of-Life (EOL), you can count on backports for critical security updates and common vulnerabilities and exposures (CVE) fixes for your ROS environment.
[…]
With ROS ESM, we have also included security and updates PPAs for core ROS packages. We will continue to backport critical security updates and bug fixes for ROS, for EOL and non-EOL distributions starting with ROS 1 Kinetic.
As security is such a cross-cutting and ubiquitous concern, will those fixes be contributed upstream as well?
Especially in cases where “your ROS distribution hasn’t reached its End-Of-Life” yet, that would seem to be the proper thing to do.
Edit: previously I’d tag @kyrofa, but I guess @SidFaber is now the person to ask?
To briefly answer your main question, yes.
Doing so allows us to have full control over the packages supported in ESM. Not only the source code but also the build/release farm. So that we can make sure that e.g. fixes do land and prevent API/ABI breakage.
We are indeed contributing fixes upstream for non-EOL distros and we’ve actually started doing so a while back with Kinetic with dozens of fixes and a couple (still) opened tickets.
Please let us know if you have any further question
The OSS side of me isn’t too excited about forks (we have way too much fragmentation already I believe), but from a business perspective I can understand.
I’ll probably send an email to the contact address mentioned in the blog post, but are these forks full forks (ie: cp -r rosdistro/{kinetic,melodic,noetic} canonical_rosdistro) or is it limited to specific REP-142/REP-150 variants?
Thanks for your interest @gavanderhoorn. Just wanted to make sure you’ve seen the OR & Canonical partnership announcement to go with the blog post on What is ROS Extended Security Maintenance? Our goal is not to be another fork, it’s all about keeping your deployed robot secure for up to a decade. The partnership & joint support agreement with OR is key to making this work.
For EOL distributions we backport security updates from upstream; this works hand-in-glove with ESM for Ubuntu to keep your entire platform (e.g., python 2, OpenCV3) patched. For non-EOL distributions, we’re currently focusing on ABI breakage: rather than simply halting updates, you’ll have an option to run your ABI-compatible release but still receive backported critical security updates.
Regarding scope, we started with REP-142 ros_base and are working towards desktop (working through some hairy dependencies hidden in there). We’re generally following a process similar to the Ubuntu Main Inclusion Process to make sure what we provide can be officially maintained, supported and secured.
