[KolmogorovComp]

> Google’s codebase is shared by more [...] than 25,000 Google software develop- ers from dozens of offices in countries around the world.

> Access to the whole codebase encourages extensive code sharing and reuse [...]

Doesn't this strategy result in a great risk of massive code leaks from rogue employees? Even if read access are logged and the culprit found, it's too late once it's been published.

[ameliaquining]

Most source code just isn't that interesting or sensitive.

[scarface74]

If you had every line of code that Google wrote, what would you do with it?

But I found this discussion on HN.

https://news.ycombinator.com/item?id=11790438

[ameliaquining]

Well, if you had the search ranking algorithms or the bot-detection algorithms or anything inherently adversarial like that, then you could do all kinds of nefarious things. But that stuff's locked down more tightly. Likewise with a few ultra-hard-tech things where the implementation's a major competitive edge.

[forgotusername6]

I imagine looking for vulnerable areas of the code might be something people would be interested in doing. Maybe start with login or billing or something. You could also look at recent activity to spot new, unannounced projects. You could use blame to find who wrote what and target them for anything from job offers to social engineering attacks.

[ameliaquining]

Most of that information is readily available on the corporate intranet without having to dig through source code.

Security-by-obscurity isn't something to rely on (again, except in the case of things like abuse detection where there's no alternative).

[forgotusername6]

You aren't necessarily looking for things that would be defined as security by obscurity. You're looking for bugs with a security implication. With the source code, you can look for these bugs without arousing suspicion.

[saagarjha]

People can find vulnerabilities without the code too.

[fatneckbeard]

id make an art piece where each line of source code was printed 1mm high on the walls of a room. . . . .. . and then..... it would show the program counter "live" on the wall as code was executed. like it would shine a light on the line of code, like a realtime debugger.

[Lexarius]

Despite almost everything being in one big repo, it has silos. Not everyone has read access to everything. Some code, like the important bits of Search, is only available on a need-to-know basis.

[Macha]

So what happens if search adopts your internal library and your update to it breaks search? Do you need to get someone from the search team to go investigate? How is that prioritised?

[compiler-guy]

The tooling is such that you will know if a change will break something in a silo before it is submitted. You then work with the affected team. It’s not a big deal.

[bananapub]

it's search's fault for locking down their code and so search gets to fix it.

[Macha]

And if they don't think it's important right now? Are other teams who need the change just blocked?

[bananapub]

? then their code doesn't build anymore and they will have a very sad time.

[Macha]

But I thought the precommit hooks would block this merge if it breaks search?