Hacker News Reader

Comment by jug | Hacker News Reader

Sounds sketchy given what the employee from Microsoft commented. The article is also not completely up to date with their “interesting” findings. For example, while a language projection for the Windows Runtime to Rust is interesting, it is also a public repository: https://github.com/microsoft/winrt-rs I’d take this article with a grain of salt until we hear more.

View on HN

I am pretty sure anything from Microsoft on GitHub is intended to be open source eventually. Theres no reason they dont have proprietary projects in their own internal version control systems.

Considering Microsoft owns GitHub, there's no reasons their internal teams aren't choosing to host more code on there.

They also have a competing service: Azure DevOps (formerly Team Foundation Server, Visual Studio Team System), which somehow has barely anything to do with Azure.

I believe that the stuff they're open sourcing go on GitHub, while the internal tools go on Azure DevOps. They also have their own VCS (Git alternative) called Team Foundation Version Control (TFVC), though I have no clue why they keep that thing around. They've also had Microsoft Visual SourceSafe, but even they themselves didn't really use that.

On a side note, they really suck at naming things.

Azure Devops is increasingly based on the same code as Github.

Github Actions and Azure Devops Pipelines, for example, utilize the same infrastructure in my understanding.

It's a lot nicer to use on the GitHub side, and more organized (.github/workflows/foo.yaml vs a yaml in the root of the project for all "Actions")

Azure DevOps does not require a YAML file in the root of the repository either - it's quite common to have them in a 'ci' folder.

While I prefer GitHub Actions in most respects, duplicated setup work and jobs are handled much better by the Azure version currently IMO.

> which somehow has barely anything to do with Azure.

This is some weird Microsoft thing. I think Windows 10 development is now handled by the "Azure" org[1]

[1]:https://www.zdnet.com/article/how-microsofts-azure-organizat...

They probably had their own internal version control for their IP before they bought GitHub. Can't imagine they suddenly migrated all their stuff to GitHub.

That acquisition happened a blink of an eye ago, in the grand scheme of things. Things don’t change that fast, especially when you have the sheer amount and scope of DevOps and integrations that MS has. With the possible (but even then still unlikely) exception of greenfield projects, there’s basically no chance that anything but open source (or soon to be open source) MS projects were hosted on GitHub.

Not my field, but security would clearly be a greater issue for repos held in a publicly accessible site vs those only accessible over a VPN.

Sure, dogfooding is good, but commercially sensitive repos would seemingly - to my naive view - be better on private servers?

GitHub has an offering you can run on your own servers: GitHub Enterprise Server

Microsoft had multiple Github Enterprise accounts before the acquisition, owned by multiple teams independently inside of Microsoft. They chose to use these instead of Microsoft's own internal repository (some VSS-based thing I think), which management ordered them to use.

More internal Microsoft code was being hosted by Github instead by Microsoft.

However, the Microsoft account on Github seems to only be public repositories, or repositories being prepped to be public. Actual internal stuff is hosted by one or more Github Enterprise accounts, the alleged hack does not claim they were hacked as well.

In this sense "hacked" doesn't make sense. 8f everything was intended for open source.

I think there are still two concerns here even if everything is intended to eventually become open source.

One, this doesn't address exactly how the repo was compromised. Likely one of the many folks with access had their credentials compromised, but until we know, there may be risk to other projects. Two, as the article mentions, it may not have had all passwords or API keys scrubbed.

The culprit would now have the ability to merge pull requests and make changes to the open source codes master branch. So if one of these owner accounts was hacked. Then yes this is a hack.

Having openpgp-signed commits would prevent such an issue.

Would it?

Couldn't the "hacker" have simply generated a new GPG key and added it to the account he had control of?

The users would have specific keys trusted.

Sure, but isn't the point of git to be able to roll back all changes on any branch? And since GitHub is owned by Microsoft, they themselves would surely be able to regain ownership of the account.

This seems like a non-story.

How much code with malicious modifications has been pulled from these repos since then? There's no evidence this happened, but we can't just handwave it away with "we can undo changes".

