Live data from Hacker News

Repositories held for ransom by using valid credentials

about.gitlab.com

11–20 of 158 posts

Re: Repositories held for ransom by using valid credentials

#11
post #9
post #8

Earlier quoted context omitted.

GitLab is not a repository backup service. They are only required to hold multiple copies of what is the current version of the repository for their own hard drive fault tolerance purposes; they are not required to hold copies of the repository from a day, week, month, or year ago.

Was just a question, don't get me wrong here. Thought they would do this for their managed service.

You can see how GitLab handles repository backups on the following page https://about.gitlab.com/handbook/engineering/infrastructure...

Re: Repositories held for ransom by using valid credentials

#12
Based upon other comments the title has already been changed several times.

It still suggests Gitlab's infrastructure (internally) was compromised: "Suspicious git activity detected on Gitlab"

Something like "Gitlab users' repos held for ransom" seems more appropriate.

Re: Repositories held for ransom by using valid credentials

#16

Some other info: https://www.theregister.co.uk/2019/05/03/git_ransomware_bitc...

Out of all things to hold for ransom git repos seem like a bad idea. Most of the time there are multiple clones lying around anyways. I agree that having the source code leak can be bad news, but the code itself being secret should not be a critical part of the business.

Re: Repositories held for ransom by using valid credentials

#17
> We believe that no data has been lost, unless the [...] GitLab copy was the only one.

One difference between how GitLab and GitHub run their infrastructure is that GitLab doesn't keep reflogs, and uses git's default "gc" settings.

As a result they won't have the data in question anymore in many cases[1]. Well, I don't 100% know that for sure, but it's the default configuration of their software, and I'm assuming they use like that themselves.

Whereas GitHub does keep reflogs, and runs "git repack" with the "--keep-unreachable" option. They don't usually delete git data unless someone bothers to manually do it, and they usually have data to reconstruct repositories as they were at any given point in time.

GitHub doesn't expose that to users in any way, although perhaps they'd take pity on some of their users after such an incident.

This isn't a critique of GitLab, just trivia about the storage trade-offs different major Git hosting sites have made, which might be informative to some other people.

I'm surprised no major Git hosting site has opted to provide such a "we have a snapshot of every version ever" feature. People would probably pay for it, you could even make them opt to pay for access to backups you kept already if they screwed things up :)

1. Well, maybe as disaster backups or something. But those are harder to access...

Re: Repositories held for ransom by using valid credentials

#19
post #10

>The breaches seem to rely on the attacker having knowledge of the affected users passwords in order to wipe their Git repositories and hold them for ransom. Yeah, until I go to my computer and use "git push" again. No? Also gitsbackup.com is registered but has no A/MX records so...

"Also gitsbackup.com is registered but has no A/MX records so..."

Gitlab should really note that in their blog posts and emails to users. Just in case someone is thinking of paying the ransom.

Re: Repositories held for ransom by using valid credentials

#20
post #17

> We believe that no data has been lost, unless the [...] GitLab copy was the only one. One difference between how GitLab and GitHub run their infrastructure is that GitLab doesn't keep reflogs, and uses git's default "gc" settings. As a result they won't have the data in question anymore in many cases[1]. Well, I don't 100% know that for sure, but it's the default configuration of their software, and I'm assuming th…

Just out of curiosity but how do you know about this inner workings of Github and GitLab?
Post reply on HN