[maemo-developers] [maemo-developers] Re: [maemo-users] 'Locking down' software installation

[From: Marius Vollmer]

Naba Kumar <naba.kumar at nokia.com> writes:

> Marius Vollmer wrote:
>>
>> The goal is to provide system software updates to the user with the
>> property that when the user installs them, we can be reasonably sure
>> that he has the packages on the device that we want him to have, and
>> that he doesn't drift out of this supported configuration by accident.
>>
> First of all, I think I need a well understanding of when a device is
> no longer in 'supported configuration'. You said the meta-package is
> meant to draw that line.

Yes, the meta package is used to implement the lock-down of a device
into supported configurations.

Also, and this might not be very visible with the current behavior of
the Application Manager, the goal is not so much to prevent the user
from doing certain things that Nokia for some reason doesn't approve
of, but to guide him from one supported configuration to the next.

In the past, we had the same issue with supported and unsupported
configurations, but we didn't help people stay inside a supported
configuration.

The question is indeed, what are these supported configurations?
Right now, you have to combine only packages that have been included
in the same release.  You can not combine packages that come from a
number of different releases.

It would be nice to also officially support configurations where
packages come from different releases.  Unlocking every single package
might be too much, but we can think about modularizing the operating
system.

Let's say we have the Core, Browser, and Comm modules.  We still make
releases of all modules at the same times, N, N+1, N+2, etc.  Right
now, we only support Core N, Browser N and Comm N together.  Browser
N+1 plus Core N is not supported, for example.

We could relax that and also support Browser N+1 with Core N and Comm
N, and Comm N+1 with Browser N and Core N+1, and any number of other
combinations.

In the limit we are so confident of our packages that we feel good
about letting users drift into any combination of our packages that is
allowed by their individual dependencies.  That should be the goal, no
doubt about that.

> However, so far my understanding is that blue-pill and the
> associated warning dialogs draw the line.

No, the blue and red pill modes are only operational modes of the
Application Manager, they are not modes of the whole system (and they
shouldn't be).

What warning dialog are you referring to?  Crossing the "This software
might harm your device" dialog should not push users automatically out
of a supported configuration.

The "This software has originally been installed from a different
source" dialog helps against 'roque' packages from non-Nokia signed
repositories, but it doesn't help to restrict the configuration to a
single release.

> I can not install/updgrade any of the system package in blue pill
> mode because Application Manager does not allow it with non
> Nokia-signed packages. That already effectively locks the device in
> 'supported mode', IMHO.

No, since there might be Nokia signed packages available.  Think about
a available release that has not yet been installed.

> When one enters red-pill mode and update a system package AM, shows a
> warning message the package is not from nokia and therefore is not
> supported. Presumably, the whole device also exits warranty/support
> system at that point. Please correct me if I am wrong (not so much of a
> legal expert here).

There are liability issues, I am sure, but they are not really
important for this discussion, I would say.  Whether or not Nokia can
talk itself out of liability or whether or not a device is still in
warranty or not, doesn't really matter if it is too easy to wedge a
device and nobody buys them any more.

>> In other words, when we announce a system update with the words
>> "OS2008 release 2.1 is available.  It upgrades Flash support to
>> Flash 10." we have to be sure that Flash 10 is actually working
>> after the user has installed that update.  Also, the availability
>> of that update must not put those users in danger that decide not
>> to install it.
>
> I understand that applies only in 'supported mode'? Once the user is in
> the wild (either by uninstalling the lock-down meta package, forcing
> upgrades in red-pill mode, or both) Nokia does not care anymore about
> his support. Right?

Hmm, the idea is that the people who do these things know what they
are up to and will not throw the device away in anger, shaking fists
at Nokia.  We should still be nice to them, of course, from hacker to
hacker.

> He took the risk of updating the system pacakges, he then takes the
> risk of making sure it works with available OS2008 update also.

Yes.

> I hope you see the problem with current lock-down. The red-pill mode
> is no longer about opening the 'can' as it used to be (removing the
> meta-package doesn't count because it removes a huge feature from
> the device, i.e. future updatibility).

I think removing the meta package still counts.  You can then use the
"magic:sys" feature of red-pill mode to update your system.  Or use
apt-get upgrade.  Or we can come up with another meta package that can
be installed instead.

> And it's not just nokia-beta related. Any 3 party can come across
> this issue.

How so?  If a 3rd party relies on replacing a package that part of a
OS release with their own version, then that is something that needs
to be fixed.

> We are the first one to encounter it, but it is very easy to get in
> the way.

Yes, but every time it does get in the way, the meta package is
exactly doing its job.  It is designed to get in the way.  I don't see
it as a broken implementation of a good intention.  If anything, the
intention of only supporting package combinations from a single
release is broken.

> Community impression won't be nice too.

I hope that system is still open enough, even with the version
lock-down.

>> Now, if a system update is available, it might be that applications
>> start depending on versions of packages that are in this update.
>> If a user installs such an application without installing the
>> system update first, this might pull in a part of the system
>> update.
>
> Now, I see that this can happen in supported-mode too because the
> partial update involves nokia-signed packages. However, locking
> meta-package sounds artificial to solve this. Perhaps, there is a
> better approach to avoid this?

I am all ears. :-)

