• 7 Posts
  • 347 Comments
Joined 2 years ago
cake
Cake day: March 19th, 2024

help-circle




  • The forking option wouldn’t work as well as it does on github because AUR packages are not namespaced like GitHub repos, e.g. communism/mypackage; instead it’s just mypackage. So if adoption required a new name you’d have mypackage-cont, mypackage-cont-cont, or whatever. And it wouldn’t really be possible to introduce username namespacing because AUR packages are just Pacman packages that are community-contributed rather than official, and Pacman, like most package managers, doesn’t namespace their package names; firefox is just firefox rather than, say, mozilla/firefox. Some AUR packages get added to the official repos so when you do, e.g. yay -Syu, you’ll then install the official package if you previously had the AUR package installed as it has the same name.

    There isn’t a perfect solution. Even if package adoptions were moderated, someone could take over a package and initially push a genuine commit, and then their next commit is malicious. Reviewing every single AUR commit would be incredibly labour-intensive. Possibly you could add automated checks for commits that suddenly add an npm install or other suspicious command with regex, but attackers could just get cleverer about avoiding those regex checks. Imo the best solution is just more widespread warnings about the fact that AUR packages are community-contributed with no guarantees of safety (e.g. on the Arch wiki where it sometimes suggests users install AUR packages), and AUR helpers forcing users to read PKGBUILDs before installation.



  • I agree about the risks in terms of the way some sources present the AUR as just extra packages. But I don’t think you can object to the AUR more than any other place on the internet where anyone can upload software; unfortunately, the onus is going to be on the user to verify what they install. The AUR is moderated by volunteers and it wouldn’t be fair to expect them to vet all of the high volume of commits to the AUR. Possibly they could vet new maintainers or new packages or newly adopted packages, but nothing would stop someone from initially uploading a genuine package and then replacing it with something malicious. Or they could require identity verification to be an AUR maintainer but then far fewer genuine packages would be on there because people don’t want to give their real identity to contribute (I maintain some AUR packages, and would stop if required to verify my IRL identity).

    I can totally understand if the AUR is not for you; it’s more time-consuming as you have to read PKGBUILDs (I always do). But that doesn’t make it bad that it exists at all. I think there should be more warnings about it for new users, and possibly some more moderation, though like I said above there’s no perfect moderation solution that would simultaneously forgo users’ responsibility to check and keep the AUR as large as it is today. Ultimately the option should still exist for users who want it. If it didn’t exist, I’d have to hand-package every program that’s not in the official repos, and that’s even more time-consuming than pulling and reading through a PKGBUILD that someone else already wrote and shared.


  • It’s just a repository of user-contributed packages. It’s no different malware-ability-wise to, say, GitHub. If you are running code you found from a stranger on the internet then you are liable for it, and you need to do your due diligence in checking that you are not running malware. It is a good thing that the AUR exists because it means Arch user packages are all in one centralised repository instead of scattered across GitHub, Sourceforge, Codeberg, Pastebin, forums, whatever. If you are just installing random AUR packages then that’s on you. It’s basic internet safety to not automatically trust random scripts you find on the internet.





  • I mean the ELI5 for the uninitiated is that X11 is older, and Wayland was made as the successor to X11. It aims to address issues that a lot of people had with X11. X11 is not in active development whereas Wayland is, and for support for modern tech, it’ll be added to Wayland but not X11. These days I’d advise to go with Wayland unless you either have hardware that doesn’t place nicely with it or you have a specific use-case for X11, i.e. Wayland unless you have a reason not to. Although most “beginner” distros choose for you without prompting you to pick, in which case go with the default (it’s probably Wayland anyway).

    If you mean to explain the debate, basically some people have particular things they want to do, or they want to do something a certain way, and it’s not supported by Wayland, usually by design due to things like security concerns or philosophical differences with X11. X11 will continue to work for a long time but it’s not getting new features, so if these issues are a concern with you, you could stick to X11 for the foreseeable future.

    The average user is not supposed to notice a difference (apart from maybe QoL differences like performance, screen tearing, etc)—that’s the goal of both projects. It should just display your desktop.



  • I’ve never daily driven it as my main machine but I’ve used it as an auxiliary driver for a more high-security machine. Afaik things like gaming are sort of a no-go on Qubes still.

    Qubes does not just do sandboxing. It runs all user programs in VMs, which adds non-negligible overhead and makes it an unsuitable OS for many more lightweight systems like laptops. And even if your PC can run Qubes without issue, you may not want that additional overhead if you want to do anything computationally intensive.


  • Maybe block on your router and save your router password such that you need to jump through several hoops to unlock it, eg password saved in one password manager DB whose master password is in another DB whose password is in another DB, etc. If you have to unlock like 10 password databases to get into your router, you’ll probably give up on whatever bad habit you were trying to do as it’s too much effort.



  • Never used Snapchat but there’s a lot of porn bots on social media. Not really sure where they come from but I guess it must be profitable and some gullible and horny people are falling for them because the bots haven’t gone away. It is very unlikely that a real woman would just be messaging random accounts with unsolicited nudes.

    Unfortunately your nieces are probably getting similar bot spam. I don’t think it’s demographically targeted at all; they just seem to message everyone. I’ve gotten them as a woman on social media too (albeit a gay one, but I don’t think these bots are targeted at gay women lol, I think they’re targeting men). It might be worth trying to introduce your nieces to some fun hobbies so they don’t feel the need to spend so much time on Snapchat, but I get that it’s a social thing too and it’s hard to opt out if all the other kids are on it.



  • I self-host on a VPS, so my off-site copy is the VPS, and my on-site copy is the emails downloaded to my email clients.

    I figure that Proton or Tuta are probably still safer than Google.

    Define “safer”. If you are receiving unencrypted emails (which is the case in the vast majority of cases), there is nothing stopping Proton or Tuta from reading them. Fundamentally, if something arrives at a server unencrypted, the server can read it—nothing can be done about that.

    If you’re exchanging e2ee emails, then it doesn’t matter if you use Google, because the body of the email can’t be read by Google. A lot of metadata is required to be unencrypted though (this is the case for Proton and Tuta too).

    I don’t really see the benefit to using an email service like Proton or Tuta from a perspective of meaningful data privacy. If it were between e.g. Proton and Google I’d probably pick Proton to avoid my emails being used to serve me ads from Google, but I wouldn’t have any illusions about Proton being able to read unencrypted incoming mail.


  • Tbh for email I’d say don’t bother with privacy as it wasn’t meant to be private, as Dessalines said. If you care about data sovereignty (which is different to privacy, though often hand-in-hand), you can self-host email—it’s not as hard as it’s reputed to be. I’ve self-hosted my main email address for a couple years now and not had major hiccups. For the most part, after initial setup, it just runs. And if you’re daunted by configuring it, there are out-of-the-box solutions like Mailcow you can use. I’d only really recommend it if you already have a VPS/home lab/etc where you already self-host things.