I've lost faith that Linux distros will ever fix the problem where some PCR changes and the TPM refuses to unseal the key... the user is left with a recovery passphrase prompt & no way to verify whether they have been attacked by the 'evil maid', or whether it was just because of a kernel or kernel command line or initrd or initrd module change, etc.
> So I connected it to the computer with the USB to NVME M.2 converter
> blkdiscard: /dev/nvme0n1: BLKSECDISCARD ioctl failed: Operation not supported
I've got a USB-to-NVME adapter that exposes the NVME namespaces as SCSI disks. `blkdiscard` did not work with these by default, however it worked fine after I changed the `provisioning_mode` attribute of the disk.
This can be done by identifying the SCSI device ID of the disk (lsscsi) and then changing it with:
`lsblk -D` will show which block devices support the discard operation; run it before and after changing provisioning_mode to see the difference.
This is absolutely not to be used as an alternative to a real 'sanitize' operation directly sent to the NVME controller. If you actually need to securely erase your data, and the drive dosesn't support the sanitize operation, then you should physically shred the drive and demand a refund from the retailed (goods as sold are not fit for purpose).
Overall, I've found dealing with nvme a frustrating experience. In theory it's nice to have NVME controller firmware be responsible for executing commands from the host (sanitize! change LBA size! underprovision by 30%!) but in practice, it's complete hit or miss whether controllers support a command or will reject it, or maybe they claim to support it but it doesn't work because the controller firmware is buggy shit.
I would like to have raw NAND devices and have the kernel be in charge of everything, but sadly that wouldn't work for Windows so we're stuck in proprietary firmware hell.
I was going to add “cURL: “ at the start of the title, but it didn’t fit. The current title is exactly the allowed length, so it seemed more appropriate to keep the message verbatim.
https://www.electricitybills.uk/ shows a breakdown of the components of consumer energy bills. It's not as simple as saying "it's expensive because of gas", though pricing based on the marginal production cost is one component.
German situation is mostly/rarely/never. Small businesses have their DSL line where their cheapo router will announce an IPv6 prefix which almost all ISPs over here provide. Medium to large businesses usually have some braindead security policies that include switching off all IPv6 functionality in devices.
On our end, it's all electronic - we never print anything out. So yeah, on our side, "email with extra steps". But I have no idea how the mortgage companies handle it on their end.
Ink on paper, where I work. There have been court decisions that have seen Fax as "remote copying". And said that those remote copies only had any legal value if there was an actual paper original. Thus the workflow always has to involve paper that is then archived as paper in a folder...
I once had to print a form and fax to a company with a signature and the instructions said specifically that "signing with a computer and sending digitally is not allowed".
I just signed with macOS Preview, applied some random noise filter and used a one-off online fax service. ¯\_(ツ)_/¯
> Medium to large businesses usually have some braindead security policies
what's the argument behind that? are they scared they might configure their firewall bad and have no NAT to safe them from accidentally making all devices public?
It comes from the same place as "passwords expire every 30 days".
People don't understand something and just apply the most annoying rule possible.
The craziest one I saw in Germany was "cookies are allowed, localStorage is not", that was for our app. CTO overrode the CISO on the spot and called him an idiot for making rules he doesn't understand. Interesting day.
Usually there is no official justification given, just a list (in excel...) of security requirements that have to be ticked off. One of them is "Disable IPv6".
I've heard some ex-post justifications, make of them what you will: Existing infrastructure like firewalls, VPNs and routers might not be able to handle IPv6 properly. Address distribution in IPv6 is unpredictable. No inhouse knowledge of IPv6. Everything has an address in IPv6, so the whole internet can access it. No NAT in IPv6, so it is insecure. IPv6 makes things slow.
tc is Traffic Control for Linux, you can do things like set priorities, drop traffic for testing, etc. This looks like now you could match by systemd service, container, or some other thing with its own group, which sounds useful.