最近の検索
検索オプション
![publicvoit](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="300" height="300"><rect fill-opacity="0"/></svg>)
@publicvoit@graz.socialAfter basically the whole #Microsoft #Azure cloud was hacked (see list of related sources on https://karl-voit.at/cloud/ ), the first follow-up incidents went public caused by missing containment actions:
60,000 emails were stolen from 10 #USA #StateDepartment accounts
https://www.reuters.com/world/us/chinese-hackers-stole-60000-emails-us-state-department-microsoft-hack-senate-2023-09-27/
If you didn't understand until now: basically EVERYTHING at Microsoft got hacked and Microsoft can't (or won't) get rid of the intruders. Everything authenticated by Microsoft is tainted. Even #Windows auth.
If #Microsoft has any (internal) trust relation between the hacked #Azure certificates and #GitHub, we need to consider GitHub as hacked/tainted.
Now that I have migrated some of my hosts to #NixOS, I do have a bad feeling because of #Microsoft and most probably GitHub being hacked.
As mentioned on https://www.karl-voit.at/2023/09/12/nix/ the deep #GitHub dependency turns out to be a real downer for this OS.
@publicvoit Could you go a little bit more in depth about:
> Microsoft can't (or won't) get rid of the intruders
P.S. I must admit I didn't read your article on karl-voit.at; was a little bit too long sorry 
@yaeunerd Sure.
In simple words: #Microsoft lost one of their master keys to unlock very important parts of their cloud. This connects to all MS services that do authenticate by MS which includes most #Windows setups as well.
This happened long time ago, some people think it was the Chinese.
They were able to implant #backdoors, self-made keys, ... all over the place.
In order to fix that, MS would need to kill all their connected hosts and start from scratch. It's obvious why they don't.
![alastair@social.alastair87.me](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="400" height="400"><rect fill-opacity="0"/></svg>)
@publicvoit@graz.social @yaeunerd@fosstodon.org I would expect there are Chinese spies working at Microsoft as well, probably also other large cloud companies.
@publicvoit I *love* that you're keeping such a long historic list!
Reminds me of @mjtsai's Review Rejections at https://mjtsai.com/blog/tag/rejection/ or https://web3isgoinggreat.com/ :)
(It's also horrible that the list could become so long.)
@publicvoit@graz.social Wow, that really sucks for users of Microsoft products and services. Oh, well! 
@adiz This does not only affect #Microsoft and their direct services.
This also affects all customers of Azure and their services.
You don't know what services you're using whose back-end is hosted in #Azure.
@publicvoit@graz.soc Damn ,that sucks for people using Azure.
@publicvoit @adiz Services shouldn't really be trusted as far as one can throw them though.
If their computation cannot be (and isn't by default) verified locally, they should be avoided entirely.
@adiz
The whole justice system in the UK is on Microsoft SaaS offerings :D
Many education systems around the world too
@publicvoit
@publicvoit Fuck me, I had no idea, the volume of this shitload is unreal.
@publicvoit I hear so many positive things about this on various podcasts (you probably know the ones), but I once tried it and couldn't even get to a useable desktop environment. That was a while back but I will stick with other OSs for now; and maybe if I go immutable I will try #Fedora first
@davidoclubb @publicvoit "couldn't even get to a useable desktop environment" .
What ?
I have installed NixOs many times since I slowly started looking at it in 2016 or 2017...
And I have had many problems with corner-stone situations, some needed packages broken in the current branch, or learning the architecture of nix package expressions in nix language, or with other package-managers not interfering really well like python pip or conda or perl cpan...
But I have NEVER had a problem of having a non-useable desktop environment.
NEVER. Just to tell you, although it is only my personnal experience of NixOs.
Have you checked the MD5sum of the installation ISO that you had downloaded?
> For example, when GitHub would be out of business or the service is down for some other reason, NixOS would probably be dead. Its main repositories are on GitHub and there is no obvious fall-back concept to other repositories hosted on different services.
This is just plain false. Flakes and channels can point anywhere; the only thing that'd need special care to move is the registry repo that points to all the other repos.
@monk Yes. And at least in my case, they all point to GitHub.
@monk And my point is: all defaults of the NixOS installer are pointing to a hacked platform where anything could be manipulated already.
Copying a tainted dataset still results in a tainted dataset, independent of the trustworthiness of a different hoster.
@monk So, yes. Let's trust Microsoft once more and delete everything since 2021-04. 
@publicvoit @monk
https://discourse.nixos.org/t/could-microsoft-master-key-hack-impact-nix-via-github/33652?u=alper-celik
Is interesting discussion about possiblity of an attack.
![IslandUsurper@fosstodon.org](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="120" height="120"><rect fill-opacity="0"/></svg>)
@monk @publicvoit I can understand why someone would say it, though. By default, the flakes registries and the previous channels both point to GitHub URLs. They don’t have to, but it’s not obvious that they could be different.
Two big things I would worry about if GitHub became unusable for any reason: 1) nixpkgs is friggen’ huge, in terms of size and activity, so picking a forge successor must be done carefully. 2) issues and PRs are hard to migrate.
@monk @publicvoit none of these problems are actually specific to GitHub, I think. It’s just what Nix uses currently. Communicating the change when necessary takes the same amount of work regardless of the host. Maybe the issues/prs migration can be easier with better tooling elsewhere.
A disaster plan sounds like a good idea. I hope someone has one, but I haven’t heard of it.
@publicvoit While I agree with you, there are issues, I worry that your framing is flirting with baseless conspiracies as you seems to be ignoring that there are many safeguards in place to avoid letting GitHub corrupt the whole project.
Even if we didn't use GitHub, you have to understand that NixOS / Nixpkgs cannot force anyone we are consuming packages of to migrate somewhere else.
Either case, I think this is kinda FUD…
@raito I can't follow your accusation.
The facts show that Microsoft got compromised since at least 2021-04.
There is no claim by MS I know of that GH is completely separated from MS infrastructure that got compromised.
Current NixOS setups are pulling from GitHub which belongs to Microsoft. Yes, this can be changed but that's not the point here at all.
As far as I know, you can't protect yourself from a bad actor that has more or less full access to the GH infrastructure and backends.
1/2
You are jumping from MSFT got compromised at time T to MSFT is still compromised and all GH repos are compromised with full capabilities for attackers. This is one of my accusation.
> As far as I know, you can't protect yourself from a bad actor that has more or less full access to the GH infrastructure and backends.
Assuming this without proof is, to be honest, conspiracy.
I don't like Microsoft neither, but this is ridiculous.
@raito The bad actors had years of more or less full access to MS infrastructure.
Actors that can pull off such an attack are perfectly well aware of what to do so that they keep access when the original attack vector is not available any more.
This is standard procedure for each intrusion attack.
Furthermore, in such a situation, the original bad actors can provide any sort of access to interested parties.
Yes, it's hard to digest but that's absolutely standard IT sec reasoning.
@raito Furthermore, it's not just me who tries to explain the implications. Please read other sources that quote various security experts and how they judge the impact of this incident.
Assuming that nothing happened to GH is understandable from a project's point of view (effort! trust!) but nothing more than wishful thinking without any proof.
In IT sec, you always(!) assume the worst case just because of that. You can never be sure otherwise.
@publicvoit @raito Does NixOS not independently sign its updates and use checksums of the aggregate repo contents (not trusting git's mostly sha1-only setup) like Guix?
If it does those two things, there's very little a malicious host could do other than denial of service.
If it doesn't then uh yeah, it's broken and really should fix that post haste.
@publicvoit@graz.social @raito@nixos.paris One thing GitHub may have going to it is that it's still descended from the pre-acquisition infrastructure. It has now been tightly integrated into Microsoft though and I assume much of it is hosted on Azure. But they still use e.g. Ruby, MySQL because that's what it was built with to begin with. Much as Hotmail continued to run on UNIX for a long time after Microsoft first bought it.
@raito 2/2
Yes, there is no proof or indication that anything happened to any GH repository yet. 
However, in IT security, you don't rely on lucky guess. A compromised network is still a compromised network and needs to be restarted from a clean status.
It doesn't look like MS is going to setup major parts of their infrastructure to introduce trustworthy hosts again.
So where's the FUD in terms of reasoning?
> So where's the FUD in terms of reasoning?
> It *doesn't look like* MS is going to setup major parts of their infrastructure to introduce trustworthy hosts again.
I think you answered yourself very well.
In IT security, lucky guess are not primitives to build threat models. Hypotheses, assumptions, economics, politics, technical measures and careful analyses are.
What you are doing is just lucky guessing that MSFT didn't do any form of "reasonable" due diligence.
@raito After years of having a (potential) state actor in the back-end of MS, I'd be very interested in your assumptions that they really did not perform lateral movements and expand to linked networks.
No tech measures can mitigate or contain such an attack that lasted for so long in retrospect.
From an politics/economic perspective, we agree. We see what the economic decisions were already.
But that is strongly orthogonal to IT sec reasoning. Trade-offs won, as usual. But no proof.
@publicvoit But then, assuming the level of catastrophe you are describing.
What value is there in using a modern computer? NixOS/Nix is not the only thing affected. systemd is in GitHub, systemd developers are from Microsoft, etc, etc.
What is the usable advice we can get out of your whistleblowing?
@raito I'm not a whistleblower at all! I just quoted articles published by MS & independent sources.
I never said that we should stop using NixOS, systemd, ...
We just need to be aware that there is no such thing as a trustworthy cloud infrastructure most probably anywhere except you deal with it yourself to some degree.
All projects that rely on a pot. compromised infrastructure need to invest in mitigation measurements against malicious infrastr. which wasn't discussed so far AFAIK.
> All projects that rely on a pot. compromised infrastructure need to invest in mitigation measurements against malicious infrastr. which wasn't discussed so far AFAIK.
We already touched base on some obvious mitigation measures we all enjoy thanks to the concept of Git repositories.
We have many more because of how nixpkgs works, but I admit I am slightly annoyed because you seem to be ignoring them and you didn't contact any expert matter, I assume?
> I never said that we should stop using NixOS, systemd, ...
> We just need to be aware that there is no such thing as a trustworthy cloud infrastructure most probably anywhere except you deal with it yourself to some degree.
Right, but what you are saying is that NixOS is particularly reliant on GitHub whereas *everyone* is reliant on GitHub so…
@publicvoit It doesn't have anything like Guix's fallbacks to (among other things) the #SoftwareHeritage archive?
That's all kinds of unfortunate.
@publicvoit many years ago (the 90s) if you were online you assumed everything you said and did was getting scraped by the NSA/ Americans. I don't think much has changed. If you want to keep something private, try to keep it off the web.
It is safe to assume (big) nation states have access to everything, or if not, hoover up everything they can and will have access soon enough.
@roomey Well, I somewhat disagree here.
If you assumed state actors, especially USA state actors you may be right.
However, now it's some hacker group that can share their knowledge with anybody. So the potential group of attackers is now extended to basically anybody who somehow was able to get in touch with the hackers who hacked Microsoft.
That's a totally different game now.
Furthermore, it's not only privacy that's in danger here. It's the whole set of https://en.wikipedia.org/wiki/Information_security#Key_concepts
@publicvoit it was my understanding that this "hacking group" _was_ nation state.
Either way, the rest of your comment here is correct in terms of what's at risk. Best to assume compromise at some level.
@roomey Attribution is extremely difficult.
Some say it's the Chinese.
But at that level, any hacker group (state or non-state) is able to fake attribution hints of any sorts.
So we basically have no clue who did that and furthermore, who was given access to the special backdoors after.
@publicvoit We really need an user-friendly alternative to #GitHub. Love seeing that both @forgejo and #GitLab work on ActivityPub support. Can't wait to try it out.
@stdevel @publicvoit @forgejo Are you referring to this? https://docs.gitlab.com/ee/architecture/blueprints/activity_pub/
How is that not already completely solved by the git e-mail workflow?
Feels like reinventing the wheel.
I have really been baffled by the widespread loyalty to Microsoft by the #FreeSoftware community. I wonder if you have the answer… is it really user-friendliness that causes FOSS devs to embrace #Github with such strong loyalty as to ignore marginalization of people communities excluded by MS? I think of developers as quite technical so I would not have thought user-friendliness is that critical to a forge. #askFedi
@batalanto my first guess is they embrace GH because it's been here for ages, and it's the largest global platform you can contribute to. Having 20 accounts in different instances just so you can help with projects sounds tedious. I'm not much for a dev, and i love selfhosted git platforms but a central one is often much more... dang... "user friendly"
@dobody The lazy login theory has to be the most popular one I keep hearing. I don’t really grasp it because #Github is login-hell for me:
1) submit login creds over tor
2) go to bogus disposable email provider for the address on GH files
3) possibly get blocked by captcha
4) get 2fa code if not captcha-blocked
5) go back to Github to enter code
Every Github login is more cumbersome than a #gitea *registration* process.
Are most Github users using a real email address (thus giving up privacy) to login? Or using clearnet? I’m not sure if tor triggers special treatment that imposes 2FA.
Why are #freeSoftware developers so loyally hooked on #Microsoft #Github?
(lazy login theory: users have little tolerance for multiple accounts regardless of how easy gitea registration is)
@batalanto /cc @stdevel @publicvoit
why isn't it possible that they are loyally hooked because it's the most widely used centralised git site, since even before it was acquired?
EDIT: this is vendor lock-in and it's a bad thing, but it's explicable
freezr @batalanto @dobody @stdevel @publicvoit
Because are mostly concerned about the corporate retaliation of not being there...