Hacker News new | past | comments | ask | show | jobs | submit login

Correct, this block would be for two functions (Site Reliability Engineer and Support) and we currently have no people in that role in China and Russia.

Please note that we're still discussing this change. We work out in the open so you can see us working on it. I hope that people appreciate the difference between that and what you would see in a non-transparent company (probably nothing, they would just not open up a vacancy in the offices in that country).




Concerns on privacy, data and IP are understandable. However, this ban would be a symbolic move with absolutley zero substance. The world is small and highly interconnected and it would be extremely easy for the Russian and Chinese governments to compromise and co-opt support staff from pretty much any country of their chosing. This will lulll your customers and your infosec teams into a false sense of security. Considering how forthcoming you are with the names, roles and location of your team. They would pick you off in a heart beat and you would not suspect or see it coming. The Chinese are extremely well entrenched across the global - with enough money to grease anybody's wheels. Not to mention it would be trivial for them to get their "agents" passports from anywhere in the world


Would you consider extending this to other roles? If you remember the Juniper VPN backdoor was so well done it would have likely (or did) passed code review, putting most software engineering in to scope.

Additionally would this extend to individuals who are of Chinese or Russian origin? China in particular leans on nationals who are on visas or have family still in country to conduct espionage operations.


It would be strange to not accept code from certain countries since we are an open core company that gets contributions from around the world. There are other ways to prevent supply chain attacks. A difference with data is that there are always multiple people involved before code is merged while data can be extracted by a single individual who has access.

Discriminating on origin is likely illegal.


> A difference with data is that there are always multiple people involved before code is merged while data can be extracted by a single individual who has access.

It sounds like you just need to harden your production perimeter. Jump boxes with two-man-rule access and terminal logging. Apply the same practices to data as you do code.

> Discriminating on origin is likely illegal.

You should ask your legal folks about the national security exceptions of Title VII. It sounds like your customer requirements are pushing you in that direction anyway.


> open core company that gets contributions from around the world

The irony...


I appreciate that Gitlab discusses this in open, the only real disappointment that it's so one sided.


[flagged]


I meant from the US perspective, Gitlab seems to have a few remote workers that aren't Americans, but still...


Well actually we have over 1000 team members (all are remote) and only half are in the US. The other half are in 63 other countries. If you want to see where we all work from you can check out our team https://about.gitlab.com/company/team/.

The reason this is viewed from a US legal perspective is because we are a US company so we are governed by US laws.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: