BusKill
OS Packages
Please release the CLI and GUI package in the following package managers...
- Scoop (Windows)
- Winget (Windows)
- Homebrew (Windows)
- apt (Linux)
- NIX (Linux)
@trymeouteh thanks for the ticket :)
I have good news: BusKill is already available in apt.
I won't release on any package managers that do not require everything that they download to have a valid cryptographic signature, so that excludes Homebrew.
I'll have to look into scoop, winget, and nix. Do you know if any of these require all packages to be cryptographically signed, like apt? If so, please link me to their documentation page that describes how they mitigate users downloading malicious packages due to MITM attacks using cryptographic signatures with pinned keys.
If I recall correctly, neither winget, scoop or nix requires cryptographic signing, they all have their own approaches to security, for nix you just need to make sure you specify the sha256sum of the binaries or repo, developing for nix should be not too difficult. I cant speak for everything else, has there been any work in getting this available on nix or other package managers?
Hashes don't provide cryptographic authenticity. We won't undertake any effort to release BusKill on a package manager that could lead to our users downloading a malicious version of BusKill.
We haven't made effort for nix. It's available on apt for fast, easy, secure, and very lightweight installs on Debian-based systems. The cryptographically-signed AppImage should work for all other systems, although it's not as easy and a much larger release (in bytes).
If you can link me to the man apt-secure equivalent for another distro's package manager that makes it clear that all packages' cryptographic signatures MUST be verified after download and before install, then we'll look into packaging for that system.
Nix is effectively a source-based package manager, you don't need to care about signatures at that level.
If a package for BusKill were submitted to Nixpkgs, it would be built by a build farm and uploaded to a binary cache. This artifact would be signed. Nix is configured to use this binary cache by default, and to verify the signatures of everything downloaded from it.
If a package for BusKill were submitted to Nixpkgs, it would be built by a build farm and uploaded to a binary cache. This artifact would be signed. Nix is configured to use this binary cache by default, and to verify the signatures of everything downloaded from it.
That sounds ok. Can you please link to the documentation that describes this, so I can review it?
Nix is effectively a source-based package manager, you don't need to care about signatures at that level.
This makes less sense to me. How does it verify the source code is authentic? It must use a signature for that, yes?
I've looked into Nix in the past. I liked how it claimed reproducibility was a large part of it, but iirc I couldn't figure out how it ensures reproducibility, if this was still a planned feature, or if all packages are currently required to pass some reproducibility test.
If nix simply downloads the sourcecode for BusKill (and its dependencies!) from GitHub using just TLS for "security," then its releases would be far less trustworthy than a our official, pgp-signed AppImage.
That sounds ok. Can you please link to the documentation that describes this, so I can review it?
https://nix.dev/manual/nix/2.25/command-ref/conf-file.html#conf-substituters https://nix.dev/manual/nix/2.25/command-ref/conf-file.html#conf-trusted-public-keys
This makes less sense to me. How does it verify the source code is authentic? It must use a signature for that, yes?
The hash of the content to be downloaded is stored as part of the expression. This makes the build deterministic. It is also authentic, as long as whoever wrote the expression ensured that the hash matches the authentic source for the corresponding version.
Also seems relevant:
- https://nix.dev/manual/nix/2.25/command-ref/conf-file.html#conf-require-sigs
require-sigs
If set to true (the default), any non-content-addressed path added or copied to the Nix store (e.g. when substituting from a binary cache) must have a signature by a trusted key. A trusted key is one listed in trusted-public-keys, or a public key counterpart to a private key stored in a file listed in secret-key-files.
Set to false to disable signature checking and trust all non-content-addressed paths unconditionally.
(Content-addressed paths are inherently trustworthy and thus unaffected by this configuration option.)
Default: true
@SpiderUnderUrBed am I missing something, or does this prove that nix does require cryptographic signing (by default)?
If I recall correctly, neither winget, scoop or nix requires cryptographic signing, they all have their own approaches to security, for nix you just need to make sure you specify the sha256sum of the binaries or repo, developing for nix should be not too difficult.
To be clear, I don't mind if there's some (dev) option available to bypass sigs, so long as this is set client-side, it's not on by default, and it's not an incredibly easy/common UX to do so..
Well this isn't a good sign:
- https://nixos.wiki/wiki/Security
Your ISP (and/or VPN provider) has been banned from nixos.wiki due to ongoing attacks originating from their IP space.
To regain access to the wiki, you can:
- Use another internet service provider.
- Contact your ISP and urge them to take action that will result in a stop of the attacks.
I changed IPs 3 times and I consistently get this message. Usually that means they're not actually temp-blocking troublesome IPs but lazily deciding to wholesale block all known VPN IPs, which is unnecessary to defend against DoS and does great harm to at-risk users.
If nix isn't accessible on Tor, I'm not sure it's a good choice for us..
But also, Nix != NixOS, right? What's their relationship? Are there any other systems that use nix but don't use NixOS?
If only the unofficial wiki people would finally shut down their awful site... https://wiki.nixos.org/wiki/Security
I've poked through a lot of the docs, but it's still very unclear to me if nix is secure. I went to try some forums to ask questions, and the nix docs linked me to to a forum of nixos, so now I'm even more confused. Let's start by trying to figure out what project is what:
- https://discourse.nixos.org/t/what-is-the-relationship-between-nix-and-nixos/57828
I also traced through how apt verifies signatures, and asked for an equivalent example in nix:
- https://discourse.nixos.org/t/where-are-the-cryptographic-signatures-sha256sums-release-gpg/
If only the unofficial wiki people would finally shut down their awful site... https://wiki.nixos.org/wiki/Security
It took me a few days to understand your comment, but if I understand it correctly:
- https://nixos.wiki/wiki/Security - This is an "awful" unofficial wiki that I can't load
- https://wiki.nixos.org/wiki/Security - This is the official wiki for Nix, and it loads fine.
Also, NixOS is the name of the organization that develops both NixOS and Nix. So the wiki (and all services at the nixos.org domain) is the official sites for both tools (the OS and the package manager).
Oh man, this is a major red flag
- https://nixos.org/download/#nix-verify-installation
# DO NOT EXECUTE THIS; IT'S EXTREMELY DANGEROUS
# sh <(curl -L https://nixos.org/nix/install) --daemon
# DO NOT EXECUTE THIS; IT'S EXTREMELY DANGEROUS
After studying nix for a few days, I've decided it doesn't sufficiently defend against a threat model of many BusKill users, and we therefore won't package BusKill for nix.
It does appear that the binary nix packages in the "nix cache" are signed, but -- despite many users asking for it -- there is no signatures on the source code. Therefore, as far as I can tell, the only protection nix users have when downloading BusKill from its sources would be X.509, which is horribly broken and vulnerable. Therefore, if a user was to try to install BusKill on nix from its original sources, an APT could MITM the user such that they download malicious sourcecode, and nix would happily install the malware on their system.
It's better for NixOS users to download our AppImage, which is cryptographically signed with PGP.
You have not yet proven that your potential "MITM" with sources was possible with nix but not APT.
For me is only clear that you do not sign your sources, so any third party signing them only shifts the point of trust but does not introduce any form of additional security.
I have to be honest though, I have no clue what buskill was or does, but just got here because the issue was discussed in our discord and linked from the Nixos discourse.
Anyway, appimages will not run well on NixOS system, so if nix users want to use your software, there will be no way for them to "package" it.
Doing this for any software not already in nixpkgs is highly encouraged and also PRing this into nixpkgs after some testing phase.
So if there is a demand, this software will eventually get packaged out of the necessity.
And as you seem to massively misunderand what nix is used for and why, it is probably better if this happens by someone who understands nix and your product.
Please don't take this as an offense. I just want to make you aware that you are not aware to get the full picture of nix, if you don't commit to it.
This is fine. Nix isn't for everyone.
Our project does sign our source code for every release. This signature is checked by our debian maintainer before being synced into their repos:
- https://github.com/BusKill/buskill-app/releases/tag/v0.7.0
- https://docs.buskill.in/buskill-app/en/stable/software_dev/release.html#build-sign
- https://github.com/BusKill/buskill-app/issues/53
If Nix was able to require a good signature using this or some other method, we'd be open to using it. But, without verifying the signature of the sources, it would leave users vulnerable to receive malicious code.
Therefore, as far as I can tell, the only protection nix users have when downloading BusKill from its sources would be X.509, which is horribly broken and vulnerable.
This is completely incorrect. Nix validates that the SHA256 of the downloaded sources matches a known hash. If it doesn't, Nix will fail to build the package pretty quickly.
Hashes are useless (for verifying authenticity) without signatures (of those hashes). If someone can modify the payload, (and there's a near 100% certainty that there are currently compromised CAs [and/or subordinate CAs] in the root stores), it's trivial to modify the hash too.
I'm getting tired re-stating this over-and-over.
And I'm sure everyone in the Discourse thread that you started is tired of having to explain that the Nix security model has nothing to do with X.509 certificates despite you repeatedly being told how the security model actually works, and you continuously failing to explain what your supposed issues with Nix actually let an attacker do.
The only realistic attack so far involves GitHub itself having a compromised CA (at which point you can't trust this repository either), and even that has a potential mitigation.
Here's a potential 'solution', include the Nix "recipe" with the signed source tarballs. That way, anyone can validate its authenticity and build it themselves locally.
at which point you can't trust this repository either
The releases are signed, so you would at least notice the attack. If you check the signature.
at which point you can't trust this repository either
The releases are signed, so you would at least notice the attack. If you check the signature.
Great. So someone updating the Nix package could also check the signature, see that it's valid, and update the source hash based on that.
(There is just one problem with this approach: the Github-generated source tarball v0.7.0.tar.gz changed/was recompressed in the meantime, so the hash no longer matches.)
I could misunderstanding the point you're making, but Nix checking the tarball hash but rather its extracted content, so recompression shouldn't matter
I was referring to the signatures provided here.
If you check https://github.com/BusKill/buskill-app/releases/download/v0.7.0/SHA256SUMS and the tarball, the hash does not match.
Assuming that's the hash of the tarball (I can't check right now since I'm on mobile), it still isn't relevant because Nix is checking the hash of the extracted contents of the tarball and not the tarball itself
@FliegendeWurst
(There is just one problem with this approach: the Github-generated source tarball v0.7.0.tar.gz changed/was recompressed in the meantime, so the hash no longer matches.)
nix checks the content hash, not the tarball itself.
Ooops stupid me, I now see in the replies that you were aware and pointing out a flaw in the signage that did not match the repacked tarball anymore.
Sorry for the noise and ping.
Not deleting this message but just adding to it, as I do not know how GH deals wit ghost-pings.
As I said, I am only referring to the signatures / hashes provided by the developer.
If you check https://github.com/BusKill/buskill-app/releases/download/v0.7.0/SHA256SUMS and the tarball, the hash does not match.
I am aware that Nix does a content hash. The threat model of maltfield includes a MITM attack on GitHub, so it would be trivial to replace both the source of buskill-app and the content hash in nixpkgs.
The signature is still good. Did you test it?
user@disp1974:~$ gpg --verify v0.7.0.tar.gz.asc
gpg: assuming signed data in 'v0.7.0.tar.gz'
gpg: Signature made Sat 17 Jun 2023 06:39:36 PM -05
gpg: using RSA key 798DC1101F3DEC428ADE124D68B8BCB0C5023905
gpg: Good signature from "BusKill Releases Signing Key 2020.07 <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: E0AF FF57 DC00 FBE0 5635 8761 4AE2 1E19 36CE 786A
Subkey fingerprint: 798D C110 1F3D EC42 8ADE 124D 68B8 BCB0 C502 3905
user@disp1974:~$
Our PGP key info is here:
- https://docs.buskill.in/buskill-app/en/stable/security/pgpkeys.html
Using PGP signatures allows to use untrusted infrastructure. Even if our Publishing Infrastructure (eg GitHub) was compromised, users would be able to see that they downloaded something inauthentic.
This has historically happened to many other projects:
- https://github.com/cncf/tag-security/tree/main/community/catalog/compromises
For example, monero's release infrastructure was compromised in 2019, and it didn't take long for the community to discover it -- because users reported that the signature was invalid.
The signature is still good.
You are right. I initially didn't test it since the sha256sum did not match in the first place.