There is also OVH (not affiliated, just happily using their VPS), but I would consider switching to 2 providers, as any provider can have data loss or just lock your account at anytime for any reasons. 2 providers with free egress so you can easily replicate data between them.
HN user
champtar
TIL `badblocks -t random` repeats the same random block over and over :(
Just being able to inject traffic is already huge as it allow you to send IPv6 router advertisement, which sometimes allows you to change the DNS config
You need working switch level filtering, many implementations can be bypassed / will never be fixed: https://blog.champtar.fr/VLAN0_LLC_SNAP/
CAP_NET_RAW also allow to capture packets (tcpdump) so you really can have some fun like running a TCP stack in user space or MITM http connections: https://blog.champtar.fr/IPv6_RA_MITM/ / https://blog.champtar.fr/Metadata_MITM_root_EKS_GKE/
Good news that it was found and fixed, but 140 days response time seems rather slow for such a critical vulnerability
Curious what are the main benefits ? (I've only ever used DD-WRT and OpenWrt)
In OpenWrt there is ujail, you give it an ELF (or multiple) to run, it'll parse them to find all the libraries they need, then it creates a tmpfs and mount bind read only the required files. https://github.com/openwrt/procd/blob/dafdf98b03bfa6014cd94f...
2 big address block that have few chances of conflict:
- CGNAT 100.64.0.0/10
- "Benchmark" 198.18.0.0/15
It'll not, the new behavior is just a new naming scheme, and you just choose not to use any, which is totally fine if you have a single NIC.
You can easily keep the current naming behavior with the 'net.naming_scheme=' kargs
Hopefully the last breaking change.
enoX should always stay stable, as it's the BIOS (in some ACPI table) telling that this device/port has this ID.
ensX means the NIC in PCIe slot X, but in your PCIe tree you can have PCIe bridges, so technically you could have multiple NIC in the same slot (what the BIOS declare as a slot), so there was a lot of breaking NIC naming changes over the years in systemd to figure out the right heuristics that are safe, enabling/disabling slot naming if there is a PCIe bridge, but just in some cases.
Also for historical reasons the PCIe slot number was read indirectly leading to some conflicts in some cases (this was fixed in systemd 257)
I once had to maintain a CalDAV server that was developed in house, computing the "free busy" with recurring events, exceptions, different timezone than the organizer + some DST is a bug source that keeps on giving.
https://github.com/rustic-rs/rustic?tab=readme-ov-file#stabi...
rustic currently is in beta state and misses regression tests. It is not recommended to use it for production backups, yet.
If you want to use some object storage instead of local disk, rclone can be a restic server: https://rclone.org/commands/rclone_serve_restic/
I remember when contactless was introduced in France, someone from the CB bank card group (https://en.m.wikipedia.org/wiki/CB_Bank_Card_Group) said that contactless was secure because you are insured. At that time France was already using chip+pin for a while.
At the end of the day the money only goes from one bank account to another, account can be frozen, charge reversed, ... So you just need to secure the POS enough that user feel safe to use it and there is a low number of people that can hack them and are willing to risk prison.
If you are using Microsoft Outlook mobile app or the webmail, inline or bottom posting experience is garbage, it doesn't quote/format the previous email, it just slaps it at the bottom. If you want to respond inline you better put some color else it's unreadable.
For timezones data go already has https://pkg.go.dev/time/tzdata
AWS EBS volumes (except io2) have an annual failure rate of 0.2%, so if you have 1000 running statistically you will loose 2. For io2 it's 0.001%, but still not 0.
With reproducible build you know that what you test on your dev laptop is the same as what will go out from your CI, and if hash mismatch you can chase why. For a concrete exemple, Mellanox driver configure script will auto detect if it's running under docker and change a compile flags, so if you build in a container using podman you get a different result.
All EBS volumes except io2 have advertised durability of 99.8%, which is pretty low, so don't count it in the magic networked storage category.
You can securely store your asymmetric key for signing, but if I remember correctly the logs are pretty useless, basically you just know the key was used to make a signature, no option to log the signature or additional metadata, which would help auditing after an account/app compromise.
Well TOTP need proper time sync, and most routers don't have battery in them
u2f and webauthn require https (https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...), don't know if it accepts self signed certs and IPs instead of fqdn. Also the auth is locked to the host, so if you use IPs, changing IP means you need to remove 2fa first and re-enroll after. IMO just using a 60+ chars password stored in your password manager + moving the admin access in a separate vlan is simpler and enough.
Both exemples generate custom nginx config
I would love if the container pull protocol stopped using custom headers or content-type, so we could use any dumb http server.
What I would really love is for the OCI Distribution spec to support just static files, so we can use dumb http servers directly, or even file:// (for pull). All the metadata could be/is already in the manifests, having Content-Type: octet-stream could work just fine.
Sewer are properly buried, Rogers cables are just thrown around with maybe a bit of dirt on top of it was a good day. I redid a wall in my backyard last year that is close to a Rogers box, I removed ~15 old cut cables from the ground.
I invite you to not trust blindly L2 security features, anything that use denylist approach can miss some corner cases, have a good read :) https://blog.champtar.fr/VLAN0_LLC_SNAP/
You should play with IPv6, you can bypass IPv6 RA Guard on some switches (including Cisco) https://blog.champtar.fr/VLAN0_LLC_SNAP/, allowing attacks in 'trusted' networks