Recent version of Handbrake download infected with malware
forum.handbrake.fr
forum.handbrake.fr
Or he exposed himself on criminal hacking forums as an easy mark. But this is purely baseless conjecture.
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...
Maybe you are confusing state mutations with fixed points, which are used extensively (thankfully).
The reason I haven't is that NixOS is just so damn comfortable that I don't want to leave.
It's so easy.
When I upgrade or (un)install a package, I get a completely clean fresh installed system. If upgrading my video driver broke my system, I can just pick the most recent version of my install from the bootloader. When I want to start writing code, I can use nix-shell to create an isolated environment with all the dependencies I need, and get to work, with one command.
At any moment, I know that my entire OS install is completely clean, devoid of any cruft, even if I have been installing and removing obscure software for months. I don't have a mess in /etc, in /usr/share, anywhere.
> I'm not reinstalling my OS regularly so I don't really see the advantage.
With NixOS, I'm never reinstalling my OS, because every update leaves me with a fresh new system, guaranteed.
Guix devs themselves have hinted that "adding impurity to a free OS is much easier than removing impurity from a non-free OS", so I suspect they may not be categorically opposed to the idea of non-free packages.
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.
Will it add the packages installed this way to rpmdb?
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!
One question: can I remove systemd? :)
Any particular reason you don't want it?
I've heard good things about Void Linux, I'll likely have a look at that at some point.
On the flip side of the coin, I've kind of accepted that everyone who uses Linux has to put up with systemd now, so I'll accept my fate eventually. It's just that I value constructive and positive communication, I don't like the systemd team's blatant arrogance, and I consider it a corporate abuse of power that nothing has been done to curb or deal with it. (I hope I never have to deal with Red Hat in a business setting. Feathers, sparks, fur... everything would fly, and it wouldn't be pretty.)
I have never had an issue with it. In fact, systemctl has been much more consistent for me than init services ever were.
[1] http://nixos.org/nix/manual/
[2] http://nixos.org/nixos/manual/
I've seen plenty of projects that were exceptionally well documented. Every method and class had inline docstring documentation, every module has a separate module docstring block. 100% PEP 257 compliance was enforced as part of the CI tool chain... helpful but only after I was sufficiently knowledgeable about the way the project was being used to get any benefit from it. The the sheer volume of documentation meant that many people had written extremely terse explanations, often devoid of any of the contextual information that would significantly improve someone's understanding of how the code in question was be used.
Point is... The volume of documentation or the percentage of documented features, has no direct bearing on its usefulness to any particular user.
Where is this explained?
I am speaking from experience when I say the documentation is "absolute shit". Most of the useful documentation I have read comes from the deprecated wiki.
When I first installed NixOS, I had to read the source code for simple things like defining a user or getting samba set up, and still had to rely on the deprecated outdated wiki.
Three current state of documentation for NixOS is spread between the manual, deprecated wiki, and the source code itself. The manual barely shows how to get a simple system working, but as soon as you reach an edge case - which Nix itself is fantastically suited to handle - you have to start digging.
In time, documentation for NixOS will be mature and usable, but right now it is severely lacking, moreso than any other aspect.
I was personally donating monthly to Nix foundation for past few years, the maximum amounts that don't trigger tax concerns, but finally pulled my funding after the team continued to bury their heads in sand about state of docs for newcomers.
The main site docs are incomplete and reference style. The Wiki which had some use cases also had a banner saying it was all deprecated.
So you get newcomers who can't orient themselves, and even advocates like thomastjeffery in this thread who love it but months in still think the docs are wildly unhelpful.
Interestingly, guys who understand it very well are no longer capable of seeing the problem. They forgot what it's like to have no idea how any of it works, so can't describe the happy path between ignorance and the lightbulb coming on -- or even see that path isn't lit.
For now, the only way to walk that path is either absolute focus on learning it w/ no time for a day job, or have your hand held by someone enlightened (which is expensive for your MVPs compared to fixing the docs).
I have my bookmarked set of gists to guide me through these things and it took me days to get it right the first time.
Also nixpkgs are a bit of a mess, you usually get a version of a package someone has bothered creating a PR for. This might be very old or bleeding edge. For specific versions you can be SoL. It is of course fairly easy to have your own .nix of the package and PR's are usually accepted quickly but the repo usually doesn't keep previous versions.
And then there is a whole world of pain regarding language specific packages. Python is especially painful for me.
It took me ages to find the page which hints at nix-shelling projects but this is a pita and requires a completely new workspace setup that is not compatible with people that don't use Nix.
Regardless I love NixOS, but to say this is perfect, not even close.
- people talk about how rapidly they can perform complex edits with few keystrokes, which is something I most definitely can't do with Geany (a Notepad++ clone that made me wish Notepad++ worked on Linux); and
- it's a standard utility that you can generally expect to be available in some form on literally every UNIX (especially server environments).
So, basically I'm being pragmatic. I'm at the point where I'm wondering about building my own text editor (something I've wondered about for several years, actually), but that immediately introduces a software-installation problem if I want to be able to bring that editor to other machines.
I have a small modicum of knowledge about how to get by in vi, but it's extremely barebones - exiting, copy/pasting (I think the wrong way, heh), not much else.
I definitely could learn significantly more, but I just have a massively hard time fielding the idea of "okay let's play with the text editor for a few hours". Sure, once I was actually doing it I'd probably find it fun, I just can't convince my brain's broken scheduler that it's not actually a waste of time :D
As an aside: I'm wondering about building my own editor because I want something that can jump around text similarly to the Canon Cat and which has syntax highlighting and autoformatting similar to QBasic/QuickBASIC - and I'm frankly petrified by the idea of adopting a text editor that uses Blink for rendering. Blink (aka Chromium) is like Flash meets Java for UI design nowadays, it's almost like crack, and I want to do everything I can to stay as far away as possible from it.
This is not because the systems using it are not well-designed or -built, but because I fundamentally disagree with the philosophy and idea of using a Web rendering engine for tasks like communication or text editing. HTML5/CSS/JS/WASM is the world's biggest Rube Goldberg "safely run arbitrary code from remote servers" in existence; it wreaks enough havoc on the Internet, I don't want it leaking into my desktop too.
My main complaint is the W3C: they produce specifications that are too narrowly scoped and at too frequent a rate for the associated implementations to be operationally cohesive. The code for each feature in isolation might be excellently architected and written, but as a whole the amount of memory and CPU churn undeniably associated with rendering engines is significantly higher than would be found in platform-native (or even cross-platform) solutions.
You can definitely argue "well that's how things are now, the Web will improve as time goes by"; I'd argue that no, things have always been a mess in the Internet community, and nowadays the driving forces are all companies with advertising and/or consumer-consumption interests. This in itself isn't necessarily wrong, but it means that the focus is "is it good enough? okay, ship it" and there's no conservative holding back until what gets released is of extremely high quality.
EDIT: FOUND IT. This was the reference I was looking for about how the Internet's been crazy for years. The link referenced here is from 1998: https://news.ycombinator.com/item?id=10684426 (there's more commentary in the article itself - https://news.ycombinator.com/item?id=10682003 - the parent posts to the excerpt I linked were pretty big).
I have been using NixOS for a couple of months now, and still don't really understand how to write nix expressions.
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...
If distributing a commercial (or enterprise) application then yeah it's peanuts (or a rounding error). Good point.
There was a time when distributing content on Steam was free and anyone could do it.
This resulted in a lot of shit stuff, copied materials and fraud being distributed.
They introduced a $100 publication fee. As the story goes, it was very effective to stop abuse.
Irrefutable point though - it's one thing to want something for free as a consumer, but quite a different story as a creator or developer. I totally get the rationale behind charging to keep quality high.
Charging also creates a contract and with that contract be able to enforce a minimum standard. That helps greatly too.
"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."
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."
>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.
% 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.
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.
You'd need a way to change your certificate though (and keep it to the same account).
Some system through DNS? I think I'm just slowly reinventing OpenID
Then they can't silently gain access to your account persistently. They can gain access until you logout but then they have to wait for you to login again. Or they can change the key but then you'd notice that you can't login.
For this to really work, you need a way to detect compromise of the password. This way the 2nd factor holds you over until you've managed to rotate all important enough passwords.
Alternatively, separate trusted hardware with an interactive (i.e. challenge-response) protocol. Something like a TPM or yubikey.
Yes, we shouldn't have passwords for authentication at all, ever, period, and shouldn't have had them for at least a decade now. All the tech has long existed to switch to hardware backed public key cryptographic auth, and even to do so in a way that is far more user friendly then endless passwords and more secure at the same time, a sort of win-win that is quite unusual. We should all have HSMs (be it in the form of tokens, cards, compliant hardware in phones, or whatever) holding our private keys, and websites should only have our public certs. Entire classes of issues (like everything associated with password databases) would be perfectly and completely eliminated forever. There would be no dependence on any 3rd party services. Users would only need to remember at most a couple of PINs and that's it.
Back here on Earth though I can count every single site I've used in my life that had certificate based authentication and still have plenty of fingers left. Maybe U2F will make a bit more of a dent, but for a long time to come passwords will be the core of a lot of people's most critical personal security (like most of their money) and online identities. To have any value passwords need to be unique, and need to be fully random, and also have to deal with layers of extra crap that have been piled on top like password policies, arbitrary allowed characters (universal UTF? hahahaha), arbitrary minimum/maximum lengths, "security" questions (which should of course just be random strings lest they undermine the point of having a password but probably have their own special character restrictions), etc. Humans cannot remember all this garbage for more then a handful of sites. Password Managers are a practical solution to this mess of the "worst one except for all the other ones" variety. They effectively replicate (badly, but that's not their fault) some of what an actual decent key system would offer by default. They make attack scaling harder.
In short they're the best match to the most typical threat models most people face. Any good efforts to replace passwords period with keys is to be applauded, and if successful would eventually (years down the line) make password managers obsolete by making passwords themselves obsolete. But in the mean time password managers matter and people talking down at them due to issues that don't actually match general threat models are doing a terrible disservice to the public.
1. Use a password pattern. Something like 8 random digits that you memorize and then part of the domain name or business name. Such as "goo" for google. Put them in whatever order you like. Now you've memorized one pattern but use a unique password everywhere.
2. Use a predictable algorithm instead of a password. Their are web based services for this. You enter the domain name and then "encode" it to a password. That is typically not reversible.
These fall down some when you have to change a password or when a system has requirements that don't match your password (like requiring a number or symbol). Other users will mention other limitations as well.
Should be hard to crack and easy to remember.
Can anyone who actually knows this thing chime in?
There are 'stateless' password managers that work that way. It does not really protect against malware. If your user account is compromised by malware, what holds them from reading out your password and applying the same procedure to obtain password for interesting sites? You'll still be updating your password everywhere.
What you want is a second factor that uses a challenge-response mechanism with user interaction (e.g. U2F Yubikeys that require a finger press to start the challenge-response).
Even if they have plaintext password (which is often not case), this is just shasum. Feel free to guess which password (and which exactly scheme) I used to generate my password for news.ycombinator.com, if (of course it's now not like that :) it is:
bb05f766a74e6bf722136eaca97d9beb1fcc8f59d47c2d9e6eb1667d57c4cb82
You have now (after hacking whole hackernews db) access to my password ONLY for the hackersnews. Which was the original goal of the method: to use different passwords at different sites, which if compromised (password), do not reveal scheme used to generate it for different sites.
That's not the point. The malware would have access to your complete machine, possibly with root privileges, what holds them from reading your master password with a keylogger when you type it in?
It does not provide more security against trojans than a password manager.
I was replying solely and only to the acusation that after revealing plain text password on one site (which was generated using said scheme) you disclose every one.
This is simply not true.
In addition (but I didnt address that), there is no single keychain/password store to steal by the trojan. I can use it anywhere, using only my head as a 'storage' machine.
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.
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.
How would a respected password manager guard against an infected machine?
Take keepass as an example, they state: The actual problem here is running specialized spyware (as the same user and with the same rights, like KeeFarce assumes). If you are doing this, everything is over. An application cannot protect itself in such a case; all modern PC operating systems (Windows, Linux, ...) http://keepass.info/help/kb/sec_issues.html#keefarce
Also, at the bottom of the page: Neither KeePass nor any other password manager can magically run securely in a spyware-infected, insecure environment. Users still are responsible for the security of their PC.
Full description here:
https://www.cybersixgill.com/wp-content/uploads/2017/02/0207...
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.
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.
brew has GUI applications. Easiest one I can think of (because I use it) is Pidgin.
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.
There's a potential downside too: If a trojan gets into the PPA sources, it will be automatically downloaded and installed by users.
Just something to keep in mind when adding a PPA: you're tying your machine's integrity to the integrity of the PPA and its keyholder(s), and this trust is tested each time you update your packages.
[1] https://developer.apple.com/library/content/documentation/ID...
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?
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.
Btw, we treat hash changes very seriously in homebrew-core; they are never merged without a confirmation from the upstream. Unfortunately Cask apparently doesn't live up to the same standard, but Homebrew Cask is not really Homebrew.
I should be able to install a transcoding app like Handbrake without giving it all the keys to the kingdom and allowing it to do whatever it pleases.
The Microsoft hate would suggest they are restricting the permission system to Metro to encourage development to move towards Metro. It could also be that the underlying metro API is much easier to build a permission system for than the old windows one.
From what I've read though, these kinds of permission systems tend to only be a barrier. Sandboxes seem to always have some exploits. It would certainly be an improvement though.
With regards to file-systems, a simple linux based file-ownership model would do essentially the same.
> Isolation is the primary goal of an AppContainer execution environment. By isolating an application from unneeded resources and other applications, opportunities for malicious manipulation are minimized. Granting access based upon least-privilege prevents applications and users from accessing resources beyond their rights.
I'm not sure why this is not really used. Maybe requires some recoding from the original developer, maybe it's too inconvenient and creates frustration for users.
Even with file systems permissions, there are a lot of problems. For example, a transcoding app like Handbrake should be allowed access to users files, but ideally it would only be able to access VIDEO files. Any attempt at reading any other kind of file (source code, text files, password stores) should be forbidden. This requires a very expressive permissioning system.
I expect it’s the walled garden strategy that is unpopular with a techie crowd, not the idea that an OS should have more nuanced permissions than (to a first approximation) “any installer is either crippled or root”.
A lot of us have been concerned about the very coarse security model in mainstream OSes for decades, but there’s a huge amount of momentum behind the Windows, macOS and Linux ecosystems now. Any new platform with a fundamentally better security and application management system would have the usual chicken-and-egg problem in terms of users and software base, and without something else to drive it (such as inventing a whole new type of device with Android and iOS on smartphones) that’s a tough barrier to get over.
It is currently in a pretty early stage of development, but it's usable and looks pretty great. Maybe this time creating a new package manager will make the package manager wars on Linux quieter :)
Also, sandboxing GUI applications is more work than just slapping AppArmor or SELinux on top. First, users still expect to be able to open arbitrary files from their home directory (which would then be added on a case-by-case basis to the application's sandbox). Second, X11 does not provide UI isolation, so a sandboxed application can still read all keystrokes (and thus credentials). The Flatpak people realize this and are working towards the goal of eventually sandboxing GUI applications (on top of Wayland).
Apple actually nailed this pretty well. All applications in the App Store are sandboxed. If you open a file in such an application, the 'Open'-dialog runs out of process and links the opened file in the application's sandbox.
Unfortunately, there has been quite an organized campaign by a subset of macOS app developers to discredit the App store and especially sandboxing. Sure, it would be nice if macOS supported more fine-grained permissions and Apple has been slacking there. But for the end-user sandboxed App Store applications are much more secure than downloading unsandboxed applications from random developer sites. As this and previous incidents have shown.
[1] Since the switch to the 'targeted' policy.
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.
Note that I'm not proposing this as a replacement for the current cert system (which you pay into), but as a replacement for unsigned executables.
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.
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.
Here is theirs blog post introducing the feature in 2012: https://chrome.googleblog.com/2012/02/faster-browsing-safer-...
> Chrome also does checks on executable files (like ".exe" and ".msi" files). If the executable doesn't match a whitelist, Chrome checks with Google for more information, such as whether the website you're accessing hosts a high number of malicious downloads.
At the time I looked at the implementation in the Chrome source code, but I remember that it took me a while to locate it.
To coin a phrase - oh shit
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.
A user of a free product telling the developer of said free product how the developer should be spending the money that said user isn't giving them takes a special kind of entitlement.
In the latter case, there is also a third party tool capable of signing binaries:
https://github.com/saucelabs/isign
You do need to pay the $99/year for the certificate, but it shouldn't be necessary to buy hardware just to sign things.
Admittedly, if you don't have a Mac build machine, (a) you can't test your builds, and (b) you can't use the official SDK (including, e.g., system header files) without violating the terms of service. Not that many people care about that, but if you don't mind ToS violations you may as well just install pirated macOS in a VM (which is easy enough in practice). Perhaps Apple deserves blame for not having a legal way to run a macOS VM on non-Apple hardware; certainly it makes life harder for open-source developers that want to play by the rules. Still, these obstacles have nothing to do with signing.
If the developers are all students or something and can't pay for that, please let me know if there's a page asking for it and I'll pay or any of the other 1000 users who can.
There is a very simple solution. Get a dev program membership. Sign and sandbox the application and make it available in the Mac App store for $1.99. People who want a signed, sandboxed Handbrake pay the equivalent of a cup of coffee. People who want to play Russian roulette can download Handbrake for free on the web page.
Given that Handbrake is extremely popular, that small fee will probably cover the $99 per year plus a Mac Pro (or two) within no time.
Sorry but you are living in a bubble. There are thousands of software professionals who don't make that kind of money in India, South America and many other places.
Run some Google ads or something.
Come on, if every developer that uses any kind of Free Software decided to donate every hour the dollar amount of one HOUR of their work for the projects that THEY need, no one would be in this mess.
(Shrug) I've authored a large amount of software that's free as in both. I sign my releases for my users' protection, and also to avoid looking like a careless dilettante. I expect others who are serious about their craft to do the same.
If that makes me an "entitled jerk," well... meh. There's no way to respond to an accusation like that except to own it.
And how's that been working out for them (and their users)?
It likely worked out fine for anyone who checked the SHA256 before installing it. Which, unfortunately, is likely a small minority of users.
For free, the author could simply GPG sign all releases for all platforms and suggest users verify them. Then, the decision to run untrusted code is the user's decision and bypasses platform monetization.
Then, if suffient and continual contributions of money and expertise permit, official codesigning per platform could be added as another layer (defense-in-depth).
"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."
Please use very small words. I am struggling.
Best practices call for releases of executable code to be signed for the reasons outlined here.
Small enough?
So you are looking at an up-front cost of $300 then around $25 per year.
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.
[1]: https://medium.com/juan-cruz-viotti/how-to-code-sign-os-x-el...
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.
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