[maemo-developers] [maemo-developers] Re: [maemo-users] 'Locking down' software installation
From: Dmitry Rozhkov dmitry.1.rozhkov at nokia.comDate: Tue Jan 8 11:21:58 EET 2008
- Previous message: [maemo-developers] Re: [maemo-users] 'Locking down' software installation
- Next message: Build Evince on Maemo
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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!
- Previous message: [maemo-developers] Re: [maemo-users] 'Locking down' software installation
- Next message: Build Evince on Maemo
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]