On Tue, May 5, 2009 at 12:50 PM, Matthew Tippett <[email protected]> wrote: > Why does the the distro disable 3rd party repositories... Some answers > could include > > 1) Effectively increase the absolute priority of the distribution > packages to allow the update. If the third party app is force to be > removed to satisfy a dependency, so be it. > 2) Remove the possible sources of conflicting/unstable/incorrect 3rd > party libraries that may have a higher version match than the distributions. > > (Any other thoughts?)
Those are all fine reasons. In the past, third party repositories have been a source of instability, so disabling them was a good idea. Now that large ISVs are considering using the package manager to update their apps (after all, why reinvent the wheel?), it might make sense to reexamine that practice. If, say, Ubuntu decides to have a whitelist of trusted ISV repositories (with preloaded public keys), perhaps those whitelisted repos should not be disabled on upgrade. (After all, if they were doing anything risky, they would't be in the whitelist, at least not for long.) > Now, obviously you are considering the "damn, it happened, what do we do?". > >>a) nothing; just grin and say "we're ok with being unable to deliver >>security updates" >>b) on next run of the app, prompt the user, e.g. >> "Something turned off autoupdates for this app. OK to re-enable updates?" >>c) silently re-enable the repo > > To initially get to that point, the user has taken direct action to > enable the updates. Based on that, b) or c) would appear on the surface > to be the better two. You seem to be assuming elevated access for c), > so b) seems to be the best option - using xdg-su or similar to inform > the user, elevate their access, and enable the 3rd party repo. Yes, b) would be the method of choice unless it resulted in too many users apathetically hitting cancel and saying "Why are you bothering me with questions?", and thereby becoming vulnerable to attack because they are running an out of date app. Remember, every extra keystroke or mouse click the user has to do significantly reduces the number of users who make it through any particular task; making the action take more than one click might mean having lots of insecure users. To reduce this problem, you could imagine doing an in-app notification, then having a tiny and heavily audited suid app that can do absolutely nothing except re-enable the isv's repo. This would make the interaction flow better in the app, and would reduce the number of keystrodkes needed. Any setuid app makes me nervous, but the risk of having a tiny setuid helper app might well be lower than the risk of having lots of users with out of date apps. And that same app could be used for c), if for some reason that one single click yielded too many insecure users. > Do you have any use cases driving the user's experience in your case? A real life user installed Ubuntu 8.10, installed Chromium for Linux on it, then upgraded to Ubuntu 9.04, and asked why Chromium wasn't updating any more. - Dan _______________________________________________ Desktop_architects mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/desktop_architects
