GSoC Proposal for Implementing one-click install feture
Debayan Banerjee
I was thinking of implementing the one-click-install(tm) feature for Fedora.
Suppose I want to install a package x in Fedora. I need to add the
repository via the command line (or gui) and then type "yum install x"
to get the package install.
In the one-click-install feature we have a xml file per package which
contains information n it such as package name,version,repository
links (for installing further dependencis), GPG key etc. One may
upload these xml files on the web and an user may click on these xml
files in a browser. Once downloaded the a parser parses the contents
of the file and automatically adds the requisite repositories and
downloads requisite packages for dependency preservation.
Tasks involved would be to add a module to package-kit that parses
these xml files and to develop a script that automatically generates
these xml files when given a package.
Requesting feedback,
Thanks,
Debayan Banerjee
--
Be Intelligent, Use GNU/Linux
http://debayanin.googlepages.com/
http://debayan.wordpress.com
http://lug.nitdgp.ac.in
Yaakov Nemoy
> Hello community,
>
> I was thinking of implementing the one-click-install(tm) feature for Fedora.
> Suppose I want to install a package x in Fedora. I need to add the
> repository via the command line (or gui) and then type "yum install x"
> to get the package install.
> In the one-click-install feature we have a xml file per package which
> contains information n it such as package name,version,repository
> links (for installing further dependencis), GPG key etc. One may
> upload these xml files on the web and an user may click on these xml
> files in a browser. Once downloaded the a parser parses the contents
> of the file and automatically adds the requisite repositories and
> downloads requisite packages for dependency preservation.
> Tasks involved would be to add a module to package-kit that parses
> these xml files and to develop a script that automatically generates
> these xml files when given a package.
> Requesting feedback,
-Yaakov
Debayan Banerjee
> Is this the service developed by SuSE? Also, how is this different than
> clicking on an RPM on a web page and selecting to open it with the package
> installer instead of just saving it?
Yes this service is developed by SuSE.
When you click on an RPM , download, and open it with package
installer it may complain of missing package dependencies. This xml
file not only downloads the RPM but also automatically adds requisite
repositories to functionally complete the dependency.
>
> -Yaakov
Yaakov Nemoy
>
>>
>> Is this the service developed by SuSE? Also, how is this different than
>> clicking on an RPM on a web page and selecting to open it with the package
>> installer instead of just saving it?
>
> Yes this service is developed by SuSE.
> When you click on an RPM , download, and open it with package
> installer it may complain of missing package dependencies. This xml
> file not only downloads the RPM but also automatically adds requisite
> repositories to functionally complete the dependency.
My suggestion is to pose this to the PackageKit mailing list and see
how the feel. Ultimately for this to be usable in Fedora, it has to
somehow either cooperate with or use PK. After that, see if there is
anyone who is wiling to mentor you on this project.
Just my two cents, i saw the presentation on it at the previous Fosdem
in 2008, and they were pretty willing to work with Fedora people, they
even half coded in support for it. But then came along PackageKit. I
think it still has some potential.
-Yaakov
Debayan Banerjee
>
> 2009/3/23 Debayan Banerjee <deba...@gmail.com>:>
> My suggestion is to pose this to the PackageKit mailing list and see
> how the feel.
http://packagekit.org/pk-faq.html#1-click-install.
Hence I have chosen to forget about this idea. :)
Debayan Banerjee
>> My suggestion is to pose this to the PackageKit mailing list and see
>> how the feel.
> I asked packagekit list and they pointed me to this
> http://packagekit.org/pk-faq.html#1-click-install.
> Hence I have chosen to forget about this idea. :)
Guess what. Minutes later I receive this reply:
"
2009/3/24 Richard Hughes <hugh...@gmail.com>:
>
> No, if you are able to address the security concerns, then I think it is
> very worthwhile. The easiest thing to do is just copy the suse reference
> OCI implementation which in my opinion is horribly insecure.
>
> Also, I think someone in google tried to do this a few months ago;
> probably worth searching the archives for links. Thanks,
"
Hence I have decided to work on this further. Shall study the OCI
reference in depth and eliminate as many vulnerabilities as possible.
I shall look for a mentor on the package-kit list in parallel.
Yaakov Nemoy
>
> 2009/3/24 Yaakov Nemoy <loupgar...@gmail.com>:
>>
>> 2009/3/23 Debayan Banerjee <deba...@gmail.com>:>
>> My suggestion is to pose this to the PackageKit mailing list and see
>> how the feel.
> I asked packagekit list and they pointed me to this
> http://packagekit.org/pk-faq.html#1-click-install.
> Hence I have chosen to forget about this idea. :)
Ah yeah, one of the things the PK guys focus on is that the users
don't know enough about computers to honestly understand the effects
of installing certain third party software. They don't lock it
completely down, they just don't make it easy to do the wrong thing.
It sounds demeaning, but it's the number one way windows machines get
infected with virii and trojan horses.
Brilliant solutions to the problem are always welcome ;).
-Yaakov
Debayan Banerjee
> Ah yeah, one of the things the PK guys focus on is that the users
> don't know enough about computers to honestly understand the effects
> of installing certain third party software. They don't lock it
> completely down, they just don't make it easy to do the wrong thing.
> It sounds demeaning, but it's the number one way windows machines get
> infected with virii and trojan horses.
Well I think I may have a chance of being mentored on this by Benji
Webber himself, the person who created this standard I believe. He
responded to my mails on the PackageKit list.
>
> Brilliant solutions to the problem are always welcome ;).
They are on the way!
Debayan Banerjee
>
> Ah yeah, one of the things the PK guys focus on is that the users
> don't know enough about computers to honestly understand the effects
> of installing certain third party software. They don't lock it
> completely down, they just don't make it easy to do the wrong thing.
> It sounds demeaning, but it's the number one way windows machines get
> infected with virii and trojan horses.
>
> Brilliant solutions to the problem are always welcome ;).
problems with the one-click-install format on the packagekit list.
Here is what came out of it:
1) There is no way to trust third party software repositories.
2) Distributions like Fedora and Debian will never include non-free
repository information such as GPG keys for non-free repositories.
My view is that we do not really need to follow a policy where we
trust a repository based on its GPG key etc. What we are concerned
with is the package at the end of the day, and if the package itself
is not compromised in any way then we can always install it. The
question now is, how do we know if a package is compromised or not.
Lets say Fedora sets up a server at the url
https://checksums.fedoraproject.org/thirdparty. This server shall
contain a listing of all the MD5SUMS/SHA1SUMS of all third party
packages that are popular. Fedora may give "commit rights" to certain
trusted (trusted by Fedora) 3rd party developers so they can update
this list from time to time.
Suppose I now click on any one-click-install link and it downloads
packages. It then queries the checksums server and finds out if the
package is 1)listed 2) tainted. If not well and good, go ahead and
install it.
In any case, we can always do this for free software packages if not
for 3rd party repositories.
To this Dan Kegel said:
"Does it follow that Fedora and Debian will never
do anything to make it easier to install non-free software?
I don't think they would do that for non-free software.
So we're back at the original problem, aren't we?
I guess the difference between Fedora blessing
third party repositories and Fedora blessing third party
applications is that it lets them filter out packages they don't trust.
Would they go for that? I kind of doubt it. Why not ask them?"
Now in my opinion if Fedora accepts this proposal it will be so that
Fedora users are safe when installing third party software. The users
still have to scour for 3rd party
repositories themselves. Its like Fedora cautioning people from
installing bad 3rd party software.
So my proposal is "Add a notion of a *trusted* meta-repository that
refers to other repositories" (In Dan Kegel's words).
My questions to Fedora are:
1) Is it OK with Fedora to host a server such as
https://checksums.fedora.org/thirdparty which contains a listing of
all popular 3rd party packages with respective checksums?
>
> -Yaakov
Patrick W. Barnes
I would think that in order to consider any package as "trusted", it would
have to pass the rigorous standards that Fedora has set for all packages
included in the distribution, with the same level of review. If a package has
passed those, then it can be included in the Fedora repositories and the
third-party repository is no longer needed. PackageKit already has a browser
plugin for installation of packages from configured repositories.
What it all boils down to is whether or not we want to make it easier to
install *untrusted* packages from third-party repositories. I do not have a
straight answer to that. There are some third-party repositories that are
definitely useful to a lot of people, such as RPM Fusion and Adobe's repository
that contains Flash. There are many more that contain potentially dangerous
packages or packages that conflict with Fedora packages or that simply fail to
maintain compatibility and thus break updates and upgrades. If we make it
easy to install from third-party repositories, but fail to provide some kind
of trust system, even if it is just peer review, that drives users to safer
repositories and away from dangerous ones, then we will end up in as sorry a
situation as Windows.
Trying to build software that enables easy installation from third-party
repositories before building a trust system would be a mistake. I suggest
instead that you focus on creating a trust system first. I think something
that does not require the official approval for each repository by Fedora, but
instead allows peer review and leaves the ultimate decision in the hands of
the end-user is far more likely to succeed. A simple voting system might
work, but you may also want to provide a way for different users to carry more
weight in voting, probably by allowing users to vote on each other to grant or
revoke voting weight. As the number of voting users increases, it is likely
that the percentage of them that have strong foresight or are knowledgeable in
packaging and maintenance matters will decrease. Hopefully, voters who give
detailed and reliable reviews will be given more voting weight by their peers,
offsetting the danger of the larger number of inexperienced voters. In order
to protect users, the review system could block or provide strong warnings on
repositories that do poorly in reviews. I would advise that you keep track,
at least internally, of what each user votes for (both repositories and other
users) so that it would be easier to reverse the effects of bots or malicious
users.
A good way to integrate this review system (presumably a website) with your
goal to make installations easier would be to have a browser plugin that
allows users to install repository definitions from the review system when they
find ones they like. As a further safety step, the browser plugin could then
have a whitelist for sites that are allowed to provide repository definitions.
By default, that whitelist could contain only the main Fedora websites and
your review system. That way, if a user wanted to install a repository
definition from somewhere else, they would have to add that site to the
whitelist first, giving more opportunity for warnings about the dangers.
--
Patrick "The N-Man" Barnes
The Fedora Project
nma...@fedoraproject.org
http://fedoraproject.org/wiki/PatrickBarnes
Have I been helpful? Rate my assistance!
http://rate.affero.net/nman64/
All messages cryptographically signed:
http://en.wikipedia.org/wiki/OpenPGP
--
Debayan Banerjee
> On Sunday 29 March 2009 10:59:24 Debayan Banerjee wrote:
>
>
> What it all boils down to is whether or not we want to make it easier to
> install *untrusted* packages from third-party repositories.
I read through this <http://duncan.mac-vicar.com/blog/archives/414>.
He makes a case for one-click-install and says that many of the
apprehensions maintained by PK developers are baseless. But he
finishes the post by writing:
"For the user is meanless to trust a repository with gpg key
0×32432432 and they will probably just click “yes”. The pending task
is to make the cryptographic chain something that makes sense for the
user."
Which is what you mean too. You want trust to mean something that
users understand, like votes.
hmmm.
>
> repositories before building a trust system would be a mistake. I suggest
> instead that you focus on creating a trust system first. I think something
> that does not require the official approval for each repository by Fedora, but
> instead allows peer review and leaves the ultimate decision in the hands of
> the end-user is far more likely to succeed.
>
> A good way to integrate this review system (presumably a website) with your
> goal to make installations easier would be to have a browser plugin
The closest thing I can think of is
<https://admin.fedoraproject.org/pkgdb> and
<http://packages.opensuse-community.org/>.
Lets say we need to add the trust-voting system to this
infrastructure. I say we add the voting part to the distro side and
not a web based vote form etc. The thing is users are lazy and wont
care to vote up or down repositories after they are done installing.
What we can instead do is make changes to PK code so that every time a
user disables or removes a repository he is asked whether he wants to
send a "recommend" or a "not recommend" remark for the particular
repository.
Or if the user has just added a new repository and installed a
package, we give him an option through a dialogue box to "recommend"
or "do not recommend". This data goes to the vote/trust-repository.
Voting on the client side will bring in more votes.
Based on these votes, the web interface of say
<https://admin.fedoraproject.org/pkgdb> shall sort repository results.
The user can then click a one-click-install link and follow the same
procedures that is followed at
<http://packages.opensuse-community.org/>.
How does it sound?
Debayan Banerjee
I have been discussing this topic simultaneously on 2 lists because of
the nature of the problem. Here are the 2 threads:
[1] http://lists.freedesktop.org/archives/packagekit/2009-March/004569.html
[2] http://groups.google.com/group/redhat-summer/browse_thread/thread/50de9e16d5407b9c
I think its time to summarise my proposal. The way I see it, there are
4 things to do:
1) Add .oci support to package-kit.
2) Add pluggable policies
3) Add voting system to package manager
4) A server that receives these votes and maintains a list of repos in
sorted order. The distro maintains this. Leave it to the user which
repo he wants to add now.
Explanation:
1)Add .oci support to package-kit:
This involves adding C code to Package-Kit. Much of the work has been
done by Dorian Perkins and is available here .
2)Pluggable Policies:
The policy of what to allow to install will not be agreed
across all distributions.
So instead of discussing a policy that will never get unanimous
approval the install policy pluggable, and allowing the distribution
to choose the policy may be better.
Some example policies would be
* Only allow packages in the distribution itself
* Only allow packages that are whitelisted or in whitelisted repository
* Allow installation of anything that is not on a blacklist
* Allow installation of anything"
(In words of Benji Webber)
3) Add voting system to Package Manager:
The word trust has mean something that the end user understands, as
opposed to GPG keys. One way of defining trust is by votes. It is my
proposal that we enable a voting system at the package manager end so
that every time a repository is added and a package installed for the
first time users are asked for a "Recommend" vs "Do not recommend"
vote. Conversely, every time a user disables/removes a repository he
is asked whether he votes "Do not recommend". These votes go to a
centrallised server
4) A server that receives votes and maintains a listing of
repositories in sorted order:
We could make modifications to <https://admin.fedoraproject.org/pkgdb>
so that it provides one-click-install links to all packages thus.
Similar efforts are at , and .
I shall go ahead and submit this proposal in more detail.
Debayan Banerjee
> Similar efforts are at , and .
>
[2] http://packages.opensuse-community.org/
[3] http://www.allmyapps.com/