I mean, they’re clearly heading toward stealing control of associated open source projects away from the founders/maintainers so I don’t think there’s even room to discuss “repairing trust.”

You might discuss repairing trust with a burglar you caught in your house after his criminal trial. At this point, Microsoft is the burglar and he’s still in your house with the ski mask on (unless you would prefer for the burglar to be a she).

With all due respect, this simply doesn't make any sense. The projects are all released with OSI approved licenses. To use your analogy, all the stuff is already on the front lawn with "For Free" signs.

Also, this is about the .NET Foundation not Microsoft.

I said "stealing control of"

I didn't say stealing the code.

Also, the .NET Foundation is Microsoft because a Microsoft employee is doing all of this behind the scenes.

They are not stealing it because in most cases they... Legally ... own it. However, doing something behind the back of the people operating it is tone deaf, stupid and shows a great degree of arrogance and mismanagement. They pulled nuclear options dozens of times in this move. For what: to reorganize billing and streamlining processes. That is not good enough a reason to go nuclear on a maintainer w/o conversation.

.NET Foundation is not Microsoft.

After reading the blog posts linked form this one I would consider this statement very questionable.

Maybe it's not MS on paper. But the DNF looks like it would be fully under MS control.

Indeed.

I think those affected have commendably kept their cool so far but I’d say this (diversity Trojan horse, “we need full control to enforce the CoC, whoops you’re fired goodbye”) is a playbook that will be often repeated in the coming years.

Only 2 of 7 board members are microsoft

One of them is the founding member appointee with veto rights.

These projects gave the .NET foundation admin access and then the foundation moved the projects. No insider access needed.

"Gave" is generous in that it fails to mention how that access was gained - supposedly needed for a tooling account to ensure inclusion/code of conduct guidelines being followed, IIRC?

Smacks of social engineering to me.

No, not supposedly, really.

We had a new repo where the CLA bot was not automatically working. I was busy with a deadline so to unblock the team, I granted admin access.

It wasn't social engineering. I did it. I just didn't realize what was going to happen after doing so.

I explain it all in the post.

My apologies, I read your post and understood the bot access part. However the timing of it sure as looked smelly to me, that's why I wrote "supposed".

I probably shouldn't have speculated it was all a set up, but even if it wasn't all kicked off with that intent, how it was then used sure was not ok. It reeked of trickery and deceit, which I construed as social engineering from that point of view - hope that makes sense (edit: #1).

Kudos on handling this, and hope you're doing well all considered. It was fantastic to read how you claimed the ownership back.

#1) that they requested "Yesterday we announced Foundation-wide Code of Conduct Enforcement. Part of making that work requires that the dnfadmin GitHub user has owner permissions to GitHub organizations."

No problem. I'm really just trying to keep the story straight.

The only issue I have with the timing is that I told them I was not comfortable with them as admin on the repo yet as soon as they were made admin (to fix the CLA bot, which happened to be only a week or so after my email) this happened. No social engineering necessary but really poor timing on top of non-existent communication.

And here we are, sadly.

Understood, and cheers.

> It wasn't social engineering. I did it. I just didn't realize what was going to happen after doing so.

How's that not social engineering?

I'm thinking the Oxford definition was used here by the author (ie tricked into giving up a password):

"(in the context of information security) the use of deception to manipulate individuals into divulging confidential or personal information that may be used for fraudulent purposes."

I didn't really want to argue it any further as the issue was inflamed, but I absolutely think that when an account privilege was requested purely for "trivial thing A and we really really need it because think of the children", for it to then be used in the next breath for "evil thing B" - then what else is it but a more sophisticated social engineering attack? (I would certainly like to know if there's a better definition of it.)

For the benefit of the doubt there could very well be things going on in the background where the account access was discovered by someone else than those who requested it, and then jumped on the opportunity. However that's giving a fair bit of leeway.

Article has a whole section on how @dnfadmin was given owner access, in a sneaky way (for a different context) - and how that was a mistake.

And how they suppressed the e-mail notifications to the (real) owners about the move of the org?

That part reads really fishy.

Someone answered my question:

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

That seems very strange given the fact that GH sends otherwise mails for almost everything done there if you didn't disable it.

Someone else noted that it may only send emails to the person that kicked the process off.

