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

From: Dmitry Rozhkov dmitry.1.rozhkov at nokia.com
Date: Tue Jan 8 11:21:58 EET 2008
Hi,

One more vote against osso-software-version (or strict dependencies at
least)
has come from the bug https://bugs.maemo.org/show_bug.cgi?id=2731

"rtcom-beta-os2008 version 2.1-14 depends on osso-software-version. As I

understand osso-software-version is a meta-package and doesn't provide anything
for rtcom. So I doubt that it really needs to depend on it.

This gives a problem for user that have uninstalled osso-software-version
because they don't want any games on their tablets (like myself). rtcom wont
install and it says it needs osso-chess, osso-mahjong and others. That doesn't
sound right to me. I understand this setup is not officially supported, but
rtcom should still do what is right."


BR,
Dmitry

Naba Kumar wrote:
> Hi,
>
> I want to start this thread again from the long past discussion on 
> lock-down meta-package. At that time, the discussion was mostly centered 
> around system upgrade using the meta-package. The 'locking-down' part 
> wasn't so much discussed and I believe we need to rethink that portion.
>
> While preparing for rtcomm software update release, it came to my
> attention that there is the said meta-package "osso-software-version" 
> package that completely 'nails' the system packages to fixed versions.
>
> This has created the very obvious problem of not being able to update
> any of those packages, such as during the recent rtcomm dev update 2 (in
> red-pill mode, of course). We had to remove the package from the device
> to make it work. This, of course, means that the user is not going to
> see any future OS updates coming through that meta package [1].
>
> If the purpose of the package is just to deliver future updates bound
> under a single meta-package, why isn't the dependency versions set with 
> 'equal-to-or-greater-than'?
>
> 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? Then this package is 
> redundant in protecting the user's device. Even in red-pill mode, this 
> package doesn't prevent anything because the installing package can 
> simply remove it and go happy.
>
> Here are three things about that:
>
> 1) As claimed by the original mail from Marius, the 'red-pill' does not 
> really override this lock-down. The meta-package needs to be hackishly 
> removed or 'replaced' regardless of whatever pill mode. Is there any 
> other way?
>
> 2) The lock down of those packages already taken care by 'blue-pill' 
> mode so no need to lock-down versions.
>
> 3) It creates a bad situation for every 3rd party to compete in 
> overthrowing the locking meta-package, like mentioned in [1].
>
> So I believe we should fix that meta-package to take '>=' and not '=='. 
> Comments?
>
> Thanks.
>
> Regards,
> -Naba
>
> [1] Of course, there is another dirty way of coming around it -- Prepare
> another micro-build-incremented update of osso-software-version package
> (with corrected dependencies, of course) and replace the existing one.
> This preserves the user device for getting OS updates later. But,
> seriously, why all these hops? This is how current rtcomm update 2 is 
> supplied.
>
> Marius Vollmer wrote:
>   
>> Hi,
>>
>> we are planning to put some features into the Application Manager that
>> will make it more restrictive when handling the packages that make up
>> the operating system itself (as opposed to third party applications).
>>
>> We would like to get your feedback on these plans, both from the
>> end-user point of view and from the point of view of package
>> developers.
>>
>> In the future, we hope to be able to provide official updates to the
>> operating system itself via packages, and we need to give the
>> end-users the confidence that when they intend to install a Nokia
>> provided operating system update, they actually get what they think
>> they are getting.
>>
>> As for the concrete plan:
>>
>> There is going to be a 'meta' package that represents the whole
>> operating system.  Updates to the OS are done by updating this meta
>> package in the Application Manager.  The meta package will have
>> dependencies on all packages with their exact versions that make up
>> the official OS releases.  The Application Manager will not allow the
>> removal of the meta package.
>>
>> This means that the Application Manager will not allow you to update
>> individual OS packages (or to install third party applications that
>> require this), since you would have to remove the meta package for
>> that.  It is still possible to install additional 'system' packages,
>> just not to upgrade already installed ones.
>>
>> A second new feature is that the Application Manager will distinguish
>> between "trusted sources" and "non-trusted sources" (based on the key
>> used to sign the corresponding repository).  A package that has
>> originally been installed from a trusted source will only be allowed
>> to be updated (or replaced) from a trusted source.  The flash image is
>> also treated as a trusted source, so you will only be able to update
>> packages that are pre-installed in the device from trusted sources.
>>
>> This makes it easier for the user to be sure that he doesn't pick up
>> unwanted system software updates by accident.
>>
>> The set of trusted sources will be under control of a power-user: you
>> can just add some GPG keys to the right place, but there is no UI to
>> do it.  You can also switch the whole lock-down machinery off by going
>> to red-pill mode.
>>
>> So whaddaya think?  Useful?  Too painful?  Too difficult to escape
>> from?
>>
>>
>> Some variants that come to mind:
>>
>> The meta package could depend on 'this version or later' of a package
>> instead of on "exactly this version'.  That would allow it to control
>> the update just as much, but would not lock down the configuration of
>> the device so much.  The motivation for this lock-down of the device
>> configuration is that Nokia (probably, IANAL) doesn't want to support
>> any other configuration, and having to 'hack' your system via the
>> red-pill mode or similar is a good indication that you are now on your
>> own.
>>
>> The locked-down upgrade path could support more than one set of
>> trusted sources down to the granularity of repositories.  This would
>> allow other parties than Nokia to make use of this feature.  That's
>> just a smop and might be done.
>>
>>
>> (And please understand that all this has nothing to do with preventing
>> bad software from doing bad things on your device; it is just about
>> giving the user an indication that something fishy is happening (by
>> accident) that he probably didn't intend to happen.)
>>
>> Thanks!

More information about the maemo-developers mailing list