On Thu, 2007-11-01 at 09:50 +0100, Adrian Schröter wrote:
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.
Isn't possible to organize the buildservice around stability? That you get a warning that "you are adding repositories from an 'unstable' branch and is therefor untested?
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.
No problem, now I know I can coach my customers better :)
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)
I think this is a great solution and the future for openSUSE (releases).
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.
Off course it it is doable (see Debian/Gentoo/FreeBSD/Ubuntu) who support up to 22000 packages. the only question is how ;)
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).
Are these procedures written down? I think this would be good way to start.
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 !
What kind of help are you looking for?
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 ?
I certainly hope so! As I said I am not a programmer but I am willing to help i any way I can to make the openSUSE buildservice more secure. An irc meeting to discuss ideas and setup a plan would be a great start! :)