[packagekit] Res: One click install support in PackageKit

[Dan Kegel]

On Thu, Apr 2, 2009 at 5:39 PM, Debayan Banerjee <debayanin at gmail.com> wrote:
> 2009/4/2 Richard Hughes <hughsient at gmail.com>:
>> Well, I still don't think popularity == trust. I also think that OCI
>> would be a nice-to-have feature, but with package catalogs I don't think
>> it's a required feature.
>
> I saw the package-catalog schema. It contains no repository url
> information. i understand that this is by design since you do not want
> users to start adding repositories on the fly by clicking on web pages
> since it is dangerous.

Good point.  This means that package catalogs, as written, are
only a replacement for a small subset of OCI.

> What if we do incorporate url/repository in the schema? ...
> It also makes it risky since people may come out with these links and
> lead to dangerous repos. Well we can warn the user every time a
> dependency preserving repository is not Fedora friendly.
> A user who is careful and knowledgeable does not need this warning
> really. He could as well have added a the repository manually to get
> his work done. But the other kind of user will pay attention to
> warnings such as these that are displayed. I speak from my personal
> experience.

Have you heard of herd immunity?  There is currently a problem
in schools in the united states because many parents (20% in
some schools) aren't vaccinating their children.  This puts everyone
at risk because that 20% of the school population becomes easily
infected with measles, chickenpox, etc. and endangers even the
kids who were vaccinated.

A similar situation could exist if we make it easy, even with warnings,
for users to access random repositories.  The careless users
(and the majority of users are, I assure you) will happily
click on any interesting link and click through any warnings.

So, while I really want something like OCI or an expanded package
catalog feature to exist, I'm also deathly afraid of what it could mean
to the health of the community.

> About the trust vote thing, we can add captcha at the client end so
> that no bogus votes are polled. Of course we need voting only for 3rd
> party repos. Also lets make the url to which this votes go to an input
> that user selects, since it is not certain which organisation, if any,
> will host this server.

captcha is breakable, and client-side captcha could be easily bypassed.

I think you need to approach the voting system much more carefully
than you are currently thinking.
You're trying to build a trust system, and those are really hard.
It might make sense to think in terms of a chain of trust.
You can't trust the result of an election unless you can trust the voters.
One way to arrange this might be for organizations that are going
to be publishing lists of trusted repositories to run their own
votes in their own communities, and only let members in good standing vote.
But really there are few enough third party repos that are trustworthy
that we don't yet need a voting system; a manually maintained
whitelist should suffice for some time.  Focus instead on the
other parts of the problem, or you won't get anything deployed
in time to make a difference.
- Dan