> [...] As I see the goal is to:
>
> 1) In blue pill mode, we don't allow any non-nokia signed packages to
> upgrade system components (already the case now).

Yes.

> 2) In blue pill mode, we don't allow any (even nokia signed packages) to
> upgrade system components *if* it doesn't come with meta-package upgrade
> (i.e. complete system upgrade). This is what the lock-down meta-package
> is supposed to fix.

The goal is to have the lock-down be effective independent of the
Application Manager, at the level of dpkg.

> 3) In red pill mode, we allow upgrading of any package - nokia signed or
> not. With appropriate warnings, of course. This is not the case now
> because of the lock-down. This is the part which needs fixing.

I think it is good enough for now that you can remove the lock-down
meta package.

> I have couple of random suggestions, but AM experts will have to explore
> more.
>
> A) Leave meta-package with '>=' deps. But in blue pill mode, let AM
> prevent any update of system package (I believe they are identified by
> some package tag) *if* the composite update does not contain
> meta-package also. It might require hard-coding the meta-package name in
> AM. In red pill mode, AM can proceed with a warning.

Hmm, I don't really like this, mostly because it puts more special
behavior into the Application Manager.  It already has too much of
that.  (The domain system should move down into apt, for example, I
would say.)

> B) Have there two meta-packages; one with '=' deps and other with '>='
> deps. In default blue-pill mode, meta-package with '=' deps can be
> pre-installed. When AM switches to red-pill mode, uninstall '=' version
> and install '>=' version. When AM leaves red-pill mode, uninstall '>='
> version and install '=' version.

This sounds OK, except that I don't want to tie it to blue-pill vs
red-pill.  Locked / unlocked should be an indepedent state from
red-pill / blue-pill, I would say.

>> The complication is that installing the rtcomm beta will have to
>> make sure that the version lock-down package is removed,
>> effectively 'unlocking' the system.
>
> Realizing that meta-package is supposed to be there for future system
> updates (notified in AM and conveniently installed), we instead install
> 'custom version' of osso-software-version that removes the lock on our
> packages. There will be horde of conflicts if everyone tries to do that.

Yes, so let's coordinate the betas of OS modules.  Let's put them all
into one repository, and that repository also contains the unlocked
meta package.

The installation instructions for each beta would have as the first,
identical step the installation of this unlocked meta package (if it
isn't already installed).

> The point was not to rip-off the user from a nice feature.

I will also try to make the "magic:sys" feature more useful, so that
when you decide to step out of a supported configuration, you don't
need a OS-wide meta package to keep your device up-to-date.

>> Removing the version lock-down package is the Right Thing for betas
>> that target Chinook, I would say.
>
> It's not the right thing because it unfairly (and unnecessarily)
> excludes the red pill mode users from a fundamental update cycle.

:-)

Yeah, I agree that we need to do better for Diablo.

>>> If the purpose of the package is *also* to prevent the user from
>>> screwing his device by installing some 3rd party updates, isn't that
>>> already taken care by red/blue pill modes?
>>
>> No, why do you think that?
>>
> What is red/blue pill modes for other then protecting the device from
> system packages update?

Well, we get into a bit of a terminology chaos here.  I used to make a
distinction between "user packages" and "system packages", where a
user package is visible in the Application Manager, and a system
package is not.

With that terminology, a 3rd party can and should provide system
packages, since not all packages need to be visible.  For example, the
Skype l10n packages are invisible, but they are not covered by the
osso-software-version meta package.

The red-pill mode was originally intended to make all packages
visible, since that seemed to be useful in some cases, it was easy to
do, and kind of cool to see the familiar Debian packages listed on a
Nokia device.  The red-pill mode has acquired more and more power-user
features that we want to keep out of sight of 'normal' people so that
they don't get confused too much.

Beta releases shoudn't really require the use of the red-pill mode.

>> The idea isn't that you just go to red-pill mode and all the
>> lock-down has disappeared.  The idea is that you can hack your way
>> out of the lock-down in red-pill mode, for example by removing
>> osso-software-version or by updating it from a source that has not
>> been signed by the Nokia System Update key.
>
> That idea is not good because I understand that package is used for
> meta-update of the system later.

No, but it is still important that you can remove it.

> Perhaps, as a (C) alternative, you put this meta package with '='

I think you mean ">=", right?

> deps in maemo repo.

I would make a package with a different name (say
osso-software-version-unlocked) and put it right next to
osso-software-version into the official repository.

The difficulty with this is that there might be a number of different
meta packages, one for each supported OS variant (one for N810, one
for the N800, say).  You would have to know which of the "-unlocked"
packages to install.

An alternative is to stop relying these meta packages and just make
"magic:sys" work well enough.  It's quite close.

> Any update, including nokia betas, expecting system package update
> can then just set a dependency on it.

No, please don't depend on the meta package.  First, you should not
rely on its name.  It might be different between N800 and N810, etc.
Second, it would be a lie: your package doesn't depend on it, it just
conflicts with the lock-down package.

Instead, we should have explicit instructions for unlocking a device.

> But then if all 3rd party packages depend on this 'unlocked'
> meta-package, what would be the point of the 'lock-down' meta
> package in the first place anyway. Seeing the version change in
> 'About' dialog is certainly not the only point of locking -
> unlocking. Is it?

That, and making it easy for people to easily stay within the
progression of supported configurations.