do-release-upgrade unecessarily disables PPA's which are not release specific
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-release-upgrader (Ubuntu) |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
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://
deb http://
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.)
description: | updated |
Changed in ubuntu-release-upgrader (Ubuntu): | |
importance: | Undecided → Wishlist |
tags: | added: rls-aa-incoming |
tags: |
added: rls-ee-incoming removed: rls-aa-incoming |
Status changed to 'Confirmed' because the bug affects multiple users.