Gitlab vs Github

General Discussion
1

guys,

any reason why Qubes & Heads choose Github as repository ?
while Gitlab is open source, & Github is not,
also some comparison article said that Gitlab is more secure,
i.e. gitlab vs github

1 Like
2

This is a frequently asked question. Three main reasons:

  1. We distrust the infrastructure including GitHub (though there are aspects we’re still working on).

  2. It’s free (as in beer). We’d have to spend either time or money to implement a solution ourselves or pay someone to do so, and we can’t spare either one right now.

  3. It has low admin/overhead requirements, which is very important, given how little time we have to spare.

The project uses Gitlab CI.

2 Likes
3

hi @Sven
it has been long time doesn’t see you around,
thanks for answering.

okay, never thought it will be in the FAQ.
sorry, forget to check the FAQ.

1 Like
4

Well, this sounds to me like: since we distrust hardware, it is more convenient to use Windows (or if you pull off “free as a beer” argument, then more convenient to use Ubuntu) than Qubes.

5

Not to say that Github is closed source platform, while Gitlab is at least open-core

6

Think again.

The architecture of Qubes OS is meant to minimize who you NEED to trust (the project team, XEN team and in a limited way Fedora). Qubes OS actively mitigates the threats arising from the distrusted hardware (sys-net, sys-usb, sys-audio, sys-gui etc.). As well as the threats from random application software (since it runs in isolated, firewalled qubes) and inevitable compromise isolated to a particular compartment.

So Qubes OS acknowledges the risks (distrust) and actively addresses them. Using Windows or Ubuntu would mean to acknowledge the risk and then surrender to the inevitable negative outcome. BIG DIFFERENCE yes?

2 Likes
7

Using Github’s closed source platform would mean to acknowledge the risk and then surrender to the inevitable negative outcome caused by the both Windows and Github owner.

It’ll happen!

8

I get that. And in a world where the Qubes OS team has huge man power and millions in budget, maybe it would make sense to spend a few man months and a couple thousand dollars to migrate to Gitlab to support the "better"™ solution.

Meanwhile in this world there are like what 3-5 core developers – maybe and a few thousand dollars of budget. So the project needs to look at all the things they could do and pick the ones that bring the most benefit. In this concrete case would you rather have them focus on stability and hardware isolation or spend a few weeks or months migrating everything to Gitlab?

Remember: there is no real security or trust benefit, just perception / nice to have.

3 Likes
9

What are you talking about? What negative outcome? What could M$ do to the project?

10

I’d rather wait! Make a poll!

And raise crowdfunding for migrating. Maybe you’d be surprised.

I emphasize: it’s my bad day obviously, but not mad at anyone, especially not on Qubes. I’ll just spit it out: using closed source platform to create open source software (of such a sensitivity) is like gets fucking to create virginity.

1 Like
11

@enmus thank you for clarifying your position. I can see this is a religious issue for you. I am not interested in that sort of discussion. If you see an actual threat to the project beyond “but Microsoft!!!” let me know.

4 Likes
12

No, no, I won’t go any further. It’s not about Microsoft, but about using any closed source tool to create Qubes.

13

This mistake in this line of reasoning is overgeneralization. We choose the cheaper, more convenient option for untrusted infrastructure. It doesn’t follow that we should choose the cheaper, more convenient option for the ultimate root of trust for our digital lives.

2 Likes
14

Yes, that is known fact. But while we have comparison here - “cheaper”, I am sure there is comparison in the second part of the statement - “less distrusted infrastructure”, or, to sound familiar, “reasonably trusted infrastructure”.

To be clear, I’m not pledging for migrating to Gitlab, Qubes is private project and the owners can do whatever they think it is the best for it. I’m just bringing in my opinion on something someone else started, not me. I would never start something like that - for me it is take it or leave it. I took it as is.

15

guys @Sven @adw

anyone know, how distrusting the infrastructure, is technically implemented,
in Qubes, related to Github ?

is it by signing each git commit, before being pushed into Github repo ?
also by verifying download.

1 Like
16

Yes, that’s correct. We sign either commits or tags (or sometimes both), then we verify the sigs on those tags whenever pulling from GitHub’s servers. This way, we’re not trusting that GitHub is honest. We’re assuming that GitHub (or someone who hacks into their servers) might try to replace all the code (or other data) we store on their servers with malicious code (or try other nasty things). By always checking signatures on commits and/or tags, we instead shift the trust to PGP and other Qubes team members’ signing keys.

However, there are some places where we’re still working on fully distrusting GitHub. For example, there isn’t an easy way to sign and verify comments, labels, and milestones on issues and PRs. (For reviews on PRs, we’ve developed our own system where the reviewer leaves a signed comment on the PR saying something like, “Approved as of <commit_hash>.”)

3 Likes
17

i see, understand now,

okay, thanks for all the hard work,
also, for high security awareness.

1 Like