If they used some special microsoft insider access to github to move these projects... that's gonna really harm trust in github. They really oughta make it clear that they did NOT do this, or make it clear how it can never happen again.
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.
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.
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.
"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?
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.
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.
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?
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.
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.
