Public bug reported: The upgrade process from 16.10 to 17.04 (for example) performed by both the GUI and do-release-upgrade CLI methods, disables 3rd party PPAs. Whilst it is understandable that PPAs targeted specifically at the release which is being upgraded should be disabled, it seems unnecessary to disable those which are release independent.
For example these are typical PPAs which are release independent and are currently unnecessarily commented out by the upgrade process (as can be seen they state "stable" rather than "yakkety" on the config line): deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main deb http://repository.spotify.com/ stable non-free Since disabling PPAs puts a users machine at significant risk (because packages installed by those PPAs are left without security updates) it would seem preferable to minimise the number of disabled PPAs wherever possible. Modifying the PPA disabling process to first check the configs release code name matches the release being upgraded from (in this case yakkety) before commenting it out would dramatically reduce this number and improve security considerably. Whilst its appreciated that the long term solution to this will be snap packages, it seems that the recent trend towards installers automatically adding PPAs has left novice users unaware of what PPAs are, putting them at even greater risk of running unpatched packages. The upgrade process should target a similar skillset level and where possible not require the user to have to deal with PPAs directly - the modification described above would be a step towards that. (...it would at least improve on the current situation which is (for example) potentially leaving millions of unskilled Linux users running unpatched copies of Google Chrome.) ** Affects: ubuntu-release-upgrader (Ubuntu) Importance: Undecided Status: New ** Description changed: The upgrade process from 16.10 to 17.04 (for example) performed by both - the GUI and do-release-upgrade CLI methods, disable 3rd party PPAs. + the GUI and do-release-upgrade CLI methods, disables 3rd party PPAs. Whilst it is understandable that PPAs targeted specifically at the release which is being upgraded should be disabled, it seems unnecessary to disable those which are release independent. For example these are typical PPAs which are release independent and are currently unnecessarily commented out by the upgrade process (as can be seen they state "stable" rather than "yakkety" on the config line): deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main deb http://repository.spotify.com/ stable non-free Since disabling PPAs puts a users machine at significant risk (because packages installed by those PPAs are left without security updates) it would seem preferable to minimise the number of disabled PPAs wherever possible. Modifying the PPA disabling process to first check the configs release code name matches the release being upgraded from (in this case yakkety) before commenting it out would dramatically reduce this number and improve security considerably. Whilst its appreciated that the long term solution to this will be snap packages, it seems that the recent trend towards installers automatically adding PPAs has left novice users unaware of what PPAs are, putting them at even greater risk of running unpatched packages. The upgrade process should target a similar skillset level and where possible not require the user to have to deal with PPAs directly - the modification described above would be a step towards that. (...it would at least improve on the current situation which is (for example) potentially leaving millions of unskilled Linux users running unpatched copies of Google Chrome.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1683415 Title: do-release-upgrade unecessarily disables PPA's which are not release specific To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1683415/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
