Hacker Newsnew | past | comments | ask | show | jobs | submit | champtar's commentslogin

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


probably due to low exposure


Curious what are the main benefits ? (I've only ever used DD-WRT and OpenWrt)


I use Tomato too, but I wouldn't say it offers many benefits over OpenWrt. The main thing is that routers based on Broadcom chipsets often only work with very old Linux kernels (such as 2.6.xx kernels), as the drivers are closed source. For these routers, the primary third-party router OS choice is to use Tomato.


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


CGNAT is used by Tailscale and presumably in the wild for its intended purpose.


And `100.115.92.0/23` is used by ChromeOS for PatchPanel: https://chromium.googlesource.com/chromiumos/platform2/+/mai...


You can easily keep the current naming behavior with the 'net.naming_scheme=' kargs


I already have systems that use net.ifnames=0. My question is about whether this new behavior can affect them.


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.


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)


>Hopefully the last breaking change.

Every year's cope with systemd.


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.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: