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).
Maybe it's not MS on paper. But the DNF looks like it would be fully under MS control.
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.
Also, this is about the .NET Foundation not Microsoft.
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.
Smacks of social engineering to me.
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.
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."
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.
How's that not social engineering?
"(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.
That part reads really fishy.
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.
I don't know, I don't own a GitHub Enterprise to try.
If there where changes post MS acquisition of GH to this parts this would look like planed long hand.
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.
Meh. I might be more interested if I actually had a GitHub Enterprise myself.
It would appear there's a backdoor system for them.
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…)
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.
What was not expected was the move to GitHub Enterprise while the CLA bot was fixed.