Es könnte aber auch genau so gut sein dass z.B. die Ankündigung einer Werteunion-Partei-Idee von Maaßen dazu führt dass die rechtsextremen Teile von CDU/CSU erst mal abwarten was damit passiert.
Sorry, aber jetzt ziehst du Sachen arg an den Haaren dabei um deine erste Schlussfolgerung zu rechtfertigen. "Abwarten und Tee trinken" wäre eine deutlich stärkere Antwort gewesen, ich habe nicht umsonst Indiz statt Beweis geschrieben. Es sagt wirklich fast gar nix aus. Mit einem Prognoseverlauf aus einem anderen westeuropäischen Land zu argumentieren wäre bei der aktuellen Datenlage wohl das Bestmögliche. Ich habe das Fehlinterpretieren von Statistiken sowie das oftmals daraus resultierende Kreisgewichse einfach satt.
I möchte sie wirklich nicht verteidigen. Dass die Prognose der AfD nach vorherigem Aufwärtstrend stagniert, ist aber eher ein Indiz, dass es funktionieren könnte als ein Beweis für das Gegenteil.
chezmoi.io is one of the best dotfile managers available. Great template language if you need different, many ways to distribute secrets safely, merging works well even with templates, not limited to homedir.
I'm suprised the family didn't have UPS & generator at their house when a member's life depends on a running machine. It's not like many people built batteries in their homes just to store their solar energy. I highly doubt that a BYD is cheaper than a generator.
I absolutely dislike the hate for systemd. Especially if there's bullshit claims like
having both sets of tools installed can increase the attack surface.
in there.
larger attack surface compared to runit, openrc, or sysVinit.
Because they don't execute million lines super thoroughly checked shell code or why exactly? Without any explanation total FUD.
Some independent binaries from the systemd project, e.g. systemd nspawn, can even used on OpenRC and the systemd project explicitly didn't change the way to launch udev in debug mode because the Gentoo non-systemd udev pkg maintainer asked to not do so (nicely).
You should instead tell people why OpenRC/runit is (more) awesome in your opinion and maintain initscripts for them. Maybe you can volunteer at the Debian project and get them to adopt OpenRC aside systemd instead of only removing the remnants of sysVinit support. This would also be beneficial for pragmatic pro-systemd users that have to deal with docker or chroot environments.
Aus Interesse: Wie sind denn da genau die Regeln? Wie definiert so ein Beschluss welche der Daten extrahiert werden dürfen? Und ist ein Image der Festplatte ziehen ohne die Daten anzuschauen schon Extraktion?
Ich habe leider die Paper über das Sicherstellen von Digitalen Beweismitteln ohne Veränderung so öde gefunden, dass ich dort nicht tief drin bin. Das Klonen der Festplatte ist selbstverständlich eine genutze Methode, ob es dort weitere Hürden gibt kann ich mich nicht mehr genau erinnern, aber deine geklonte Platte ist ja evtl immer noch verschlüsselt, was je nach Sicherheitsmethoden des Geräts die Extraktion ohne Veränderung erschweren kann. Mit der Rechtslage in Deutschland kenne ich mich erst recht nicht aus.
Die Ermittlungsbehörden greifen nicht grundlos auf Software wie Cellebrite zu, wenn die Version zugelassen ist, müssen sie sich keine Gedanken mehr machen. Blöd halt nur wenn die Version hackbar war und die Zulassung für Beweismittelextraktion nachträglich entzogen wird. Wenn du auf arxiv.org nach "digital forensics" suchst, findest du einige case-studies und andere Abhandlungen.
Wie genau kam man denn auf die Idee, dass die beste Möglichkeit diese E-Mails aufzubewahren auf den Laptops ist?
Das rechtlich korrekte Sicherstellen von Daten für spätere Gerichtsverfahren ist der Knackpunkt der IT-Forensik. Wenn du die Daten von sichergestellten Laptops schon mal präventiv extrahierst ohne Beschluss ist das vor Gericht nicht gültig. Was der genaue Stand hier ist, weiß ich leider nicht.
Thx a lot for checking this, you gave me the missing part in the puzzle.
It was hard to find the actual patch increase, but the latest commit lists the current patch level:
+ - New microcodes:
+ + Family=0x17 Model=0x31 Stepping=0x00: Patch=0x0830107a Length=3200 bytes <--- Your processor, higher patch version
+ + Family=0x17 Model=0xa0 Stepping=0x00: Patch=0x08a00008 Length=3200 bytes
+ - Updated microcodes:
+ + Family=0x17 Model=0x08 Stepping=0x02: Patch=0x0800820d Length=3200 bytes
+ + Family=0x17 Model=0x01 Stepping=0x02: Patch=0x0800126e Length=3200 bytes
+ - CVE-2023-20593
I guess that pretty much confirms the theory, AMD only rolls microcode for Epyc and there is no magic sauce why the patch version are all over the place on their consumer chips. For me, the worst thing is their lack of transparency. Guess they're justification is ridiculous and incomprehensible from a customer standpoint, otherwise they would have communicated it.
Also funny that Ubuntu 22.04 doesn't ship microcode for Zen3 and higher, why don't they backport such things?
The family is printed in the kernel log: [ 0.380496] smpboot: CPU0: AMD Ryzen 9 5900X 12-Core Processor (family: 0x19, model: 0x21, stepping: 0x2)
Anyone having hardware access to an epic CPU ? Could you please report the numbers from zstdcat /lib/firmware/amd-ucode/README.zst
vs the patch level reported by grep microcode /proc/cpuinfo
, even if you run a different distro ?
I read that AMD microcode from the AGESA always has a higher patch version number than the microcode supplied by the kernel. The lastest microcode version from the linux-firmware repo the latest version for family 0x19
are:
``` Microcode patches in microcode_amd_fam19h.bin: Family=0x19 Model=0x01 Stepping=0x01: Patch=0x0a0011d1 Length=5568 bytes Family=0x19 Model=0x01 Stepping=0x00: Patch=0x0a001079 Length=5568 bytes Family=0x19 Model=0x01 Stepping=0x02: Patch=0x0a001234 Length=5568 bytes
```
My CPU (Ryzen 5900x) reports [ 0.579161] microcode: CPU0: patch_level=0x0a20120a
, though? My BIOS is from January, the amd-ucode was update in July.
Others have come to the same observation and speculate that the linux-firmware microcode is only for Epyc. AMD in their statement about inception only talks about updating microcode via AGESA.
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1402527-amd-inception-cpu-vulnerability-disclosed?p=1402567#post1402567 https://www.phoronix.com/forums/forum/hardware/processors-memory/1349645-amd-publishes-new-family-19h-cpu-microcode?p=1349760#post1349760 https://www.reddit.com/r/archlinux/comments/hdrron/amd\_microcode\_not\_loading/
Anyone having more information on this?
Lass uns darauf alle einmal den Tipporary Song singen.
Let's hope they'll use GNU Taler for this. I only heard it being considered in Switzerland.
Thx a lot for your detailed feedback. I already heard about bang notation once, but forgot about it. I think I do understand how laziness works, but I can't understand why it'd be bad if Vault gets loaded into memory the 1st time it's needed. Does GHC split the parsing into multiple operations because salt
is used a little earlier than secrets
?
Hello, I've written a tool helping me keeping my histfiles free of my secrets. I'd like to hear your thoughts and suggestions about it. I'm a Haskell noob, so please be kind. https://github.com/bionade24/histcleaner
If Linus would be a non-techie, he would have tried to install it with a graphical AppStore, it wouldn't have worked and he'd either given up or found the flatpak version of Steam, which would have worked. Not restricting power users is a good aspect. If I play around with Windows registry to force the removal of edge, Linus would blame me, not Windows. You have to differentiate between things normal users tried and things Linus attempted because he has some technical knowledge.
Some random user saying anything doesn't make anything true, you don't believe flat-earthers on the internet, either.
The bug was that you couldn't install steam without faking a the installation of a dep that went down the dependency chain ending in a conflict of essential packages. The functionality to still proceed is a feature. Linus could also just have copied rm -rf --no-preserve-root /
from the internet as solution and would have trusted it blindly. If you want to be nannied all the way, I'd suggest you switch to iOS for everything.
IIRC it was already fixed when Linus did this, just not distributed. It was caused by the bluntness Linus developed due to unmeaningful Windows warnings in the 1st place.
Mehr übersimplifizieren konntest du es auch nicht, oder ? Der Teufelskreis aus dem Meme existiert nicht, das sind beides nur Symptome der grundlegenden Probleme.
Is it a dick move? Absolutely.
When this is such a dick move, why has no one cared about SLES not publishing the sources to a openly accessible page?
Real people only use cat
.
Und da will mir noch einmal wer erzählen Demokratie wäre ne tolle Sache /s