"fork" trisquel
- Inicie sesión o regístrese para enviar comentarios
Hello everyone,
I think it is time to change how trisquel is developed/governed. It hasn't to be so dependent on 1-2 people. Everyone can contribute supposedly but the actual decisions fall on these same people. If, as many times in the past, they are busy trisquel suffers.
What we have to do is offer the posibility to more people (everyone interested) to take part more actively.
For example if someone fixes something in package-helpers (the scripts that build the source from ubuntu) they have to wait until their fix is merged and this can take a long time.
I propose to work like wikipedia works. Everyone can change things without permission, unless vandalism happens.
What do you think?
The only change needed is this. Not another distro.
So the first step is to host somewhere else trisquel and decentralize the whole process.
Your suggestion has a problem. package helpers can also be used to import source code of deb packages from *any* APT repo. How can we be sure that someone is not trying to *intentionally* import a malicious software into the main Trisquel apt repository?
Maybe somebody tries to do that. In that case we revert that change.
I am a translator!
I chimed in to remind you there is already a fork of Triquel, it's called URUK
Yes, I checked it today. I don't want to change the programs in Trisquel but the way these programs are made. I don't think Uruk does this in a different way.
I am a translator!
I know the two guys who are maintaining Uruk are both great folks, but I have no idea what is their idea of how development should be done. I know they accept and **need** help, developers included. Maybe try to contact them directly if interested. You'll find contact info on their website.
I think a better idea would be that we can define some *access levels* and for example just renaming *Ubuntu* to *Trisquel* would not be dependent on Ruben himself, for acceptance. But someone who he trusts.
What you're proposing is a terrible idea from a security perspective. There has to be some central control, because that's the only way the Debian packaging system can be secure. Otherwise, someone could e.g. push a change that puts a backdoor in all Trisquel systems that's almost impossible to fix. The comparison to Wikipedia is inappropriate; when a Wikipedia article is vandalized, the only effect is a minor inconvenience, not a security breach. Consider what would happen if Wikipedia editors could change the JavaScript code Wikipedia deploys. All sorts of bad things could happen from that.
The solution to a lack of time to check and pull fixes isn't removing the checking, but rather giving more people the authority to do it.
"What you're proposing is a terrible idea from a security perspective. There has to be some central control, because that's the only way the Debian packaging system can be secure. Otherwise, someone could e.g. push a change that puts a backdoor in all Trisquel systems that's almost impossible to fix."
Why it's impossible to fix it?
That's a hypothetical example based on the assumption that someone malicious could make any change, which they can if they can implant the right malicious feature into the right package upgrade. There are all sorts of ways they could prevent further Trisquel upgrades from fixing the problem, up to and including blocking further access to the official repo. If that happens, there's nothing the Trisquel team can do about it other than post a message and hope that all users come see the message and fix their systems.
Yes that could be happen. But for a malicious feature to actually work, I think it must be secret. If the users-other developers know about it, it's useless. As soon as the whole process is transparent it is not worth the effort to put malicious functionality.
> But for a malicious feature to actually work, I think it must be secret.
And it can be. If you have the capability to change the software on Trisquel's servers, you can make it do something malicious and also prevent future updates. The user who installs this malicious update would never notice a thing, and any fix delivered would not reach them. Therefore:
1. Legitimate Trisquel contributors would have to be on high alert at all times, which they simply can't be, to minimize this sort of damage.
2. Users would have to frequently manually check the Trisquel website for news so they can learn about this sort of thing.
Additionally, the person doing this cannot be held accountable, so it doesn't matter how transparent the system is. That's why it has to be only designated, trusted individuals who have permission to actually send updates to the Trisquel users.
Great point, didn't think about that. I mean maybe such a wiki distro is worth a try, but I'd definitely wouldn't use it as my main distro.
Now, linking this to politics (not a great move I suspect, but the analogy intrigues me), Trisquel/Debian can be compared to some kind of mild benevolent dictatorship.
But as a user, I can inspect what's going on, and I can leave.
Maybe I'm going too deep in this, but anyway, you made an interesting point.
"Great point, didn't think about that. I mean maybe such a wiki distro is worth a try, but I'd definitely wouldn't use it as my main distro"
We can use it as an experiment for organizing collaboration in this way. I understand that there are implications in this model but if we don't try it we can't be sure if it works.
In reply to onpon4:
If someone malicious disables future updates for everyone can't this be detected from users, after some time?
Possibly, possibly not. One way to hide it would be to modify the update reminder program to pretend to download updates, or to point to a different APT repository. It doesn't matter; they're vulnerable to whatever malicious features have been added in the meantime.
I don't think you fully comprehend how much of a security hole this would be. Maybe an analogy would help: allowing anyone to change what updates are sent to users would be almost as bad as leaving an SSH port open and telling everyone what your password is in the hope that someone is going to come along and fix your security problems. It's completely insane.
SalmanMohammadi wrote:
>> I think a better idea would be that we can define some *access levels* and for example just renaming *Ubuntu* to *Trisquel* would not be dependent on Ruben himself, for acceptance. <<
Good idea, but is it possible to allow someone to make minor changes without also giving them permission to make major changes?
Anyway, before we start thinking about ways to involve more people, the OP's claim is that Trisquel development is dependent on the work of 1-2 people. First things first, is this true?
If it is, then the next question is, why? Is it because there is a lack of volunteers, or because people who want to volunteer are not being accepted into the project team? If it's a lack of volunteers then the only solution is for more of us keen users to volunteer.
If it is that there are overly restrictive barriers to people doing volunteer work to help the Trisquel project, the next questions are, what are those barriers? Are they barriers that need to be there to safeguard the security of the project? If so, there's not much we can do. If not, then we can start discussion of how to bring down as many of those barriers as possible, and involve more people in the work of the project. But first, we need to make sure we actually understand the precise nature of the problem we think we are trying to solve.
I think it's mostly a lack of volunteers. Beyond that making it work like a wiki where where anyone can come along and do anything is an absolutely horrible and dangerous idea. No distro works like that. Not even Debian does. It's not as if, in Debianland, absolutely anyone can walk up upload anything they want into the Debian repos. They have a process established. You have to work with them for a while. Prove that you are trustworthy. Have other already-existing Debian developer(s) advocate for you. etc. https://wiki.debian.org/DebianMaintainer There is a whole process. An example in Trisquelland might be people sending in patches for Helpers to the mailing list of making pull requests through the GitLab instance. Let that go on for a while. Other people should absolutely have to review things done by other people. Especially so if that person has a new account. Trust is earned, not bestowed.
Ok, maybe after all it seems to have serious problems this idea (from a security perspective).
If tomorrow lots of people are willing to help Trisquel, they all have to wait until their contributions are reviewed and merged from those that have the authority to do so. A hybrid model between the extreme of "wiki" and the current one is needed.
- Inicie sesión o regístrese para enviar comentarios