RFC: On-demand package installation API in kdelibs
Lubos Lunak
l.lunak at suse.cz
Thu Jul 29 18:15:01 BST 2010
On Thursday 29 of July 2010, Martin Sandsmark wrote:
> On Thu, Jul 29, 2010 at 04:12:53PM +0200, Lubos Lunak wrote:
> > So? If you're fine with polkit for the clock, you should be fine with
> > polkit for installing trusted packages too.
>
> You don't see the difference between allowing the user to change the clock
> without asking for confirmation, and installing unauthenticated, arbitrary
> packages from arbitrary sources without confirmation?
I do. Do you see the difference between installing unauthenticated, arbitrary
packages from arbitrary sources without confirmation and installing
authenticated specific packages from specific trusted sources with
confirmation?
> > Which is not the usual case. The usual case is also a result of the user
> > explicitly doing something.
>
> Could you please enlighten me to the usual case, if not the application
> trying to use this functionality?
I was replying to your "This [=KWallet] is still the result of the user
explicitly doing something, as opposed to, for example, the mediaplayer just
proceeding to the next track." The usual case is that the API is used as a
result of an explicit user action, while the mediaplayer just proceeding to
the next track is not the usual case. And, uhm, KWallet actually
occassionally turns up seemingly without a reason too.
>
> > Of course not. The useful feature is the excuse.
>
> It is still just an excuse.
Excuse me for reusing the original sentence in the reply. I of course meant
justification.
> But if you think training users to click
> through and entering their passwords, as well as moving legal liability
> over to KDE, is worth it for band-aiding over distributions crippling their
> multimedia packages, I can't argue with you, only disagree.
Since your arguments are mostly only your opinion, it seems I can't argue
with you either, only disagree.
> > > > No. They are in additional 3rd party repositories which need to be
> > > > added first, or the packages need to be installed in a different way,
> > > > so they sadly can't be installed in a simple way :(. But you don't
> > > > install those every day either.
> > >
> > > Seriously, you want KDE to automatically download and install
> > > unverifiable packages from 3rd parties?
> >
> > No. Did I say that? Let see. No, I didn't.
>
> 1.: You proposed this API to automatically install extra multimedia
> packages when missing.
I proposed this API to install optional component packages when missing,
which among other things may be also multimedia.
And I didn't say it has to be automatic; while I didn't stress the opposite,
e.g. from my blog post it's rather obvious that the user at least needs to
agree.
> 2.: These multimedia packages are not available in the official, verifiable
> repositories.
That may happen to be the case.
> So yes, you did.
No, I did not. That is only your interpretation.
> Unless you mean the distributions somehow can verify the
> packages, in which case I don't have a problem with this.
There are basically 3 possibilities:
- The distro can ship the multimedia stuff directly. No big deal, the API
probably won't be even called.
- The distro can't ship the multimedia stuff directly, but can provide it as
an addon (let's say, hypothetically, if the user first confirms a dialog that
they don't live in the US), then the API can add additional trusted distro
repository and install from there. No big problem.
- The distro can't ship the multimedia stuff in any way. Which means maybe the
packages can be provided in some 3rd party repository by somebody else, but
the distro can't use it out of the box. So there's no way the API can install
these packages on its own, the user has to do manual intervention (e.g.
adding the repo themselves during the process). No problem either, besides
the user suffering.
> > - Because we already do have it, today. Just check the dialog or
> > notification next time something complains you don't have something
> > installed. And nothing stops you, you can have it cumbersome forever if
> > you want.
>
> I don't get that dialog, I have a package manager that handles this at
> installation time. :-)
So Debian has only one installation option "Install everything and the
kitchensync" :) ?
> > - Because I doubt it's more secure and it's definitely not more sane.
>
> I'm sorry, a perfect implementation will of course be secure, what I meant
> was that it would be bad from a security perspective (training users to
> click through etc.).
> OK, and sorry if I am very stubborn and rude.
>
> Noone has yet met my criticism, though (without being incoherent from
> sentence to sentence).
Still some technical details that you have a problem with? I think there is
no point in continuing the discussion about the disagreement on whether the
benefits justify the possibility of stupid users getting trained to be even
more stupid.
--
Lubos Lunak
openSUSE Boosters team, KDE developer
l.lunak at suse.cz , l.lunak at kde.org
More information about the kde-core-devel
mailing list