Fair enough, that's a little out of main scope for Xecrets Cli.
Just for fun, I tested now to build and publish for an ARM processor running Linux (linux-arm) and the build worked fine. I don't have a device to test it on though.
So... as long as it runs Linux and has an ARM or ARM64 processor and sufficient storage & memory it could work! (It's not tiny like a pure C-program unfortunately).
I'm the original author of AxCrypt. There's a new compatible iteration of it based on the original cryptography code called Xecrets, with several components. Xecrets Cli is the main fully featured command line engine, free open source GPL on https://github.com/xecrets/xecrets-cli . Xecrets Ez is a simple GUI frontend, single executable, portable. Runs on Linux, macOS and Windows. There are several more components available as nuget packages.
Good question. There's some evidence that not all affected systems has seen this 'all zeroes' file, the first account stories varies. But something was definitely broken in the deployed data. But, once again, CrowdStrike does not paint a clear picture and it raises new questions and only partially answers old ones.
Why is it so hard for manufacturers to just go ahead and explain what really went wrong, without a lot of corporate b..t? Probably, if they do really say what happened in so many words they might open themselves for negligence lawsuits. Hopefully somebody files one anyway. The industry needs to learn to be better, and the only thing that talks loudly enough is probably money. Lost revenue, liability damages, and share holder value loss.
Yes, my article is pretty much speculation - in the absence of a proper explanation by CrowdStrike. (Now there actually is sort of an explanation, but it raises almost as many questions as before). I don't have data for a first hand investigation, but do cite the investigation by Dave Plummer - which of course also contains quite a bit of speculation.
Whether or not "Rapid Response Content" and "Template Instances" are Turing complete is unclear, but the fact of the matter is that according to CrowdStrike "problematic content in Channel File 291 resulted in an out-of-bounds memory read triggering an exception", so the interpretation of the content is at least fairly complex. CrowdStrike also states that "Each Template Instance maps to specific behaviors for the sensor to observe, detect or prevent", and mentions a "Content Interpreter". Whether it's code or configuration data is not really relevant though, the point is that it's interpreted by a kernel mode driver which did not have sufficient validation of it's "Content" to prevent the crash.
Well, you don't want a fancy anti-virus update to rip through the global population of customers, effectively killing 8.5 million systems (according to an estimate by Microsoft) either in the space of approximately 78 minutes, right? What possible malware threat warrants that risk? And in this case, according to CrowdStrike, it was "to detect novel attack techniques that abuse Named Pipes". That doesn't really sound like such an urgent situation.
It is kind of obvious, isn't it? But I've yet to see any hard questions asked in main stream media about the process of simultaneous global rollout of "content updates".
But in a recent update of https://www.crowdstrike.com/falcon-content-update-remediatio... they have a long explanation of of things are supposed to work, with a lot of nice words (sounds almost AI-written...) and quite a few implications that it's really the customers fault who have not configured their systems to for example stay one version behind the latest and still a very short explanation of what went wrong.
But... Lo and behold, what are CrowdStrike going to do to avoid this happening in the future?
"Implement a staggered deployment strategy for Rapid Response Content in which updates are gradually deployed to larger portions of the sensor base, starting with a canary deployment." About time...
My main point, and the reason for the title, is that this has not been the major takeaway in main stream media analyses. Of course not "everyone" has missed this, but pretty much all media articles about the incident do appear to miss this.
Right, they write rather cryptically "This is not related to null bytes contained within Channel File 291 or any other Channel File."
That's not quite the same as saying "This is not related to Channel File 291 containing all nul bytes."...
I don't have first to hand knowledge here, but rely on Dave Plummer's statement.
Regardless of zeroes or single files or not, the fact is that bad data in C-00000291.sys in combination with bad validition in the driver causes it to crash. Deleting C-00000291.sys causes the driver to stop crashing.
Anyway, my main point isn't really about this. It's about the big bang global roll out simultaneously to at least 8.5 million systems in one go that's irresponsible.
The driver architecture is the lesser evil here, although it's bad enough!
Yes, since CrowdStrike won't tell us, we'll have to rely on our own or third party analysis. As I write "Since as usual the company won't release any detailed information on what really happened, we'll have to rely on other sources. I found that Dave Plummer's account on YouTube was very good, and trustworthy."
But, absolutely, probably is a required qualifier for some statements about the details.
What is definitely known is that a WHQL kernel mode driver from CrowdStrike crashes, and removing a single file external to the driver causes it to stop crashing. Some pretty sure conclusions can be drawn from that. No "probably" required.
Interesting, do you have a link to this statement? Also, do they state what did cause the crash? At least removing the file of zeroes does solve the problem, as the instructions both from Microsoft and CrowdStrike states "Boot into safe mode. Delete C-00000291*.sys." That's the file(s) with the zeroes... See https://www.crowdstrike.com/falcon-content-update-remediatio... and https://www.youtube.com/watch?v=Bn5eRUaMZXk (3 minutes 20 seconds in).
Ok, maybe I was to quick to judge, I didn't spend enough time studying it. I looked at some screen shots, and it seemed like the translation tool knew things about the app, but I was apparently mistaken. Sorry.
Well, that's what the setup I have does, almost. If you consider .po/.pot to be a unified format file. I extract the original texts, comments and internal names from the resx into a .pot (Portable Object Template). This is then sent to a translator-centric web site service. A translated file is then exported, although I export it as a .po file, and then use a library and a little bit of my own code to implement an IStringLocalizer. As someone said elsewhere, more and more services do support .resx directly, so I could consider skipping the .po handling in my code, and just use the .resx.
As for bloat, I find the .po format to be quite bloated, with it's use of the full texts as keys in each and every translation. I don't really like that, but in practice it appears to be working well and has been for many years. Then again, the obvious choice today would be json.
Nice, but perhaps a little pricy for small startups. That's actually one of the things I didn't emphasize perhaps. Not only is the gettext/.po eco system big, there's also a lot of free or relatively low cost services available.
Nice, very ambitious! I like the twist to extract from the compiled IL code, much easier, more stable and reliable than parsing the source. My one gripe here is that the code does not follow the .NET paradigm of using resources at all. Still, very clever and a lot of functionality.
If you're referring to my app, Xecrets Ez ( https://www.axantum.com/ ), it runs in Windows, macOS and Linux.
As mentioned, the issue I'm trying to solve is not the code end. Resx works fine once it's there. It's the translator end. How to present the texts and translations and context etc to the human, often non-technical, translators and often many and one translator might only translate a few strings, then another one etc. So it has to be real easy to use and gain access to. Can't for example ask them to install a piece of software. Finally, once a text has been translated, how to get it back to the app as easy and preferably as automated as possible.
Quite so, and in the case of resx, that's exactly what you're getting. A list of key-value-pairs, no support for pluralisation either (as you say, it gets hard. I understand Polish for example is very complex, perhaps Russian is the same?).
I never had a problem with resx and .net satellite assemblies and all that as far as the format goes. But it's always been an issue how to involved translators in a way that's both simple for the translators, safe for the quality and as automated as possible in bringing the translations back to the app.
Nice - but very special purpose from what I can gather. I've done a few custom solutions myself over the years, but that's exactly what I'm trying to get away from. I want to write code that does cool stuff for the users of my apps, not code that does cool stuff to make translations possible - someone else can do that cool stuff ;-) where I'm the "user".
Just for fun, I tested now to build and publish for an ARM processor running Linux (linux-arm) and the build worked fine. I don't have a device to test it on though.
So... as long as it runs Linux and has an ARM or ARM64 processor and sufficient storage & memory it could work! (It's not tiny like a pure C-program unfortunately).
Would be cool to try...!