GitHub hasn't been hacked. We accidentally shipped an un-stripped/obfuscated tarball of our GitHub Enterprise Server source code to some customers a couple of months ago. It shares code with github.com. As others have pointed out, much of GitHub is written in Ruby.
Git makes it trivial to impersonate unsigned commits, so we recommend people sign their commits and look for the 'verified' label on GitHub to ensure that things are as they appear to be.
As for repo impersonation – stay tuned, we are going to make it much more obvious when you're viewing an orphaned commit.
In summary: everything is fine, situation normal, the lark is on the wing, the snail is on the thorn, and all's right with the world.
Some people think RIAA’s DMCA notice is not legally valid, arguing RIAA is not the copyright holder and there is no infringing material. DMCA takedowns are for taking down works you own the copyright to; not for enforcing any arbitrary aspect of legislation.
It’s my understanding that service providers do not need to comply with illegal requests.
For example, if I DMCA’d <an oil producer>’s repository on accused violations of environmental protection acts, I don’t think it would be taken down, would it?
If GitHub was an independent company advocating for open source; would it have acted any different?
Note: Microsoft is a member of the RIAA.
Apple made waves and built lots of favour for resisting the FBI and challenging quasi-legal processes. They took risks and demonstrated their principles (Suing the FBI over a terrorist’s iPhone is unlikely to be the first recommendation from their legal counsel).
This smells like a qausi-legal process, and it would look great for GitHub/Microsoft if you do.
Almost all of the lawyers at HN, and the lawyers at the EFF, and the guy at Popehat, are all generally in agreement that there was nothing wrong with what the RIAA or what GitHub did. It should tell you something when the people most in a position to evaluate the situation don't see anything amiss.
If you object to people following the law because you feel they don't hold the same views on the matter at hand, the point is moot, unless of course you feel they should break the law.
Which leads back to, if you don't like a law then lobby for it to be changed.
I've changed the laws in two countries through my lobbying efforts, though saying which two countries (and which laws) would be too identifying given that this is my quasi-anonymous account.
But on that note, businesses change laws through lobbying all the time. That is indeed one of the complaints about our current system of government: that it is too susceptible to lobbying.
Of course laws change in response to business interests. The context of this discussion is changing laws like the DMCA, though, which protect capital interests.
Signed: CEO's of the US.
What the EFF actually said: https://twitter.com/EFF/status/1319787243184123904
OP lied. The EFF never said this. I can't find Ken White ("the guy at Popehat") saying anything similar either, but perhaps someone will post a link. And I don't know what "lawyers at HN" he's referring to either.
* RIAA was legally welcome to send a DMCA letter which didn't conform to DMCA requirements. Anyone can legally send a legal demand letter saying more-or-less anything, and plenty people do.
* Since this letter didn't conform to DMCA requirements, github wasn't required to take down youtube-dl, but was well within its right to do so.
* github wasn't required to take down other instances of youtube-dl, not referenced in the letter, and ban users, but github can probably fire customers without cause, so there was nothing illegal.
... and so on.
RIAA may or may not have a legal leg to stand on with the DMCA anti-circumvention stuff, depending on what exactly Google does, and I haven't dove into the system in enough detail to know. I don't think Youtube implements DRM, but perhaps it does and perhaps youtube-dl circumvents it. That should be between youtube-dl and RIAA, nor between RIAA and github.
My own opinion is RIAA can't have it both ways. If they don't want people to copy, they should use tools designed for that: iTunes, Amazon Music, etc. If they want to use viral networks used for sharing personal videos, they should respect that those networks are designed for, well, sharing. If my mom uploads a video of my son playing with her to Youtube, yes, family members might want to download that if she's okay with it.
The friction here is that centralized media, whom decentralized is disrupting, wants to now use decentralized media (and by "decentralized," I'm talking from a social perspective -- anyone can publish versus a few people can publish -- not a technology one).
What we call DMCA takedowns, coloquially, with the whole counter notification process etc, are notices submitted under Title II. That title deals with copyright infringement, not anti-circumvention.
That means treating such notices as a typical DMCA notice, as GitHub has done, is incorrect. GitHub may well choose to follow the takedown if it considers it valid and the repo infringing, but what they've done is treat it as a copyright takedown. And that is clearly, unambiguously wrong, as it goes against their own DMCA policy, linked from the youtube-dl repo's disabled notice, which says:
> The DMCA notice and takedown process should be used only for complaints about copyright infringement. Notices sent through our DMCA process must identify copyrighted work or works that are allegedly being infringed.
So yes, GitHub messed up here. That doesn't mean they shouldn't have taken down youtube-dl, but they way they went about doing it is wrong.
You'll notice that the EFF, in that article, never goes into the details of the takedown process that happened. They never said what GitHub did was proper. They are just talking about the anti-circumvention law in general.
On the other hand, if they DO comply with it, the RIAA is extremely unlikely to sue them, whether this is covered by the safe-harbor provisions of Title II or not.
> they'd be in for a costly legal battle.
In fact, in the US, that is the _only_ way for a citizen to challenge a law. One cannot challenge a law that they have not been charged with breaking in the United States.
"That's some nice software you got there... be a shame if something were to... happen... to it. So, you better keep paying us for our locked-down content, and don't even think about trying to pick those locks. Or else."
The Title II provisions are irrelevant, as they do not cover circumvention devices. The RIAA could sue them regardless of whether they comply or not.
Did you even read the comment you replied to?
Anyone can sue anyone for any reason.
ETA: And yes, if you submitted a DMCA takedown which has any reasonable chance (from the recipient/provider's perspective) of being valid, it would get taken down. Otherwise, the provider takes on their customer's liability. Very few (and zero free) providers are willing to do so.
> DMCA takedowns do not need to be from the copyright holder themselves. They can be from ANY authorized agent of the copyright holder
I think it's clear that "RIAA is not the copyright holder" is shorthand for "no member of the RIAA is the copyright holder". Even if you don't accept that, you can easily deduce that no member of the RIAA is the copyright holder by looking at the immediately following claim, "there is no infringing material".
Given that there is no infringing material, it can't really matter whose agent the RIAA purports to be.
The EFF has a write-up about it .
OTOH, your comment violates a number of HN rules and probably should be deleted for dang kills your account for a few days.
> The clear purpose of this source code is to ... reproduce and distribute music videos and sound recordings owned by our member companies without authorization for such use. ... We also note that the source code prominently includes as sample uses of the source code the downloading of copies of our members’ copyrighted sound recordings and music videos, as noted in Exhibit A hereto. For example, as shown on Exhibit A, the source code expressly suggests its use to copy and/or distribute the following copyrighted works owned by our member companies: • Icona Pop – I Love It (feat. Charli XCX) [Official Video], owned by Warner Music Group • Justin Timberlake – Tunnel Vision (Explicit), owned by Sony Music Group • Taylor Swift – Shake it Off, owned/exclusively licensed by Universal Music Group
I'm sometimes baffled that people miss that point when it comes to internet security. The biggest real difference is the global nature of the internet and thus problems with jurisdiction, which obviously doesn't apply if both sides reside in the same jurisdiction.
Clearly what is most important is the intent. In this case, it is very clearly RIAA's intent to make the aforementioned videos obtainable publicly via the use of HTTP agents. Browsers are HTTP agents. youtube-dl is an HTTP agent. Either they are all infringing or they are all not infringing.
On the other hand, it is clearly the intent of my door and lock to keep people out.
There are other examples in the real world tho, where the distribution/creation of the tool is already illegal (e.g. certain weapons or explosives), because only reacting after damage is done is infeasible.
If fair use tells us that it's ok to use parts of copyrighted works for certain purposes, then there must be a legal avenue for obtaining those parts.
There is massive legitimate use for downloading videos, yet the alleged harm is purely monetary.
It's really, really, really stupid, because it presumes guilt before innocence, standing in opposition to most general legal principles.
If anything, Microsoft via Github would do well to assert itself by not conforming, forcing the court to examine the DMCA's legality and process.
So shouldn't the next US-American recipient of one of these notices refuse to comply on the grounds that the law is unconstitutional?
The U.S. Court of Appeals for the Fourth Circuit in 2006 begins a discussion of possession with:
"That possession is nine-tenths of the law is a truism hardly bearing repetition. Statements to this effect have existed almost as long as the common law itself."
Willcox v. Stroup, 467 F.3d 409, 412 (4th Cir. 2006).
It doesn’t mean whoever possesses something is automatically the owner. It means that absent evidence of superior title, possession generally suffices to show ownership.
That doesn't make the notice facially invalid, if they have made the required representations (which they have, as they have alleged specific infringement of their works on a contributory infringement theory as well as alleging that the works in question violated DMCA anticircumvention provisions, and particularly alleging that the combination of the anticircumvention violation plus the specific identification of works of RIAA-represented owners as targets was the basis for the contributory infringement claim.)
Unless Github wants to expose itself to both upfront costs and potential liability by judging the details of the legal theories and fact claims in facially-valid DMCA takedown notices, it makes sense for them to react to facially-valid notices and wait for a facially-valid counter-notice before restoring user content.
Therefore there is only risk and no benefit for a service provider not to comply with any notices they might receive.
tl;dr there probably isn't anything inherently wrong with the RIAA's claim, and there's definitely nothing wrong with github's response.
As for DMCAing an oil producer's repository for something unrelated to DMCA, github would still take it down, but it's quite likely that you'd end up with a lawsuit from the oil company for damages. As long as GitHub is run by a US company, it doesn't matter how advocating they are of open source, nothing would change...they'd still take down the repository after receiving a DMCA takedown request.
And the last point, my understanding is apple wasn't actually required to assist the FBI, but american companies are required to follow DMCA.
This is how things work; it may not be how you'd like things to work, but I doubt you've ever been involved in any part of a DMCA takedown request (as the sender, receiver, or the person that had their stuff taken down).
Let's pretend for the moment that the original youtube-dl DMCA had been valid, or that you removed youtube-dl due to an innocuous mistake. If I post youtube-dl to MY account, you have NO reason to take it down until you receive another takedown request from the RIAA for my repo. You certainly have no reason to ban users. There is nothing in your ToS which this violates.
I work on education projects which use youtube-dl in legal, non-infringing ways. I don't think the RIAA has a legal leg to stand on for reasons I'm not going to get to in this post.
Until github starts following DMCA processes properly, I CANNOT respond to the existing takedown request, since I have no standing. It's not my repo.
The right course of action for me would be to:
(1) Consult my lawyer and figure out if this is a fight I want to pick. I'm pretty sure I'd win in court if this went all the way, but I might go bankrupt first.
(2) Post youtube-dl to my repo.
(3) Wait for a DMCA takedown notice.
(4) Respond to it with a counternotice, and litigate with the RIAA.
Because github has decided to act as an arbiter on behalf of the RIAA, rather than a neutral third party, I cannot follow this process. github short-circuits this process at #2 by threatening to remove the repo and ban my account.
I'm sorry that you've chosen to side with the RIAA against the Internet. I'm gradually moving my business to gitlab. This is approximately what people thought would happen as a result of the Microsoft purchase.
You need to re-read the Github TOS, because this is absolutely covered by it already (see Section F of their TOS).
You potentially also lose your safe harbor restrictions in the process.
That is false. They could lose their safe harbor if they did not respond to a presumptively valid DMCA notice.
Pretty sure that the Legal Dept at Github knows more about the DMCA process than a random non-lawyer on HN. It's something they deal with on a regular basis.
This is false.
That is probably for the best. Customers with unrealistic expectations are not worth the effort to keep.
Section F says they can take down RIAA's account, not mine. Here is the section in full: "If you believe that content on our website violates your copyright, please contact us in accordance with our Digital Millennium Copyright Act Policy. If you are a copyright owner and you believe that content on GitHub violates your rights, please contact us via our convenient DMCA form or by emailing firstname.lastname@example.org. There may be legal consequences for sending a false or frivolous takedown notice. Before sending a takedown request, you must consider legal uses such as fair use and licensed uses. We will terminate the Accounts of repeat infringers of this policy."
The relevant policy is here: https://docs.github.com/en/free-pro-team@latest/github/site-...
> That is false. They could lose their safe harbor if they did not respond to a presumptively valid DMCA notice.
Had it been a valid DMCA notice, the required response under the DMCA is taking down the youtube-dl repo.
Their thermonuclear bomb was to take down other people's repos, ban accounts, and make random threats.
> Pretty sure that the Legal Dept at Github knows more about the DMCA process than a random non-lawyer on HN. It's something they deal with on a regular basis.
I'm pretty sure they do too, which is why their aggressive and technological legal response, combined with their CEO making public statements of sympathy for their victims, is so cynical, dirty, and dishonest.
They can be the good guy, and fight the RIAA. They can be a neutral party, and do their duty under DMCA. But fighting the RIAAs battles for then, and then making comments like Nat's? Sketchy and sleazy.
Even eighties/nineties Microsoft didn't do that. They went after people, but they were at least open about what they were doing -- they called Linux a virus and all sorts of other nasty things. They didn't pretend to like Linux while spreading FUD and mounting legal attacks.
On the other hand, I'm pretty sure the other random guy on the internet (you) doesn't know more than the first random guy on the internet (me).
> That is probably for the best. Customers with unrealistic expectations are not worth the effort to keep.
Depends on the cost, the context, and how those expectations manifest. Talk to any luxury good company serving the ultrawealthy for how not catering to customers with unreasonable expectations would serve them. Or any company selling to an athlete to promote a product. Or many small businesses who just won multimillion dollar B2B contracts. Or...
But in either case, I don't think expecting github to act honestly is an unrealistic expectation. Each time I've dealt with a dishonest company, no matter how good the deal looked, I came out behind. I think people were holding their breath to see what happens with github post-acquisition, and we just learned.
The TOS says that Github will take down the offending content (or if, necessary, account), not the copyright owner's account. Most copyright owners do not have Github accounts. Github is not a thing people use outside of programming.
This is the proper response to the petulant behavior of techies flaunting the original takedown. The end result would simply have been the RIAA issuing more requests, possibly even formal requests, which Github would have led Github to doing the same thing it did proactively.
You know why did it? To protect people from the legal consequences of their stupidity. Lawsuits are expensive, especially when you're in the wrong and the other side has a very large legal budget.
Being the good guy in this situation is not fighting the RIAA. It's doing what the law requires to prevent disruption of services to their other customers, most of whom aren't opening flaunting the law.
Outside of the tech world, to the extent that people care about this conflict, they're wondering why techies are so intent on bullying non-techies just trying to protect their work. Outside of tech, people are struggling and many are unemployed. This is a PR battle that tech is losing.
No. It doesn't say "offending content." It says "repeat infringers of this policy," referring to the aforementioned paragraphs.
> Github is not a thing people use outside of programming.
Which is increasingly close to zero major industries.
> The end result would simply have been the RIAA issuing more requests, possibly even formal requests, which Github would have led Github to doing the same thing it did proactively.
Exactly, and the opportunity for people with non-infringing uses, such as myself, to pick up the torch. It's a lot easier to take down youtube-dl than it is to take down obviously non-infringing educational tools used by kids to learn from home during a pandemic.
> It's doing what the law requires to prevent disruption of services to their other customers, most of whom aren't opening flaunting the law.
The law requires a very specific process. github went above and beyond that process, for no positive reason. The safe harbor provisions in DMCA hinge on being a "service provider," which is not very well defined, but the provisions were inspired by the concept of a common carrier.
If all I'm doing is hosting people's content, with no control over that, or providing bandwidth, or a caching layer, I shouldn't be liable for the actions of those people. Comcast has no liability for what I send over their network. If I run something illegal on AWS, that's not AWS' liability either. That's reasonable.
There's a fuzzy line from there to a service like github or Youtube, to a service like pip or npm, to something like the Debian package repository. If the Debian package repository, which is controlled and curated by Debian, has infringing content, Debian would almost certainly be liable.
github can be viewed as "like Comcast/AWS" or "like Debian," depending on how much control it exerts over what goes on github. Exerting more control than it absolutely needs to -- as it did in this case -- increases their liability in the long term. This shouldn't put them out of the service provider category, but a pattern of exerting control might.
I'll post cites to sources, and then I'm done here.
In the same way, it seems GitHub is preemptively telling people that if they re-post youtube-dl on GH, they'll be banned, even though GH has no legal responsibility to do so. It's really sad that they're siding with big business in all this, rather than their users, without whom they'd be nothing.
GitHub seems to be acting without a backbone. They’re owned by Microsoft, and can definitely stand up to legal challenges like this. Look at BitTorrent: The protocol and it’s code are legal despite being used for piracy. I don’t see why GitHub caves to every request to take down code that is clearly not violating any copyrighted material.
Also, the code itself does not break any copy protection and even if it did.. the code itself needs a user to execute it. Isn’t this how LAME was able to exist without violating mp3 patent laws?
That's how section 512 works. The RIAA letter referenced section 1201, not 512. There is no copyright infringing material to identify. The letter relates to distribution of copyright protection circumvention technology.
Maybe Github needs a new page explaining section 1201 takedowns.
Does the DMCA actually define these, or is the entire concept of a "section 1201 takedown" a courtesy GitHub is extending to rightsholders, but not legally required to provide? I am only familiar with the DMCA outlining a takedown process for copyrighted content.
An MP3 patent, such as 6,009,399, covers methods and apparatuses for encoding a digitised audio signal. Writing source code that uses a claimed method is arguably not infringment but as soon as anyone besides the patent owner or her licensees compiles the source code and tests the binary, then there is a much stronger argument that infringment has occurred.
Just curious, what would the effects be if one were to use multiple accounts to automate the submission of DMCA takedown notifications for all <content> hosted on <content provider>? Does <content provider> honor takedowns only from or in preference to blessed accounts? Could one DoS <content provider> in such a manner? If a human has to review all DMCA complaints, would a flood of false claims DoS the human reviewers?
Asking for a friend.
> The DMCA requires that you swear to the facts in your copyright complaint under penalty of perjury. It is a federal crime to intentionally lie in a sworn declaration. (See U.S. Code, Title 18, Section 1621.) Submitting false information could also result in civil liability — that is, you could get sued for money damages. The DMCA itself provides for damages against any person who knowingly materially misrepresents that material or activity is infringing.
That's interesting; is US copyright law enforceable everywhere?
The DMCA works in much the way that its authors, the telcos and the MPAA and RIAA intended it to. To indemnify ISP's in return for their becoming enforcers for rights-holders ridiculously over-broad "anti-circumvention" clauses which lead to outrageous abuses of the law (including anti-trust violations, attacks on the rights of consumers, academics, etc).
Now, Microsoft's lobbying machinery must have been in its infancy back then so the blame can't entirely be laid at their feet. But Microsoft don't seem to be doing anything to help either.
Fundamental to the problem is that youtube-dl (and many others) seem to be obvious candidates for exceptions to DMCA 1201. But the process around those exceptions seems not be working at all. Something which Microsoft appears completely tone-deaf and oblivious to.
So, with respect, I suggest you... get a grip to how you guys are going to be being perceived in this situation.
 Fritz Attaway, policy advisor MPAA. https://www.wired.com/2008/10/ten-years-later/
There is a way forward, Nat. You can reinstate that repo today, and tell the RIAA that they cannot use your online tool. They have to send your legal representation (in Alaska to slow it down) a certified, hand-signed letter through snail mail. Make a big public show of this process, and get public mindshare on your side.
It seems to me that this could be used to cause a lot of damage – target a popular open source project with a totally bogus DMCA notice, even if they instantly file a counternotice they still get made unavailable for 10+ days.
(Also, why 10-14 days? Why not just 10 days or just 14 days?)
> GitHub Asks User to Make Changes.
I think many would argue that the takedown notice wasn't "sufficiently detailed", especially when you consider the 1201 vs 512 issue.
>With potential damages multiplied across millions of users, cloud-computing and user-generated content sites like YouTube, Facebook, or GitHub probably never would have existed without the DMCA (or at least not without passing some of that cost downstream to their users).
Talk about backwards logic
I am going to believe that. Github CEO wanted a reason to open source it, and used a rogue leak in a win-win situation.
Why he didn't sign it to prove it was him? because the desktop client doesn't even have this basic git feature implemented ¯\_(ツ)_/¯ ...and everyone knows managers only uses GUI, Q.E.D.
Unless you’re referring to the generic “our hands are tied” tweet that said nothing: https://twitter.com/natfriedman/status/1321221940774723584?s... in which case, I suppose we’ll agree to disagree on what “all within their power” actually means.
 you failed to read the 1st paragraph of the linked article :)
By the way the serious design flaw where GitHub forges signatures on merge commits I told you about when you joined as CEO... Still not fixed.
The fact a commit can be shown as "verified" in the interface when I didn't sign it with my Yubikey is totally broken.
One issue is that you are loading profile images and creating links based on unverified emails (if I click the little picture next to the commit message I get to the impersonated profile). I mean I get that a proper solution might introduce unacceptable friction, but you can't really blame users for misunderstandings in the current state either.
Maybe add a checkbox in your profile like "Specifically mark unsigned commits" or even "don't associate unsigned commits to my account" as well.
> (!) This user usually signs their commits, but this commit is not signed. [Learn more]
Is what I've been surprised there isn't something like in the past.
> This is GitHub.com and GitHub Enterprise
It also contains linting config, ci workflows, dockerfiles, and other build related files that you probably wouldn't put in an "un-stripped/obfuscated tarball of our GitHub Enterprise Server source code"
The readme seems clearly aimed towards developers of GitHub.com
I am not advocating it - I am making people aware that is what leaks mean.
[I randomly picked 20. Because it's usually a lot of options when you have source code access]
Your comment amounts to "Github's security team should be making sure the dependencies in their Gemfile don't have vulnerabilities". Which is an obvious and pointless statement, yes, of course github's security team should make sure github's code doesn't have vulnerabilities. That's the most important duty of their job.
The fact that the Gemfile has been leaked changes nothing about what the security team should be doing.
Your comment doesn't really contribute to discussion because it's not presenting novel information, and it's misleading because, per the reasons above, their security team's priorities goals/responsibilities/behaviors/etc aren't really impacted by this, and your comment sorta implies otherwise.
That's what I was getting at. It means this list - has more avenues & more options for on-prem risk. For someone who has internal network access to lateral subnet (small example). Because one who chose to can start analyzing methods for privileged code access. CISOs would want to add additional review of the surrounding on-prem network and hardware. Just my thoughts.
> It increases downstream risk to GH enterprise
I disagree with that. People have been able to de-obfuscate and read github enterprise's source code for pretty much as long as github enterprise has existed. Researching security vulnerabilities in it is not really any different.
> Because one who chose to can start analyzing methods for privileged code access.
As above, people already could do this; the deobfuscated GHE code is pretty easy to get your hands on. And the chance of there being a remotely exploitable vuln that exfiltrates code or gives you an admin account.. well, that seems to remain at "pretty unlikely".
If this were to logically follow, than no one would run Gitlab, an open source equivalent, because the source code is available for people to "analyze methods". However, I have a similar level of respect for github and gitlab's security teams, and I tend to think the security of both of them is pretty decent, irrespective of whether the code is leaked, open source, or proprietary.
> CISOs would want to add additional review
I also disagree with that understanding. A CISO in the past would have already decided "We trust github's security practices enough to run GHE here and put our code in it." The fact that the code has leaked changes that not-a-wit. The CISO still trusts github's security practices, and those practices haven't changed.
Instead of making conflict messages clearer and easier to work with using local files, contributors keep thinking the users are too dumb and adding (and changing) merge resolution hacks.
This boils up to github, as can be seen by teams who do not understand the very basic about git commits, and enable "squash commits by default" on their repos. With these teams, git commit history cease to be bit sized changes in a larger changeset, and become useless displays of the author interacting with the remote server while they upload small changes to tests to make the continuous builds get green.
Funds are safu?
But Github uses the same single Git repository for all forks, and they have an issue where you can access a branch/commit of a fork from the main repository if you know its hash. They should probably fix that at some point.
Ah I see, thanks for the explanation. I didn't know this was the case. I thought each fork would have its own `.git` folder. Seems like this approach could allow forkers to mess with the original repo, but maybe Git is designed in a way that this is mostly safe.
bit of a Wodehousian twist there. appreciated.
Robert Browning, Pippa Passes (1901)
A nice one. I didn't know it.
The desktop client explicitly does not support this, why is that?
Git does not make it trivial to impersonate commits.
As you yourself mentioned, very, very, very few projects/people sign their commits. Even fewer actually verify them.
In the same vein, one can spoof email - but DKIM, SPF, DMARC together as controls make it much more difficult.
I am well aware that you can sign commits with Git. I do, personally and professionally, and my coworkers and I are required to, by policy that I wrote. That has absolutely no bearing on the topic at hand even tangentially.
Are you aware of the fact that it is irony in the original work?
Have you read the newspaper in the last months?
I suspect irony on your side and if it's true you are kind of funny...
There are hidden costs to going open source as well as expected ones. Could you imagine the number of PRs, issues and discussions over trivial shit the GitHub userbase would create against an open GH repo? Nightmare. Not to mention code cleanliness expectations and buildability expectations and so on.
Of course they "could do this" or "do it that way," but the fact that they don't should tell you their priorities lie elsewhere, and that's fine. Closed source isn't evil and we have other open source git hosting platforms.
It’s popular because it’s free.
Gitlab has always seemed a little clunky to me from the perspective of running a smaller operation.
Security by oh yuck it's Ruby.
No, it is not.
You "hacked" yourself. A majority of commits are not "verified", and a majority of users don't know to "look for" the verified label. Why didn't you make signing mandatory if you recommend it?
As for repercussions to your mismanagement, I will certainly stay tuned.
In summary: you're fucked.
Also, if users don't know the very basics of how Git works, they probably shouldn't be using it, and certainly not trusting it.