cannot proceed through dist-upgrade if using unsigned PPA packages

Bug #218086 reported by Martin Pool on 2008-04-16
12
Affects Status Importance Assigned to Milestone
synaptic (Baltix)
Undecided
Unassigned
synaptic (Ubuntu)
Undecided
Unassigned

Bug Description

I'm running Hardy, and I also have bzr installed from a PPA.

Software Update recently prompted me to do a partial distribution upgrade.

Because of bug 125103, packages from PPAs are not signed. So I get this error:

  http://launchpadlibrarian.net/13447831/2008-04-15-151328_498x411_scrot.png

Within the GUI, there's no way to proceed. It would be nice to either allow me to continue and install the packages without checking their signatures, or do the upgrade for everything but the unsigned packages.

This blocks people upgrading eg hardy->intrepid if they're using any PPA packages.

William Grant (wgrant) wrote :

Isn't it intended to respond nastily when third-party repositories are enabled?

Bryan Donlan (bdonlan) wrote :

@William Grant:
I see no reason to punish the user just because they chose to use a third-party repository. Warn them, sure, but allow the user to override, or at least allow them to continue with whatever else can be done.

Martin Pool (mbp) on 2008-10-31
Changed in synaptic:
status: New → Confirmed

On Wed, Nov 26, 2008 at 1:49 AM, Russel Winder
<email address hidden> wrote:
> Jelmer,
>
> On Tue, 2008-11-25 at 14:51 +0100, Jelmer Vernooij wrote:
>> Am Dienstag, den 25.11.2008, 11:02 +0000 schrieb Russel Winder:
>> > I just tried upgrading one of my machines from Hardy to Intrepid.
>> > However the presence of the bzr and bzrtools 1.9 packages from Bazaar
>> > PPA causes the upgrade manager to complain that these packages cannot be
>> > authenticated and terminates the attempted upgrade.
>> >
>> > Is this the expected behaviour -- is it necessary to uninstall bzr and
>> > bzrtools prior to an attempted upgrade?.
>> You should be able to tell it to continue without authenticated
>> packages. Packages from PPA are never authenticated (GPG signed).
>
> Update manager offers a dialogue box explaining the the packages cannot
> be authenticated, it offers one button "OK". When you press it it
> terminates and rolls back the changes.
>
> Clearly the update manager people at Canonical refuse to accept that any
> package be allowed not to be authenticated. Bit of a bugger for the PPA
> people at Canonical I think.
>
> In the end I had to remove all of bzr to get it to upgrade. :-(((

Yes, I know, it's a very poor interaction between a bug in synaptic
<https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/218086> and
the fact that PPAs are not signed
<https://bugs.launchpad.net/soyuz/+bug/125103>. The second bug is
promised to be fixed very soon.

For a regular dist-upgrade you can work around this by running it from
the command line rather than the gui, but I'm not sure if that's
enough for upgrading from one release to the next.

--
Martin <http://launchpad.net/~mbp/>

description: updated
Julian Edwards (julian-edwards) wrote :

I was tempted to mark this a dupe of bug 125103 but I guess this is a separate issue because it's not just unsigned PPAs it will barf on.

In any case, we're very close to fixing 125103 so hopefully some of the pain will go away soon.

Russel Winder (russel) wrote :

Martin,

On Wed, 2008-11-26 at 11:01 +1100, Martin Pool wrote:

> Yes, I know, it's a very poor interaction between a bug in synaptic
> <https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/218086> and
> the fact that PPAs are not signed
> <https://bugs.launchpad.net/soyuz/+bug/125103>. The second bug is
> promised to be fixed very soon.

So it might happen before the heat death of the universe ;-)

> For a regular dist-upgrade you can work around this by running it from
> the command line rather than the gui, but I'm not sure if that's
> enough for upgrading from one release to the next.

I have to admit I am still an Aptitude user since, as far as I know,
Synaptic still doesn't have the dependency tracking that aptitude has.
I hesitate to do the upgrade by editing sources.list myself and doing a
dist-upgrade since the upgrade manager generally seems to do various
extra fiddling.

The algorithm appears to be:

 remove Bazaar
 upgrade Ubuntu
 reinstall Bazaar

This appears to work fine on systems that don't have NFS mounted
filestore -- Network manager, NFS and NIS seems to have a fight on
systems with NFS mounted filestore meaning it takes about 2 hours for a
reboot to work :-(( Nothing to do with Bazaar though, so I'll have to
find another list to moan about that on :-)

--
Russel.
====================================================
Dr Russel Winder Partner

Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084
London SW11 1EN, UK. m: +44 7770 465 077

Martin Pool (mbp) wrote :

In bug 125103, Savvas Radevic <email address hidden> wrote:

> Martin, unfortunately users are always suggested to uncheck any third-party repositories before upgrading to a new release. Anything that doesn't belong to the original distribution can and probably will create problems.
> But I agree that it is an issue that must be solved somehow - perhaps explaining that the users should remove/disable any third-party software repositories?

I think it would be reasonable for the GUI to say: "you can't upgrade with these repositories. do you want me to disable them, or cancel?"

> My opinion is that unsigned packages (or unsigned packages list)
> shouldn't be allowed to be installed, as it is a common security risk
> that I believe none of us wishes to take.

I think the current Ubuntu tradeoff of making them allowed but discouraged is reasonable; you can hardly 'disallow' actions in an open system. But this bug has a much smaller scope: the tool does not implement its current design intention, and leaves the user stuck.
--
Martin <http://launchpad.net/~mbp/>

> I think it would be reasonable for the GUI to say: "you can't upgrade
> with these repositories. do you want me to disable them, or cancel?"
Either way, they will have to restart the upgrade/installation :)

> I think the current Ubuntu tradeoff of making them allowed but discouraged is reasonable; you can hardly 'disallow' actions in an open system. But this bug has a much smaller scope: the tool does not implement its current design intention, and leaves the user stuck.
True, can't argue with that!

David Fraser (davidf) wrote :

I don't get this aversion to third-party repositories. Surely it should be at least possible for third-party repositories to provide the appropriate packages to ease an upgrade? And if so, why on earth would we want to prevent them from doing that?

Savvas Radevic (medigeek) wrote :

> I don't get this aversion to third-party repositories. Surely it should
> be at least possible for third-party repositories to provide the
> appropriate packages to ease an upgrade? And if so, why on earth would
> we want to prevent them from doing that?

Because:
a) they are third-party repositories, not used in Ubuntu and not
supported officially.
b) they can and probably will create problems while upgrading.
c) people usually report the problems of the third-party repositories
and connect it to Ubuntu packages and forget to mention that they even
use third-party software. This can be really confusing for the
developers and the bug squad.

However, I'm just providing my opinion about this, I'm not an official
representative - Ubuntu might has a different stand on this :)

Martin Pool (mbp) wrote :

Just to be clear, this bug is about a much smaller issue than whether third-party repos should be supported during upgrade, on which I can see good points either way.

For a "real" distribution upgrade, kicked off by clicking the "new distribution version available" button in update-manager, you get a dialog saying that third-party sources will be disabled automatically, and you can reenable them through the software sources dialog. (Tested upgrading intrepid->jaunty.) I think just the same thing should happen during the 'partial upgrade' that update-manager sometimes runs, rather than it just aborting.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers