[Bug 1683415] [NEW] do-release-upgrade unecessarily disables PPA's which are not release specific

[Daniel Bull]

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
Foundations Bugs, which is subscribed to ubuntu-release-upgrader in
Ubuntu.
https://bugs.launchpad.net/bugs/1683415

Title:
  do-release-upgrade unecessarily disables PPA's which are not release
  specific

Status in ubuntu-release-upgrader package in Ubuntu:
  New

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://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.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1683415/+subscriptions