Ah source code at MS. Always amusing to me. VSS [1] (Visual Source Safe) was terrible and I always wondered how "real" companies could use it. From what I heard, MS never did use it, they bought it and sold licenses. That's it.

That being said, Microsoft actually moved Windows to Git [2] years and years ago. Presumably they did the same with everything else. Team Foundation Server (TFS) supports Git, so they probably have the critical stuff on that TFS still, rather than GitHub. Especially since those repo's are huge.

[1] https://en.wikipedia.org/wiki/Microsoft_Visual_SourceSafe [2] https://arstechnica.com/information-technology/2017/02/micro...

They moved to Git, from what I can tell as an outsider, as part of the "Balmer fucked Microsoft" clean up duty that produced a toxic and soon-to-be-fatal culture over there.

Github ended up being the final piece they needed after years of effort. Most of what I said in the earlier comment was what I pieced together from multiple (ex-)Microsoft people who chose to talk about it, over years.

TFS afiact started as just a repo manager (in the sense, does what Github does) for VSS and Perforce, with more modern support for other things, including Microsoft's gargantuan Git monorepo... but a lot of people at Microsoft still like Github Enterprise better.

I imagine given this, whatever TFS does better, Github Enterprise will learn to do over the next few years. Microsoft is big on eating their own dogfood now, but they don't seem to want to do Google sillyness where they have 20 products that do the same thing and let them fight it out in FFA arena combat (even Lync is still Lync underneath, it just keeps getting new frontends).

> Lync is still Lync

mmm.. I know what you're saying but the change to Teams from a VOIP perspective substantially changed some of the under-the-hood stuff. They stood up a facade to offer luke-warm integration from SfB/Lync IP phones (authentication and basic calling, but that's about it). AFAIK this wasn't just a breaking change but a re-arch of some of the backend. Point being, they may be evolutions but the move to Teams is not just a new front-end. Substantial evolution has happened since we first installed server stacks to support Lync, even though we still see Lync fingerprints and junk dna everywhere.

Actually if you are taking a stab at Teams I met a developer who said the lead architect did work on Lync but it is in fact from scratch.

I left Microsoft around 2013 when the transition to Git was announced.

At the time, most teams (that I encountered) used something called Source Depot. I was told that back in the day, MS licensed the source code from Perforce, forked it, and that became Source Depot. I do know there were some teams using TFS and I'm sure there were some smaller teams using Git too.

I'm not sure how the transition went, since I left before it started, but I would bet it's still at least somewhat ongoing. Some of the people on my team that had been at MS for awhile were EXTREMELY skeptical of change.

> some VSS-based thing I think

It was Source Depot, a fork of Perforce.

However, IIRC they moved to a git based Git Virtual File System for windows development a few years back..

>Git Virtual File System

Hows that coming along, I wonder.

It was released, and was used for the Windows repo. Search "vfs for git" - it's open source.

Then macOS removed kernel extensions, so they came up with a different approach and released that too. Search "scalar" to see it.

It may be useful to note that "scalar" is mostly (albeit not entirely) a git (auto) configuration tool using (now) built-in tools like sparse checkouts and sparse checkout "cones", it shows how much of Microsoft's improvements have made it upstream into git itself. (And it is a stated goal of "scalar" that everything eventually should be.)

Microsoft moved from VSTS Source Control to Git over 3 years ago.

VSS hasn't been used in a decade or more.

Right, I last used VSS in like 2008 or so and it was a pretty tired old tool by then. I mean, it worked, especially in the world it was built for in late 90's (corporate on-premise LAN stuff) - I can't remember any big complaints with it, although I do remember an occasional corruption, but was never f'd over by it. Unsuitable to the distributed and scaled world of today for sure.

Microsoft is moving everything to GitHub. We were at a MS training center recently for Azure DevOps training and the trainer said they were porting DevOps features without equivalent to GitHub and bringing a few things like YAML to DevOps in preparation for the transition.

Reply on news.ycombinator.com