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! _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
