GitLab Is A Vast Improvement To FreeDesktop.org's Infrastructure

[GreenByte]

This is less secure, because now I have 2 laptops (one personal, and another on the work) with private keys in a "non-somewhere" directory, and anybody can steal it (either physically, or virtually), and use to do stuff from my account. You see what's the difference with passwords?

No, only you can steal it, since it's encrpyted by default (decrypted either every time you want to do anything, or on login by your key manager) with a password, adding extra layer of security. That's my point. 1+1 > 1+0.

[DrYak]

Why is that a problem? (Curious, not assuming any reasons and not trying to judge them)

In addition to all the US politics and Google approach to privacy discussed in this thread, I want to point a completely different problem which is general to the Cloud - no matter which provider in particular :
You're running things on somebody else's computer.

It has some limited advantages : that somebody else (as in Google's case) might be a lot more competent and/or have much more resource to run the service. (Everybody here remembers the train wreck of Linux Games Publishing's server).
If FreeDesktop.org's GitLab server gets broken, Google surely has the ressources to fix it quick.

But it comes at big disadvantages : you running things somebody else's computer - on a computer that you don't own nor control. With some less known names in Cloud hosting that might mean that *they* can fuck up your server. Also you're at risk of the service disappearing. Google is a champion of shutting down popular services every now and then. (They even shut down their own Google Code). So even if Google probably won't fuck up clumsily in an unplanned manner (they are not XKCD's Hat gay cloud hosting service), they could fuck up by changing business plans.

openly giving Spotify and Netflix fast lanes that they didn't charge data on in order to entice customers to switch to their service, and this was perfectly okay according to the FCC.

There's something special that Netflix does : they install relay servers in the same data center as ISP. ISP can thus inter-operate with these servers locally, and the users might get better response time (even more so if the movie happens to be on the local cache). Netflix pay for their own connection in the data center and they don't eat the ISP's bandwidth.

So it's not the ISP throttling (like the actual problems that people against the net neutrality repeal are pointing to), it's simply some service being served faster, because they are served locally. Nobody is neither complaining that your ISP's IMAPS email server answers fast than Google.

If the US somehow suddenly decides that Mesa is illegal (HOW??? WHY???), the location of the hosting service is going to be the very least of it's problems.

Hum.... Some patent troll managing to convince a jury that some OpenGL feature that Mesa implements (say, simulating 64 float on 32bit hardware) violates IP that they own ?

If the project is hosted at a European company (just like VLC is handled by VideLan - in Paris) - well, fat chance. France doesn't recognize software patents, only software component as part of an actual physical invention being patented.

If the project is hosted in US, an US court could order them to take down the hosted service. They are a US company present on US soil, they have to comply with US laws (or face financial consequence).

(That's also one of the reason Google moved out of China : they don't have presence here, they don't need to comply with Chinese law, China has no recourse to directly harm them (-their chinese branch), they are left trying to block them with the firewall).

Did you know it doesn't allow to push into your forked repo with password?

I very clearly remember pushing into a Git-Lab repos over https (for the sake of trying to get around some stupid firewall that was blocking the regular git+ssh access).
Are you sure of your setup ?

You gotta jump through the hoops to make an ssh key, store it somewhere, add it to your profile, then to make git it to use it… Damn this is confusing and annoying!

Whaaa.... ? You find SSH public keys difficult to handle ?! Are you trolling or are you really having trouble with that ?

Why had they to replace good old login/password system with something so terrible that makes you to reconsider whether you really want to contribute to gitlab-hosted project?

Because of security ?
Because a 2048 bit RSA key certainly beats some simply string that you've picked up with your human brain ?
Also because you could setup "deploy keys" - helping you to automate the deployment of your code to e.g. a test-server, without needing to store your password somewhere ?

[DrYak]

This is less secure, because now I have 2 laptops (one personal, and another on the work) with private keys in a "non-somewhere" directory, and anybody can steal it (either physically, or virtually), and use to do stuff from my account. You see what's the difference with passwords?

Speaking of standard behavior, in addition of using ~/.ssh/id_rsa litterally the next question that ssh-keygen asks afterword is if you need to password-protect the private part of the key.

It's up to you to:
- not use your UNIX account's password
- not use an SSH key agent that auto-unlocks SSH keys.

Then ssh will ask you the key password for any new connection.
You'll get the same UX as with a password.
The same "won't work if stolen" effect.
But any (weak) password interactions are only locally between you and your locally encrypted files on your 2 laptops.
Any data on the net or on server only deals with stronger encryption key (>2048 bits RSA, ECDSA, etc.)

And no, my password is far not easy to guess.

Is it a base64-encoded string of a 256 bits number you got from /dev/random (that you also feed with your own true random source, of course) ?
No ?
Then it is guessable. Eventually. Maybe not now (you know, there where a lot of password that resisted dictionary attacks but got covered by pattern-based one).

[Hi-Angel]

I very clearly remember pushing into a Git-Lab repos over https (for the sake of trying to get around some stupid firewall that was blocking the regular git+ssh access).
Are you sure of your setup ?

I just checked: I have "url = https://gitlab.freedesktop.org/Hi-Angel/libinput" as my origin. I made a change for testing, commited it, and did "git push origin master". After asking for my nickname and password it says:

remote: HTTP Basic: Access denied
remote: You must use a personal access token with 'api' scope for Git over HTTP.
remote: You can generate one at https://gitlab.freedesktop.org/profile/personal_access_tokens
fatal: Authentication failed for 'https://gitlab.freedesktop.org/Hi-Angel/libinput.git/'

Whaaa.... ? You find SSH public keys difficult to handle ?! Are you trolling or are you really having trouble with that ?

I did it just once or twice, and I am definitely annoyed I have to go google stuff, and do lots of manipulations, to get a trivial "git push" to work.

Because of security ?
Because a 2048 bit RSA key certainly beats some simply string that you've picked up with your human brain ?

My password is also encrypted with RSA due to https it's being send over — now what?

Also because you could setup "deploy keys" - helping you to automate the deployment of your code to e.g. a test-server, without needing to store your password somewhere ?

Fair, then maybe it should be an optional feature for those who do use CI, because most random contributors definitely don't?

[Hi-Angel]

Is it a base64-encoded string of a 256 bits number you got from /dev/random (that you also feed with your own true random source, of course) ?
No ?
Then it is guessable. Eventually. Maybe not now (you know, there where a lot of password that resisted dictionary attacks but got covered by pattern-based one).

lol I'm using a combination of lower and upper case letter + numbers, and a not easy to guess algo to mix this stuff for every site. It's not easy to guess the pattern even if password from a particular site is compromised (although possible), don't have a visible pattern unless you know you gotta search one, and you have to enumerate 13537086546263552 combinations. If you go through 1000 combinations every second, you'll need roughly 421180 years.

[Tomin]

I did it just once or twice, and I am definitely annoyed I have to go google stuff, and do lots of manipulations, to get a trivial "git push" to work.

It can not be that hard. When I set up a development machine, this is what I do:
Set up my name and email to git global config (I usually forget this and do it when I commit the first time).
Copy my ~/.ssh/config from backups (defines users and ports for my own machines).
Generate a key with ssh-keygen and copy the ~/.ssh/id_rsa.pub file to the services/machines that I need to access.
Now git push and pull will just work when using SSH protocol. For Github/Gitlab/Gogs/Gitea/etc. you can get the url from the repository page.

[Vistaus]

This is why, nothing open-source should *ever* be hosted in the US. Because now, it is under the microscope of the US government, who is not trustworthy.

And who exactly is trustworthy? The UK with GCHQ? China with their government control? Israel with their spying eye? The Netherlands with the AIVD that recently received NSA-like privileges due to a new law? Russia with the FSB?

[jf33]

The problem with Google is NOT, that the code is a secret (because it's not). The problem is that Google tracks you everywhere you go on the web. Search, Analytics, Captchas, YouTube, (embedded) Maps, googleapis, ... they're everywhere! Lots of websites don't work without their services. The same is true for Amazon, Cloudflare, jQuery and a few other cloud providers. That's why it's a bad choice to host yet another website on their computers.

Also the "somebody else's computer" is a good argument, as mentioned by DrYak. Now, the developers should at least sign all their commits (which they won't do), so that the code can't be manipulated unseen.

[smitty3268]

No it is not. There was significant lobby money behind both. That's not political.

Wait, you think that lobbying isn't political???

Technically speaking, servers don't magically connect to the internet, they have an ISP too. And such ISP can throttle them selectively all they want as long as this isn't explicitly forbidden in the contract.

Of course. But for a paid service obviously Google would ensure that works no matter what. And more to the point, the server could well be in Europe in the first place, making this entire point completely nonsensical.

that's the issue with big data, you can't know.

Ok, i give up. This is like talking to a flat earther. No amount of reason is going to matter, you just have an opinion that something terrible might happen and you're not going to change that, ever.

Haha, you're new to this. There is no authentication that ensures that people aren't just using a fake name. The "signed-off-by" line serves mainly the purpose of protecting the project itself from third party copyright claims, not to authenticate contributors in any way.

You're delusional if you think they can't track back IP addresses if they want, no matter where the server is. It's what governments do.

Also, more to the point, the Mesa project itself doesn't want you to be anonymous either. So this is a poor argument to make to them about not hosting on Google, since if anything they'd view that as a bonus.

[pal666]

This is less secure, because now I have 2 laptops (one personal, and another on the work) with private keys in a "non-somewhere" directory, and anybody can steal it (either physically, or virtually), and use to do stuff from my account.

you are doing it wrong. you should always:
1) use full disk encryption for laptops
2) use passphrase with ssh keys