Bu9818

The take away of that story is: don't post a message from Tor that gives out the network that you're entering Tor from.

They're talking about the attack surface to get accidental code execution from opening files that try to exploit vim. Integrating shell commands with vim/less is a valid feature.

namespaces (which have been a frequent source of vulnerabilities)...

Unprivileged user namespaces sure, but I don't think that applies to namespaces in general (which without unprivileged user namespaces can only be created by root, and LPE is the concern with unprivileged userns due to increased attack surface). systemd doesn't need unprivileged userns to run.

Yeah I was wrong about that, I confused it with socket-activation passing. The systemd-side socket is available from the process.

Services may be in a different mount namespace from systemd for sandboxing or other reasons (also means you have to worry about filesystem permissions I suppose). Passing an fd from the parent (systemd) is a nice direct channel between the processes

Use Invidious, use RSS, use yt-dlp, use Tor.

The vast majority of services and user programs don't need to escalate privileges by invoking SUID/SGID binaries. no_new_privs should be used on them so that the "setuid with libc/LD programs" security boundary is avoided.

It could be a FOSS portable binary that runs outside of a web browser.

They aren't preventing you from using a content filter nor are they making it difficult to scrape the site. The counter measures against this are the problem.

I agree, I don't even care about ads in specific. I primarily use the tor browser which doesn't block ads due to fingerprinting (it's ok for casual browsing, though some sites are actually obnoxious and slow down the browser). More generally, I care about web scraping and being able to control the presentation of content: for internet archival, using a featureful video/music player (mpv) or library like a local imageboard, utilities like user scripts to add features/programatically do stuff, content blocking (filter rules for specific posts/users), creating RSS feeds for notifications if the site doesn't offer one, simpler/faster frontends like invidious/nitter, etc.

For faster session establishment in OpenSSH consider ControlMaster in ssh_config(5), which multiplexes multiple sessions in one connection instead of creating a new connection for each session.

Lots of games won't ever be converted to Wayland (maybe some unofficially by replacing libraries with updated ones that still work with the game), we'll need some nested X server like xwayland in rootful mode once wayland compositors remove their xwm.

Also, malicious code can be pushed to the website if you are logging in through that. You have to trust that their infrastructure is safe.

You can mark individual files as No_COW in btrfs, and No_COW + preallocation is a requirement for swapfiles anyway due to how the swap subsystem works.

affected 100% of the connections to XMPP STARTTLS port 5222 (not 5223)

Why did they only target the STARTTLS port? On a related note, I would never use the STARTTLS port (opportunistic encryption) if I knew that the server had a regular TLS port...

Instead of replacing the md5sum on the download page an attacker could replace the infohash/magnet link/.torrent file.

There's at least some differences, such as HTTP/2 usage, or maybe algorithm usage/bugs in newer versions. Whether or not most tracker staff actually bother to attempt fingerprinting, IDK.

The article linked includes OOB verification as a scenario in TOFU. From the perspective of the ssh client it's TOFU (no CA chain for the client to perform a check), sure, that just means it's up to the user to do the work and use ssh safely (either the server has a site posting the fingerprints like GitHub/the AUR or you're setting up the machine and have physical access, or maybe you're using SSHFP).

If no identifier exists yet for the endpoint, the client software will either prompt the user to confirm they have verified the purported identifier is authentic, or if manual verification is not assumed to be possible in the protocol, the client will simply trust the identifier which was given and record the trust relationship into its trust database.

systemd.directives(7) is useful if you know what directive you want to read about but not in what manual it's in.

I recommend programs using Tor to be run in an empty network namespace then set http/HTTPS/ALL_PROXY to a Unix domain socket created in torrc (or use socat to get it on the namespaces' 127.0.0.1 if not supported by the library), to avoid accidentally misconfiguring programs if their proxy settings are bad or you run a statically linked binary with torsocks.

If I'm allowed to use a software implementation (like with TOTP) so that my private keys can be stored in for e.g. a KeePassXC database so that I can back it up by having multiple copies, then I'm okay with it. Is it possible for sites to deny certain webauthn providers (ignoring scenarios like attestation forcing you to use a locked down system where you can't run keepassxc)?

Hopefully Tor Browser can turn on security.webauth.webauthn in a safe way before sites force it to be used, too.

The captcha on this page takes a few seconds then says "Failure", with no message, then restarts itself, when using Tor Browser on the Safer mode.

edit: Was able to get a mix of a few successes and a few failures upon multiple browser restarts. Maybe I was lucky to avoid a discriminated exit node? I'm not sure if IP address is a factor here.

They have a couple more joke physical JP input methods: https://github.com/google/mozc-devices

What in particular needs to be upstreamed and to what projects?

Most of it is open source similarly to the Chrome/Chromium situation. But you're right that many Linux desktop users won't care about it due to it being locked down and limited, which was demonstrated in the article. It's not something I'd use on my personal devices.

I too use rsync over SSH for devices I own, but I would avoid using SSH to transfer files with someone else. As the receiving side you either allow them way more access to your system than necessary or do some extra configuration to limit their access.

It's just a bit more involved to use for this use case, especially if the data is confidential (having to set the private flag so clients don't publish the infohash to DHT, using a built-in tracker in your client, transport layer encryption not provided by default). Things like Resilio are fine, they build on top of the protocol and provide a different UX.

Torrents also don't provide encryption between peers, unless you use SSL torrents, but it's clearly designed towards sharing between a group, not one-on-one transfers.

I've seen sites like discogs do this for tor exits. You quickly realize what they're doing. Same with shadowbans, I verify by accessing the post in a clean session.

Honest question: why does this matter? If you end up with running malware as your user haven't you already "lost" in any of a wide variety of ways that Wayland does nothing against?

The security benefits of wayland are useful when you're also using other things like namespaces/seccomp (with bubblewrap/flatpak), and pipewire which I believe has a similar access control mechanism.

Or is it that Wayland is trying to bring the mobile security model to the desktop with partially untrusted apps?

I trust my programs, but they can have bugs when parsing untrusted content. (ffmpeg, browsers). Although I've never been hacked, I'd like my systems to have defenses against this (without going full mobile security mode and giving up functionality and user freedom, or running everything in inconvenient isolated boxes with VMs).

Also, I'm not sure if I'd trust proprietary games, so preventing them from doing naive things (I don't expect them to exploit kernel vulns) like snooping on files by using namespaces is nice.