There’s this newfangled thing people complain about…

Instead of having to do service.domain.tld it’s nice to do service.lan.

I wrote scripts to automate my own custom ZFS multi-site backup solution. Way harder than spinning up a purose-built NAS OS, but not only do I have full control over it, I learned so much more about the underlying filesystem than I ever would have.

I use a dual NIC mini PC running OpnSense. Ot would support USB sims. I actually have two of the routers connected woth a network cable. If one goes down, the other takes over.

No, because it’s open source. Keep on chuggin

Sim Collector Simulator

Fry’s. Some Microcenters. Al Lashers.

The drawers are the best everywhere. RadioShack? Component drawers. Home Depot? Fastener drawers. On and on.

I’m not sure I follow the question. All of the TLD *.arpa is not reserved for private use, only *.home.arpa. So all your internal services are required to be a sub domain.

I wonder if it’s so you can get a calendar of usage tines. Could be handy to ensure kids are brushing for the right amount of time?

The biggest one: Snaps.

I switched from Ubuntu to Debian, and it’s basically the same thing, just faster since it uses native packages instead of Snaps. Ubuntu might as well run all it’s apps in Docker containers.

You could rebrand Debian to Ubuntu and most users wouldn’t even notice.

But… your original comment is just… wrong?

This isn’t a critical security flaw unless you have the worst partition scheme on your encrypted volumes imaginable.

The default LUKS partition scheme is vulnerable.

It’s not even a process flaw at that point, just “possible”.

There is a successful POC, it is a flaw.

you can compromise disks once encrypted because everything is happening in an in-memory boot process.

This is not just in-memory. This is modifying the unencrypted part of initramfs on disk. Powering off the machine does not remove the exploit.

You always “boot something that is unencrypted.” You then “mount” the encrypted volumes and load the OS.

This is how people can put an SSH server (dropbear) in initramfs so they can unlock remotely.

The attack is to initramfs, not the encrypted layer.

The order’ish:

• Boot
• Initramfs loads, gives you the LUKS prompt
• Initramfs decrypts/mounts OS
• OS loads

I’m confused.

Initramfs is unencrypted in /boot when using LUKS with RAID. It has to be, right?

The attacker uses a debug shell to modify the unencrypted boot, so the next time you boot and type your LUKS password, they can gain access.

This doesn’t line up with your comment?

No thanks. I get some people agreed to this, but I’m going to continue to use .lan, like so many others. If they ever register .lan for public use, there will be a lot of people pissed off.

IMO, the only reason not to assign a top-level domain in the RFC is so that some company can make money on it. The authors were from Cisco and Nominum, a DNS company purchased by Akamai, but that doesnt appear to be the reason why. .home and .homenet were proposed, but this is from the mailing list:

1. we cannot be sure that using .home is consistent with the existing (ab)use
2. ICANN is in receipt of about a dozen applications for “.home”, and some of those applicants no doubt have deeper pockets than the IETF does should they decide to litigate

https://mailarchive.ietf.org/arch/msg/homenet/PWl6CANKKAeeMs1kgBP5YPtiCWg/

So, corporate fear.

I just use openssl"s built in management. I have scripts that set it up and generate a .lan domain, and instructions for adding it to clients. I could make a repo and writeup if you would like?

As the other commenter pointed out, .lan is not officially sanctioned for local use, but it is not used publicly and is a common choice. However you could use whatever you want.

I use a domain, but for homelab I eventually switched to my own internal CA.

Instead of having to do service.domain.tld it’s nice to do service.lan.

I just validated that the latest version of the LDAP privilege escalation issue is not an issue anymore. The curl script is in the ticket.

This was the one where a standard user could get plugin credentials, such as the LDAP bind user, and change the LDAP endpoint. I.E., bad.

I chose this one because after going through all of them, it was the only one that allowed access to something that wasn’t just data in Jellyfin.

So for me, security is less of an issue knowing that, as only family use the service, and the remaining issues all require a logged in user (hit admin endpoint with user token).

Plus, I tried a few of those and they were also fixed, just not documented yet. I didn’t add to those tickets because I was not as formal with my testing.

@EncryptKeeper@lemmy.world

Use an LDAP to OIDC bridge?

This 100% needs to be reported. First to KIA, then to the media after whatever time is required to pass for responsible disclosure in your country/region.