1. 3

    This seems a bit far-fetched, and would be applicable to almost any third party repo. A real life example of this short attack would have been more interesting.

    1. 2

      I think the main point here is that Skype adds a /etc/apt/sources.list.d/skype-stable.list file without explicitly saying this (although I might be wrong and I might have clicked a “get updates” button).

      On the other hand, anyone can browse the repo and see what packages are available at any time so the conclusion that Microsoft “can easily inject malicious packages via regular update and replace distro packages w/ their own manipulated ones” does seem a bit far-fetched.

      1. 4

        On the other hand, anyone can browse the repo and see what packages are available at any time so the conclusion that Microsoft “can easily inject malicious packages via regular update and replace distro packages w/ their own manipulated ones” does seem a bit far-fetched.

        It’s not far-fetched, it’s a fact they can do it. And they could easily avoid getting caught by adding additional date/time, IP address and user-agent header filters to ensure only the target will get the updates via apt-get, for example via automated updates. Anyone else browsing the repo, or the target browsing the repo at another time or using a web browser would not see the replacement packages. To be sure, this requires malicious intent, which one might argue is “far fetched”, but the NSA has been known to pull such shenanigans as a matter of course.

        Updates would show up in the apt logs, of course, but once installed, a malicious application could scrub local logs easily, as the post-install scripts run as root. This would be pretty hard to detect, let alone prove.

        1. 3

          Any package can add to /etc/apt/sources.list.d, though.

          It would be nice if they said they were doing it, but it is possible to check before installing with “apt-file list ”.

      1. 6

        I cycle 3 times a week, it really helps me lose my thoughts. Apart from that reading / electronics, soldering is a lot of fun :)

        1. 1

          I’ll be there with some other Arch folks :)

          1. 2

            Last night, been busy setting up wireguard with my own dns server for my phone, and a wireguard server at home so I can log into my RPI. Planning on setting up some SDR stuff on my RPI at home, should be able to log planes, 433 MHz and boats! (AIS).

            Need to prepare/write my talk about the Arch infra for FrOSCon, hack on the archlinux.org website (testing for the Python2 to Python3 migration \o/).

            1. 3

              If the sea keeps rising I might need a boat to go to work instead of a bicycle. Realistically though we don’t change much at work except the airco is on more often due to the buildings bad dissipation of heat. I would love to have solar panels on it, but we rent the building.

              1. 1

                I respect Arch Linux’s wiki and its commitment to simplicity, but I’ve always wished they would support more architectures. There is more in the world than x86_64.

                1. 2

                  Which architectures in particular?

                  1. 1

                    ARM is the biggest one. I know there is a separate project that supports ARM, but it’s just that - a separate project. I’m also interested in MIPS and POWER.

                    Here are some examples of interesting hardware that I can’t use with the base Arch Linux project:

                    Eliminating lesser-used architectures goes along with simplicity, so I guess the decision makes sense. When I started using Arch, the focus on i686 and newer (eliminating i386 compatibility) was part of the appeal. These days I default to Debian for the architecture support.

                    1. 2

                      ALARM is good, why dismiss it as “just a separate project”? What’s wrong with that?

                      1. 1

                        ALARM certainly looks a lot more complete than when I first encountered it a couple years ago. The device support page in particular looks nice. The ARM-specific wiki pages are somewhat meager.

                        The FAQ on the official wiki explicitly states “You may not want to use Arch if you require support for an architecture other than x86_64,” and I take that at face value. All the official wiki pages assume x64, although I’m sure much of the information is transferable.

                        1. 1

                          My issue with ARM is, it’s a totally different ecosystem and you need the specific hardware to reasonably support it. I would love to support ARM, but that would be only mainline and not all the closed source gpu’s and BSP kernels. Users probably would not like this.

                          Just supporting the RaspberryPi would be neat, but I believe aarch64 is still not 100% supported and requires a custom kernel :-(. And adding another kernel to our repo’s requires even more work when security issues pop up, which is already an issue currently.

                1. 1

                  Anyone have an idea what the prices are for the event though?

                  1. 1

                    Ticket prices haven’t been determined yet, but should be in line with previous years.

                    Usually there are varying levels from hobbyist to professional, the details will be announced when registration opens.

                    I look forward to welcoming you to Christchurch!

                  1. 2

                    the only complaint I have with arch is that pip install and npm install fuck the system up. the solution is you have to use them inside virtualenv, nvm.

                    1. 7

                      Which is not a distro problem, but a problem with the defaults of these third party language package managers. Everyone assumes sudo pip install requests is a great idea while have these issues when installing the requests lib from the repository.

                      I’ve configured my npm to install in ~ for globals things, so it doesn’t mess up my system :)

                      1. 4

                        The problem isn’t really an arch issue, it’s related to the defaults of pip and npm. I’ve never had an issue with either negatively affecting my system if I set it up as the arch wiki recommends.

                        For pip, use --user if you aren’t in a venv, for npm, set $npm_config_prefix to be located in ~.

                        1. 4

                          You install pip or npm with the package manager

                          then you use them according to the man pages and it borks your system.

                          This is a fault

                          If special configuration should be done this should come when you install it with the distro package manager. That’s the whole point of a linux distribution. If you’re supposed to use the virtual env you should at least get a warning about that when you install the tool. UX matters.

                          1. 7

                            If you’re supposed to use the virtual env you should at least get a warning about that when you install the tool.

                            Actually almost every popular Python package suggests using virtualenvs (or more recently, pipenv). AFAIK, sudo pip install is considered bad practice in the Python community.

                        2. 7

                          Yeah, my solution to the npm problem is to stay far far away from npm.

                          1. 1

                            Not exactly a universally applicable solution.

                            1. 2

                              As a society, however, we’d all be better off if we could.

                        1. 12

                          As someone who uses arch on all my developer machines, arch is a horrible developer OS, and I only use it because I know it better than other distros.

                          It was good 5-10 years ago (or I was just less sensitive back then), but now pacman Syu is almost guaranteed to break or change something for the worse, so I never update, which means I can never install any new software because everything is dynamically linked against the newest library versions. And since the arch way is to be bleeding edge all the time, asking things like “is there an easy way to roll back an update because it broke a bunch of stuff and brought no improvements” gets you laughed out the door.

                          I’m actually finding myself using windows more now, because I can easily update individual pieces of software without risking anything else breaking.

                          @Nix people: does NixOS solve this? I believe it does but I haven’t had a good look at it yet.

                          1. 14

                            Yes, Nix solves the “rollback” problem, and it does it for your entire OS not just packages installed (config files and all).

                            With Nix you can also have different versions of tools installed at the same time without the standard python3.6 python2.7 binary name thing most place do: just drop into an new nix-shell and install the one you want and in that shell that’s what you have. There is so much more. I use FreeBSD now because I just like it more in total, but I really miss Nix.

                            EDIT: Note, FreeBSD solves the rollback problem as well, just differently. In FreeBSD if you’re using ZFS, just create a boot environment before the upgrade and if the upgrade fails, rollback to the pre-upgrade boot environment.

                            1. 9

                              Being a biased Arch Developer, I rarely have Arch break when updating. Sometimes I have to recompile our own C++ stack due to soname bumps but for the rest it’s stable for me.

                              For Arch there is indeed no rollback mechanism, although we do provide an archive repository with old versions of packages. Another option would be BTRFS/ZFS snapshots. I believe the general Arch opinion is instead of rolling back fixing the actual issue at hand is more important.

                              1. 8

                                I believe the general Arch opinion is instead of rolling back fixing the actual issue at hand is more important.

                                I can see some people might value that perspective. For me, I like the ability to plan when I will solve a problem. For example I upgraded to the latest CURRENT in FreeBSD the other day and it broke. But I was about to start my work day so I just rolled back and I’ll figure out when I have time to address it. As all things, depends on one’s personality what they prefer to do.

                                1. 2

                                  For me, I like the ability to plan when I will solve a problem.

                                  But on stable distros you don’t even have that choice. Ubuntu 16.04, (and 18.04 as well I believe) ships an ncurses version that only supports up to 3 mouse buttons for ABI stability or something. So now if I want to use the scroll wheel up, I have to rebuild everything myself and maintain some makeshift local software repository.

                                  And that’s not an isolated case, from a quick glance at my $dayjob workstation, I’ve had to build locally the following: cquery, gdb, ncurses, kakoune, ninja, git, clang and other various utilities. Just because the packaged versions are ancient and missing useful features.

                                  On the other hand, I’ve never had to do any of this on my arch box because the packaged software is much closer to upstream. And if an update break things, I can also roll back from that update until I have time to fix things.

                                  1. 2

                                    I don’t use Ubuntu and I try to avoid Linux, in general. I’m certainly not saying one should use Ubuntu.

                                    And if an update break things, I can also roll back from that update until I have time to fix things.

                                    Several people here said that Arch doesn’t really support rollback which is what I was responding to. If it supports rollback, great. That means you can choose when to solve a problem.

                                    1. 1

                                      I don’t use Ubuntu and I try to avoid Linux, in general. I’m certainly not saying one should use Ubuntu.

                                      Ok, but that’s a problem inherent to stable distros, and it gets worse the more stable they are.

                                      Several people here said that Arch doesn’t really support rollback

                                      It does, pacman keeps local copies of previous versions for each package installed. If things break, you can look at the log and just let pacman install the local package.

                                      1. 1

                                        It does, pacman keeps local copies of previous versions for each package installed. If things break, you can look at the log and just let pacman install the local package.

                                        Your description makes it sound like pacman doesn’t support roll backs, but you can get that behaviour if you have to and are clever enough. Those seem like very different things to me.

                                        Also, what you said about stable distros doesn’t seem to match my experience in FreeBSD. FreeBSD is ‘stable’ however ports packages tend to be fairly up to date (or at least I rarely run into it except for a few).

                                        1. 1

                                          I’m almost certain any kind of “rollback” functionality in pacman is going to be less powerful than what’s in Nix, but it is very simple to rollback packages. An example transcript:

                                          $ sudo pacman -Syu
                                          ... some time passes, after a reboot perhaps, and PostgreSQL doesn't start
                                          ... oops, I didn't notice that PostgreSQL got a major version bump, I don't want to deal with that right now.
                                          $ ls /var/cache/pacman/pkg | rg postgres
                                          ... ah, postgresql-x.(y-1) is sitting right there
                                          $ sudo pacman -U /var/cache/pacman/pkg/postgres-x.(y-1)-x86_64.pkg.tar.xz
                                          $ sudo systemctl start postgres
                                          ... it's alive!
                                          

                                          This is all super standard, and it’s something you learn pretty quickly, and it’s documented in the wiki: https://wiki.archlinux.org/index.php/Downgrading_packages

                                          My guess is that this is “just downgrading packages” where as “rollback” probably implies something more powerful. e.g., “rollback my system to exactly how it was before I ran the last pacman -Syu.” AFAIK, pacman does not support that, and it would be pretty tedious to actually do it if one wanted to, but it seems scriptable in limited circumstances. I’ve never wanted/needed to do that though.

                                          (Take my claims with a grain of salt. I am a mere pacman user, not an expert.)

                                          EDIT: Hah. That wiki page describes exactly how to do rollbacks based on date. Doesn’t seem too bad to me at all, but I didn’t know about it: https://wiki.archlinux.org/index.php/Arch_Linux_Archive#How_to_restore_all_packages_to_a_specific_date

                            2. 12

                              now pacman Syu is almost guaranteed to break or change something for the worse

                              I have the opposite experience. Arch user since 2006, and updates were a bit more tricky back then, they broke stuff from time to time. Now nothing ever breaks (I run Arch on three different desktop machines and two servers, plus a bunch of VMs).

                              I like the idea of NixOS and I have used Nix for specific software, but I have never made the jump because, well, Arch works. Also with Linux, package management has never been the worst problem, hardware support is, and the Arch guys have become pretty good at it.

                              1. 3

                                I have the opposite experience

                                I wonder if the difference in experience is some behaviour you’ve picked up that others haven’t. For example, I’ve found that friend’s children end up breaking things in ways that I would never do just because I know enough about computers to never even try it.

                                1. 2

                                  I think it’s a matter of performing Syu update often (every few days or even daily) instead of once per month. Rare updates indeed sometimes break things but when done often, it’s pretty much update and that’s it.

                                  I’m an Arch user since 6 years and there were maybe 3 times during those 6 years where something broke badly (I was unable to boot). Once it was my fault; second & third one is related to nvidia driver and Xorg incompatibility.

                                  1. 3

                                    Rare updates indeed sometimes break things but when done often, it’s pretty much update and that’s it.

                                    It’s sometimes also a matter of bad timing. Now every time before doing a pacman -Syu I check /r/archlinux and the forums to see if someone is complaining. If so then I tend to wait for a day or two before the devs push out updates to broken packages.

                                  2. 1

                                    That’s entirely possible.

                                2. 4

                                  I have quite a contrary experience, I have pacman run automated in the background every 60 minutes and all breakage I suffer is from human-induced configuration errors (such as misconfigured boot loader or fstab)

                                  1. 1

                                    Things like Nix even allow rolling back from almost all user configuration errors.

                                    1. 3

                                      Would be nice, yeah, though I never understood or got Nix really. It’s a bit complicated and daunting to get started and I found the documentation to be lacking.

                                  2. 3

                                    How often were you updating? Arch tends to work best when it’s updated often. I update daily and can’t remember the last time I had something break. If you’re using Windows, and coming back to Arch very occasionally and trying to do a huge update you may run into conflicts, but that’s just because Arch is meant to be kept rolling along.

                                    I find Arch to be a fantastic developer system. It lets me have access to all the tools I need, and allows me to keep up the latest technology. It also has the bonus of helping me understand what my system is doing, since I have configured everything.

                                    As for rollbacks, I use ZFS boot environments. I create one prior to every significant change such as a kernel upgrade, and that way if something did happen go wrong, and it wasn’t convenient to fix the problem right away, I know that I can always move back into the last environment and everything will be working.

                                    1. 2

                                      How do you configure ZFS boot environments with Arch? Or do you just mean snapshots?

                                      1. 3

                                        I wrote a boot environment manager zedenv. It functions similarly to beadm. You can install it from the AUR as zedenv or zedenv-git.

                                        It integrates with a bootloader if it has a “plugin” to create boot entries, and keep multiple kernels at the same time. Right now there’s a plugin for systemdboot, and one is in the works for grub, it just needs some testing.

                                        1. 2

                                          Looks really useful. Might contribute a plugin for rEFInd at some point :-)

                                          1. 1

                                            Awesome! If you do, let me know if you need any help getting started, or if you have any feedback.

                                            It can be used as is with any bootloader, it just means you’ll have to write the boot config by hand.

                                  1. 6

                                    For me as a programmer, what I need is just a stable Operating System which can always provide latest software toolchains to meet my requirements, and I don’t want to spend much time to tweak it.

                                    Why is this? As a programmer I find I rarely need bleeding edge. I’m sure not going to install bleeding edge to production. It can be fun for hacking around but I don’t see why as a programmer it’s needed.

                                    1. 7

                                      It can be useful to have the latest compiler set and tooling for your project. I often find new potential issues with a newer GCC.

                                      1. 4

                                        For what it’s worth, Arch does distinguish between ‘stable’ and ‘bleeding edge’ in its releases, although the rolling release does mean that stable is generally much newer than you might find in, say, Debian.

                                        I wouldn’t use it in production, though I have seen it done.

                                        1. 3

                                          I don’t want bleeding edge in general, but “your issue has been fixed in the latest version” get old quickly.

                                        1. 10

                                          The big annoyance was that back in the day, with posting boards and guestbooks being all the rage, (or just a badly made web page) people would open a blink tag and never close it and the browser would render everything after it on the page as blinking.

                                          1. 4

                                            In a similar vein: U+202E “RIGHT-TO-LEFT OVERRIDE”

                                            1. 3

                                              I remember doing that once in 1996. Good times.

                                              1. 2

                                                These days you can annoy everyone with gif images though ;-) Which sadly regularly happens on Github issues of major issues / bugs.

                                                1. 1

                                                  But at least it doesn’t have a spillover effect of turning every post that comes after it into an animated gif meme version of itself (as long as no one makes “memification” a feature of markdown, aynway).

                                                  1. 3

                                                    as long as no one makes “memification” a feature of markdown, aynway

                                                    Goes off to register memedown.com and apply to a startup accelerator.

                                              1. 2

                                                This is great news, it’s been at 0.9x FOREVER.

                                                Also nice to see a project that takes custodianship of all of Arman Ronacher’s superb work!

                                                1. 3

                                                  Indeed it’s good to see it still get’s love and attention :) I’ve just updated our Arch flask based security tracker to 1.0 and it was quite an easy upgrade! Plus the get_json method for the test_client is a great improvement.

                                                1. 2

                                                  Yay! Still want to un-Python2 my Arch machine, but sadly calibre won’t be ported to Python 3.

                                                  1. 1

                                                    I was curious so I searched; statement from a few months ago:

                                                    No, I will simply maintain python 2 myself, far less work and I already do it for the windows python.

                                                    I’m going to laugh if in ten years my machine still has a python 2 interpreter, stubbornly maintained by Kovid :-)

                                                  1. 3

                                                    At work, I’ll be diving more into React for our new frontend. In my free time I’ll try to start reading “write great code” and for Arch Linux work on reproducible builds, figuring out what needs to be done and writing down issues.

                                                    1. 1

                                                      Is that the Randall Hyde book? I read and liked Volume 2.

                                                    1. 3

                                                      Can’t say that I do, but I have experience with lowend, cheap ARM boards which turned out to be a pain in the ass since upstream support is non-existent. The Allwinner boards can due to community written drivers and u-boot support run Linux, but GPU and a mainline kernel is a still a no go. Although there is one company still working hard on creating an open source laptop (which you can actually buy) https://olimex.wordpress.com/tag/laptop/.

                                                      An interesting alternative would be a T Bao Tbook, which is an Intel based laptop and relatively cheap and since it’s Intel hardware you can use their mainline gpu driver.

                                                      1. 1

                                                        Excellent/Average, I work at a relatively small company (~ 30-35 employees) but with a lot of products which makes it a bit stressful. But I can still make ~ 40 hours / week and plan in what I will work on during the day so there is a lot of freedom. What annoys me more is that I sometimes can’t let go of my job during my free time.