On Thursday 01 November 2007 09:33:40 wrote Aniruddha:
On Thu, 2007-11-01 at 09:03 +0100, Adrian Schröter wrote:
..
Putting lots of packages into one large repo does not help you, as long you do not add extra review mechanisms. Which can't be that extensive, if you increase the number of packages.
Since the are also different requeriments (you want to be more care full on your critical server than on your test systems) it is better to have multiple repositories with different requirements for the trust and let the user decide.
I am not sure I am getting your point.
I mean, each user has a different level on requirements. And he may even decides different for his different systems.
This makes it hard to define one level and one single policy for us at openSUSE, since the result of the highest security requirement would be a very small distro with not really up2date software versions.
There are two extrems from "highest security needed" up to to "I do not care, it is just for test or I just want the latest version".
So we can not define a single policy, but we can help the users to decide themself.
Compare this to the openSUSE buildservice where everyone can get an account start a repo and wreck havoc because there aren't any safety precautions.
Right, but only stuff in home:* can get added by them. So you are already one step more secure when you do not use these repos.
Thank you. This is a very valuable lessen. What would be the best way to communicate this to the user? And does this mean that the non home:* are checked by openSUSE devs? Does this also include security fixes?
In general, each project can have its own policy. I agree the user is a bit lost atm and it is hard for him to decide how much he can trust which one.
Security fixes are only done via version upgrades in the repositories atm. (unlike SLE or openSUSE distros where an extra update repo with backported fixes is available)
Since everything in the build service is free software you can always check the source the packages are built from yourself if you wish, and so can anyone else, which provides as much as a safeguard as possible.
This can be doen for a few packages that you manually compile, however openSUSE relies so heavily on the buildservice for functionality that it becomes a daunting task to check all these packages yourself.
All packages checked into the main distro get a review. This is also the reaons why it takes sometime until a new version appears there.
I think it would be best to enlarge the packages that belong in the main distro. Since openSUSE became open source this really should be possible (one team focus on packaging another one putting the packages together for a new distro).
This conflicts with high security requirements ...
For example, SLES (or most secure product) has only ~ 50% of the packages of openSUSE. Simply because it is not doable to apply all required rulse for more packages.
openSUSE distro has some lower riquerments, but still more than any build service project. So, if you can wait until a new version gets added there this is the most secure way.
Unlike SLE and openSUSE, the build service repos just get a peer review only. This means, if there is something evil, either the packager needs to react after reporting (or we as admins, esp. if the packager is the evil guy).
What is indeed missing is a peer review and rating system to help the users to decide which repos to trust or not...
Does this have any chance to be implemented? I missed it on the roadmap ;)
It was unfortunatly not as important as other stuff listed there, so I can not promise any date right now.
However, if someone is willing to work on it, we will help him of course !
I personally consider this approach more secure than a one large repo where everybody gets easily an account no one is really doing source reviews of new submitted tar balls. One the other hand, our modell still allows that new packagers can start immediatly and make their stuff available. It is up to the user to install it or not. (and keep in mind that downloading the source and install yourself is maybe even more unsecure, because there is not even a packager review).
You're right about that. I do think that some improvements we can greatly improve the security of the build service:
-Make it more difficult to add home:* repositories
Make something more difficult just creates new hazzle and bugreports, but does not really help the security.
-Add some kind of review and comments section to value to repositories.
How should we proceed to make this happen?
We have a minimal base for the trust handling with our new user directory. If someone wants to extend this, that users can be rated by other users and that a certain trusted group is allowed to change user trust leveling it would help a lot.
We can automatically show the level of trust for a project afterwards, if we know how much we can trust the people with write access there. (additionally they should be allowed do downgrade their project as well, if they do not trust it much either, because they downloaded some untrusted source ;)
So, if you would like to work on this, we are happy to help you. The source is part of the opensuse svn on forge already and we can make a (irc?) meeting where we discuss details and the design a bit more.
Does anyone have interesst in this ?
bye adrian