I don't know, I don't own a GitHub Enterprise to try.

Is it possible that anything which @dnfadmin is an owner of is automatically migrated by GitHub the moment it becomes an owner? Maybe they never realized that what happens?

I don't think there's any reason to believe that? That's why a good chunk of the story is setup leading up to adding dotnet foundation as an admin.

The fact that moving WiX out of public Github did not generate any emails while moving it back did generate a lot of emails is the suspicious part. There's probably an utterly mundane explanation as to why, but it's also possible that there's a MS-only "move this repo without notifying anyone" option.

Moving it out back to public GH was done by transferring the repo(s) between organizations. The move into GHE moved the organization as a whole to GHE. So it's conceivable that moving organizations as a whole to (or even from) GHE does not send emails. To be clear that's still bad, especially given how the user could only know of this move if they were logged in and looking for one tiny bit of text in the repo homepage, but it's a non-malicious explanation.

If that's true and GitHub doesn't send mails for this particular thing, even it sends mails for more or less anything else if you don't disable it, paired with the fact that such a change is almost invisible if you don't know what to look for, makes it even more suspicious.

If there where changes post MS acquisition of GH to this parts this would look like planed long hand.

Repeating myself but it's applicable here too:

I'm curious about this too. I was told (by someone at GitHub) that the features I used to do the move are brand new and were not expected to be used the way I did. It is very possible pieces are missing in the audit trail GitHub creates.

Meh. I might be more interested if I actually had a GitHub Enterprise myself.

I'm curious about this too. I was told (by someone at GitHub) that the features I used to do the move are brand new and not expected to be used the way I did. It is very possible pieces are missing in the audit trail GitHub creates.

Meh. I might be more interested if I actually had a GitHub Enterprise myself.

There is no "special" access in GitHub, and no person as far as I know has such an access. I work at Microsoft, but GitHub side is very detached so I don't think there was any collaboration.

It would appear different. Microsoft stealing projects into a private enterprise space is a different action than putting them back to public. Stealing generates no emails, but restoring to public generates a lot of emails.

It would appear there's a backdoor system for them.

I've been an admin of an organisation that was moved into an enterprise org (with consent) and can confirm that this does not generate emails for the child org.

As I read it, there’s two different things happened. The foundation moved a repo they were given owner (or maybe admin) access into an enterprise GitHub account, which doesn’t generate a noisy trail of email.

The OP used a workaround of starting a new GitHub project a couple of project renames, and a project transfer - which did generate a flurry of notification emails.

(I’m surprised the “move into enterprise account t” action doesn’t at least notify all owners on the account. If it normally does, and these ones didn’t, that’s a super bad look for both the foundation and GitHub…)

What's the difference between "moving a repo...into an enterprise Github account" in the first paragraph and a "project transfer" in the second? I would have thought that "project transfer" is just another term for "moving a repo into a different account", so the only thing that seems different is going to enterprise versus going from. It seems kind of odd that email notifications wouldn't be the same in both cases.

I assume moving into an enterprise account is a single click (although I've never dione it, so :shrug:).

The workaround "project transfer" used/suggested for getting back _out_ of that enterprise account gets explained in the article like this:

1) Create a new GitHub organization, normally. For example, name it new-yourorgname

2) Rename your organization in GitHub Enterprise in the Settings to something like, dnf-yourorgname

3) Rename the organization from step 1 to your desired organization name. You want to complete this quickly after step 2 so no one takes your organization's name.

4) In the GitHub Enterprise dnf-yourorgname go into each repository's Settings and transfer the repo to the brand new yourorgname organization.

Not at all surprising that generates a flurry of emails, especially since in the authors case step 4 needed too be done 44 times, once for each repo in the org.

There is no reason to suspect that they did. As I wrote, I granted admin access to my GitHub organization. No other special access was needed after that.

I would be willing to bet it is just a "feature" of GitHub Enterprise. Automatic migration of anything an enterprise user owns.

listening to the wix video linked elsewhere here, they were essentially duped into adding a bot for other reasons

No. I was never duped. We've always had a CLA bot (a assignment agreement and later CLA was always requirement since the project's release in 2004).

What was not expected was the move to GitHub Enterprise while the CLA bot was fixed.