Did you reboot?

It could be that a system service was installed, and activated. This service could stay running even after the packages are removed, since the programs would remain in memory.

Thank you so much. This was so annoying. Although another comment mentions that this appears to be specific to samsung devices, and doesn't work on general android/aosp.

For those the ADB solution another comment mentions probably must be used.

It's not about trusting the source code or binaries to not have malicious additions.

It's about protecting myself and other users from anti features, by modifying or forking the software of the need ever arises. If software ever adds tracking or telemetry, the community can either modify it downstream (i.e. the way many linux distros compiled out audacity's telemetry), or they can directly fork it.

There is no need to worry about vendor lock in to a proprietary ecosystem, because the option to exit is always there.

randomise your web interface port

Randomized interface ports change nothing except for stopping automated scanners. They don't really help. Just lock it behind ssh, physical access or similar, and then never worry about it again.

Yeah only if you enable their cloud api

No, all of the local web interfaces have had problems too. Literally every router or network appliance has had similar issues.

ts not an isp or consumer router

ISP, consumer, and enterprise routers have all the same issues due to the same architecture. All of them.

have also pen tested my router remotley.

Me too. But it's just not about my router being secure today, it's about it being secure tomorrow. I want to be able to rest easy knowing that if a new vulnerability appears in xyz component then I don't have to worry about it.

Every issue with tp link has been. You need to have acces to the router physically to implement.

Come on, this is not true and you know it. Finding a counterexample was easy:

https://www.anavem.com/en/news/cybersecurity/tp-link-patches-critical-router-flaws-enabling-rce

Auth bypass + auth rce flaw. Literal remote code execution, instant own.

The problem with network appliances/routers is that they all have web ui's, and management api's or something of the sort. Web UI's are extremely complex services, with lots of difficult to secure attack surface. In a router, that attack surface is now running as root (because it has to be, to manage linux (or freebsd, routers are usually based on one of the two) kernel routing and networking.

So literally every single network appliance and router has had it's own critical vulnerabilities, even open source ones like openwrt.

The real solution here is to recognize that web interfaces are a security nightmare, and to either disable them or lock them behind ssh.

(Open)ssh, is known for having extremely few vulnerabilities, only 2.5 critical ones over it's 25+ years of existence. That's a big difference compared to some of these network appliances/routers which have 2+ critical vulns every quarter.

I'm so tired of news articles that hype up fairly mundane stuff, acting like it's the next big bomshell.

In addition to that, by misrepresenting what is happening, it's literally actively harmful to consume this kind of news, which is so common on the cybersecurity news cycle.

Yet another cyberslop article.

Not really. Immutability can be overriden by root, who can then edit files.

And in addition to that, /etc/, system config files, including pam files mentioned here, are not immuable even in immutable distros.

SIX. SEVEN.

Frantically does hand gesture

Yes this is the best way.

On Linux I've never had to install drivers for any printers, it comes with a "generic" driver that works for a ton of brands,

The original person you replied was commenting that nix was less vulnerable to supply chain attacks. Your reply is essentially completely off topic, talking about CVE's. They are not the same type of issue. Having an actively running piece of malware on your system is vastly more concerning than a vulnerability someone has yet to exploit, and the supply chain security techniques needed to protect against the former are different as well.

Immutability is an extremely poor defense against any form of attack. Immutability is literally a filesystem feature where a flag, chatttr -i is set on files or folders. Any program with root can adjust this flag, and any program running as a user could download additional binaries to or modify the users home directory. This is how the nix daemon works.

Now, if nixos followed (or you configured it to follow) a model where only binaries in the nix store could be executed, and nothing else could be executed (in addition to maybe say, using selinux to enforce that only the nix daemon is editing the nix store), that would be much more secure and very interesting. But it's not doing that.

Edit: correction, the nix store is not actually immutable on the filesystem level. It merely holds immutable "outputs", the packages and functions it generates. You're not supposed to edit them... but nothing stops you (if you're root or the nix daemon user). You can verify the nix store pretty easily, but it's not an ongoing process, that is to say it wouldn't catch malicious changes.

What I said above about a theoretical applocker enabled like system based on Nix still applies, however.

This is not the same. The AUR was a supply chain attack, where good packages where replaced with malicious one's.

Nix is better at stopping things like that from happening, becuase they have a monorepo, where most package updates or changes are reviewed by another person. The AUR is just a collection of individual git repos (or branches), where each maintainer can make updates or changes with no oversight.

Huh. I just checked and guix uncendors go. Very impressive.

It looks like they let you override cargo crate deps with different versipns but they haven't managed to compile without cargo or crates yet.