Live data from Hacker News

Tell HN: Whole Yandex Git repository leaked

news.ycombinator.com

301–310 of 369 posts

Re: Tell HN: Whole Yandex Git repository leaked

#301

Earlier quoted context omitted.

Maybe, but I remember when the Windows 2000 source leaked, and the ReactOS developers started forcing all contributors to sign a statement saying that they hadn’t read it.

Yup it'd end up in random places just like fast inverse square root. Origin will be forgotten and that will be that. These days everyone whack code on GitHub I wonder if it'd be possible for GitHub to review repos for likely derivative of leaked code?

If GitHub did that then there's a chance it would flag Copilot-written code, revealing their public narrative as a lie, so I think they'd quickly kill any such proposals.

Re: Tell HN: Whole Yandex Git repository leaked

#302
post #48

Earlier quoted context omitted.

I wonder if that's a function of their technology or their database. Google's image search used to be good, but regulations have forced them to cripple it in some ways, and they might have chosen not to surface results in some contexts.

Not only regulations, Chrome's builtin image search uses Google Lens to find products to sell you instead of simple reverse searches. It has become useless.

Totally. Even the regular search is mostly made of selling links.

And in quantity, it seems like 9/10th of the content is gone.

Re: Tell HN: Whole Yandex Git repository leaked

#303
post #59

% bzgrep "BEGIN PRIVATE KEY" \*.bz2 disk.tar.bz2:Binary file (standard input) matches drive.tar.bz2:Binary file (standard input) matches extsearch.tar.bz2:Binary file (standard input) matches ...

People check in fake private keys to git repos all the time for testing. My own tests have private keys too. They're just sample, unused, publicly advertised private keys I found online. They're useful to make sure your code is working end to end with some private key.

EDIT: For example, here: https://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-htm...

or here: https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSpher...

or: https://www.ietf.org/archive/id/draft-bre-openpgp-samples-01...

Re: Tell HN: Whole Yandex Git repository leaked

#304

Earlier quoted context omitted.

Checked in private keys are fine if they're just used in tests, local development, etc.

Technically fine yes but from a habits and practice standpoint it's safest to stick to a "not ever" rule and work around the limitations.

Checking in fake private keys is fine for testing. Why is it bad, out of principle, just in case you check in bad private key? I think that's a bad argument because there are a lot of benefits to being able to run end-to-end tests with some key.

Re: Tell HN: Whole Yandex Git repository leaked

#305

Earlier quoted context omitted.

I have seen your article. This bit caught my attention: > All files are dated back to 24 February 2022. If a coincidence, pretty interesting.

In case people aren't aware, that day Russia made a major escalation of the Ukrainian invasion that began back in 2014, starting with the announcement from Putin about a "special military operation" beginning in Ukraine by Russian forces. Unlikely that was the day of download, it's common practice to mask last-modified/last-accessed/created-at timestamps in dumps, by setting it to some significant date or just initia…

[dead]

Re: Tell HN: Whole Yandex Git repository leaked

#306

Earlier quoted context omitted.

why?

Russia is currently trying to invade and conquer even larger parts of Ukraine and a significant part of the world is helping Ukraine defend itself at the moment. I prefer handing my data to privacy-breaching companies if the alternative would be handing data over to a state my government is currently holding a proxy war against.

[dead]

Re: Tell HN: Whole Yandex Git repository leaked

#307

Earlier quoted context omitted.

Care to explain? Keeping private keys inside the repo sounds fine for me as long as these keys are only used for local development, they are rotated regularly and are only valid for localhost (in case of TLS certs).

Not GP: If you make it normal to check in credentials and keys, then the risk of accidentally checking in prod secrets increases. It's basically making it comfortable for devs to deal with keys in repos and I think that's inherently dangerous.

You should be using automated checks to keep credentials out of your repo, not relying on individual developers. And those checks can have explicit exceptions for known safe/public/test keys, just like you might explicitly allow testing or fake credit card numbers.

Re: Tell HN: Whole Yandex Git repository leaked

#308

Earlier quoted context omitted.

When I've been there arcadia was the primary SVN monorepo where everything was stored (and built by custom flavour of cmake). From what I heard it's still SVN and git was completely eradicated in the company.

This is pretty interesting to me. Usually companies will gradually switch over to git. This is the first time I've heard of a company using git and ditching it in favor of older technology.

git is inefficient when you need to handle a huge monorepo where just one checkout weights 66 GiB and the history is measured in tens of terabytes.

The other problem not addressed by git was the support of per-directory permissions.

Re: Tell HN: Whole Yandex Git repository leaked

#309

Earlier quoted context omitted.

Yandex regular search is very good too, especially at surfacing results which appear to be censored by Google. The only problem is the interface language keeps flipping back to Russian.

Is there a meta search engine that highlights results from Yandex that are missing from or ranked much lower on Google?

Searx used to highlight the source engine. I don't remember ever seeing yandex though.

Re: Tell HN: Whole Yandex Git repository leaked

#310
post #136

If you want to know what's inside archives without downloading them I'm slowly working on my blog post about this breach. Will try to write a bit about affected Yandex services for those who never been interested in russian internet segment. Also uploaded file lists from most of archives: https://arseniyshestakov.com/2023/01/26/yandex-services-sour...

I have seen your article. This bit caught my attention: > All files are dated back to 24 February 2022. If a coincidence, pretty interesting.

not a coincidence yandex has its own VCS (called arkadia). But not all services used it, some used github public and private. After war started, they had to migrate everything to internal vcs for obvious reasons.

So it makes sense they stopped committing to other repos somewhat around that date.

I don't have any inside knowledge now, but my guess would be that the leak is from 'on-prem' github.

Post reply on HN