It can work as a universal homebrew replacement (works on MacOS, Linux, WSL and can be easily ported to most BSD variants), comes with a huge collection of packages[2] and produces its own reproducible source builds. Like homebrew, it's a hybrid source and binary based package manager (if you haven't done anything to modify the build, it will likely be downloaded from a cache of pre-built binaries[3]). Unlike something like homebrew-cask, it will never download the pre-built .dmg file from the developer's website - with the obvious exception of proprietary software.
It can also work as a great AUR/ports replacement on Linux systems. Fedora doesn't provide FFmpeg or an up-to-date version of a package you need? No problem, just get it from Nix! All the advantages of a rolling release distro, without actually having to use one.
Due to its functional nature, it comes with a wealth of advantages over homebrew and other traditional package managers[4]. Once you get past the learning curve, creating your own packages or modifying existing ones is a breeze. It can create disposable development environments with dependencies of whatever project you're working on, without having to install them in your system or user profile! Check out the Nix manual[5] for more information.
It's so flexible that people have built a Linux distribution where your entire system configuration is a Nix derivation (package) - with atomic upgrades, rollbacks, reproducible configuration and much more! [6]
[2] https://nixos.org/nixos/packages.html
[4] https://nixos.org/nix/about.html
https://www.gnu.org/software/guix/download/
Essentially, all the benefits touted above apply here, but it is worth noting that Guix is a younger project. The author was originally a Nix dev, but found the DSL to be too awkward to use in practice, and opted to use Scheme through and through. Yes, Emacs bindings are available.
Also, Guix can now produce Dockerfiles, if that floats your boat:
https://www.gnu.org/software/guix/news/creating-bundles-with...
The main allure to Nix/Guix is to be used for the internals of an OS. For example, NixOS is the most stable and maintainable system I have ever used, even though the documentation is absolute shit.
I'm not a packager, but I can't read either.
I breezed through your explanation with great interest and became more curious than ever to try Nix out at some point - I've heard tidbits about it over the past few months and found it to be a fascinating project.
Then I read some of the other comments in this subthread, about Nix being Haskell and Guix being Scheme, and how the internals don't conform to the principle of least surprise within their development domains - and became sad.
On the one hand, there are going to be teething problems, that's fine.
On the other hand, if I'm learning a new package manager, I ONLY want to learn package management. My brain gets really confused if I don't stay highly domain-specific when learning new things. So if you present me with "you need to learn B to grasp and work with A" you'll just get a duck trying repeatedly to jump up over the curb and failing. Looks hilarious, maybe, but very impractical.
I don't know Haskell or Scheme yet, which puts a great dampener on me using Nix for a bit.
As another practical example, emacs and vi do greatly interest me (particularly emacs' flexibility), but I'm not interested in having to learn Lisp or memorize a Nethack labyrinth of single-character keyboard commands (and the scopes for what works with what and where).
I suspect I might pick up emacs at some point after I've played with Lisp/Scheme/et al for a while, but that's not right now.
TL;DR: It's a strain for me to learn new things (basically do anything that requires focus and can't be done with passive autonomy) if my mental stack already has anything in it. AKA, I have a monumentally stupid variant of ADHD that gives me learning difficulties.
That being said, NixOS is the best damn OS I have ever used. Period.
Installing NixOS is a total breeze. It's magical.
1. Boot live CD
2. Mount partitions
3. Write a simple configuration.nix
4. nixos-install
5. Boot a complete system, and log in with the user you defined in your configuration.nix (with a hashed password and everything).
nix-env lets you install packages in your home directory (without root).
nix-shell lets you create a special environment with specific packages, etc. and run a shell in that environment.
nixos-rebuild [switch test boot] (as root) creates a new system according to your modified configuration.nix. If you use switch, it (re)starts updated/new services all on its own. If you broke your system, just reboot, and pick the second most recent boot entry, and you will be back where you started.
TL;DR NixOS is well worth the effort. The benefits far far outweigh the headaches, and there is only room for improvement. You will start with a system that you cannot break!
I have been using NixOS for a couple of months now, and still don't really understand how to write nix expressions.
Am I alone in thinking that this is irresponsible? Why not move releases to github?
Why aren't you going to start signing macOS binaries? I find this offensive. Thanks for potentially compromising users because you couldn't be arsed to pay for a certificate.
I'm assuming the price for hosting the mirrors isn't free, and probably more than $100/year. If they moved to github releases they could recoup some money.
Certs are free for apps published outside of the MAS: https://www.reddit.com/r/apple/comments/69n9ii/recent_versio... https://www.reddit.com/r/apple/comments/69n9ii/recent_versio...
as well as the potentially necessary Apple hardware
It's a pretty safe bet that an OS X/macOS developer already has a Mac.
If you don't want to take on that responsibility, then you could just quit hosting binary builds, and focus on the source. Then it becomes "someone else's problem" to deal with hosting binaries, and providing security.
Based on the information we have, you must also change all the passwords that may reside in your OSX KeyChain or any browser password stores."
That sounds like a very large exercise...
That is not to say that there are many good reason to do so, but the password manager do become a very coveted target.
edit: Maybe I phrased that badly. It is a risk associated with password managers that everyone that are using one should be aware of.
Your browser's native store is probably unencrypted [1], and the OS X keychain password can be snatched with a clone of the native password prompt. Neither is true for any respected password manager. They keep you safe.
Or for desktop security. Pretty sure Wayland's current security model prevents this as long as the password manager has a well-designed API.
With OS X keychain(and browser) unfortunately, if your system is compromised, you can decrypt the password store.
Is it really just because of the $99/yr developer program fee? And if so.. is it starting to sound like a better value now?
[1] https://developer.apple.com/library/content/documentation/Se...
Signing doesn't help unless you know which public key to trust.
While I'm at it, distributing through the Mac App Store would have added further protection against this attack on a couple levels. 1) It's harder to compromise with a MITM attack in the first place. 2) macOS wouldn't install an update signed by another party like this.
[1] "We have been informed that the process to update the definitions for OSX's XProtect feature started this morning, so this should start rolling out to machines automatically soon if not already."
"The HandBrake and HandBrake Documentation projects are not accepting monetary donations. Please instead consider donating to the VideoLAN non-profit organization and the Blender Foundation."
% codesign -vv HandBrake.app
HandBrake.app: code object is not signed at all
In architecture: x86_64
[1] http://gizmodo.com/mac-bittorrent-client-transmission-gets-i...
Is there a security product on OSX that would have prevented this?
Little Flocker. Unfortunately, it was sold to F-Secure [1].
I'm infected
Personally, I would wipe the whole system (rather than just removing the malware as in the steps that they describe) and change all credentials (passwords, SSH keys, etc.).
[1] https://9to5mac.com/2017/04/06/little-flocker-acquisition/
> Further Actions Required
> Based on the information we have, you must also change all the passwords that may reside in your OSX KeyChain or any browser password stores.
First take note of everything that might be vulnerable. You need to take care of this too, not just the infection.
There's a potential downside too: If a trojan gets into the PPA sources, it will be automatically downloaded and installed by users.
Apple does support code signatures for apps downloaded this way through their Developer ID program, but you have to pay $99/year to be a member of their developer program in order to do so.
In theory, you could still sign downloads using a code signing certificate you got elsewhere, but system wouldn't check it for you, and few people would bother to do it manually.
Hence, we have occurrences like the OP. The point is checking checksums or (better) signatures is the most common way to mitigate it. Otherwise, this will continue to happen. Dare I say that is the entire reason repo managers of all stripes do this in the first place.
[1] https://developer.apple.com/library/content/documentation/ID...
If you want to avoid these sorts of compromises, use a package manager or check the hash of the downloaded file against one that you trust.
Also, the package manager you're after is brew, specifically 'brew cask', which installs GUI apps.
EDIT: By the way, building from source doesn't stop someone replacing the source package the package manager uses. Sure you can look at the code in the package, but are you going to? It's more likely you'd check the code on Github, if at all.
brew has GUI applications. Easiest one I can think of (because I use it) is Pidgin.
Homebrew Cask currently can't address this kind of situation, since the binary is still built and distributed from non-reputable sources.
The correctness of the source code itself is surely a problem, but it's better than having to trust random binaries built and distributed from non-reputable sources.
Software like https://github.com/google/santa can help, especially if you're doing IT in a large enterprise.
The feed used by the software's autoupdate framework(sparkle) was signed, so that would've prevented bad downloads through autoupdate.
Chrome for example has a sort of a bloom filter which is used to check all downloaded executables. This will raise a nasty warning if the thing you downloaded is not a "popular" download.
For obvious reason, this check is disabled for a bunch of sites, like github, sf, ...
I know for a fact that some malware authors host their stuff on GitHub exactly to bypass this Chrome check.
Along with the fact that Apple updated the built-in sorta-antivirus in MacOS to detect it. But it only detects an SHA1 hash on the original DMG. If someone rebuilds the DMG or puts the malware with another app and builds a DMG, it'll bypass the MacOS sorta-antivirus.
Interesting, the malware creates a phishing-ish popup.
Any one client that's been hacked or infected would show up as an improper hash and easily spotted.
i'm sure <insert your favourite open source project here> would appreciate patches for reproducible, cryptographically signed releases
Full description here:
https://www.cybersixgill.com/wp-content/uploads/2017/02/0207...
If I understand correctly even if I had in fact downloaded the compromised version ClamXav wouldn't have detected the malware?
This kind of stuff is extremely worrying and really strengthens Apple's case for signed application binaries across the board.
Are package managers like Homebrew and MacPorts not also susceptible to this kind of binary poisoning?
Why shouldn't I create a "Tommy Transcoder" user on my system? That user would have the Handbrake app in his own Application folder. I assume that Handbrake will run correctly without needing to be installed in the system /Applications?
I already do this for a few items of software. Maybe it should be SOP to do this for most/all software?
Or what about installing most apps into virtual machines and using VMWare to run them?
I do recognize that such an approach couldn't be used universally. E.g. VMWare itself must run on the native machine, and with elevated privileges.
I'm interested in "defense in depth". No single technique can defend against all possible exploits.
To coin a phrase - oh shit