OverviewExploreTrending
Nostr Archives
OverviewExploreTrending
franzap13d ago
I'm actually quite shocked with the responses in this thread. No one seems to care much about proper hash verification? People commenting here are not your average Windows normie. They use Linux. They are familiar with the command line. They are aware of Nostr's main selling points. Censorship resistance and cryptographic verification good for shitposting... but for software "trust me bro" just fine? Holy shit. 📝 f92e8203…
💬 46 replies

Replies (46)

semisol13d ago
Every package manager under the sun already does signature verification.
0000 sats
franzap13d ago
You can do better
0000 sats
semisol13d ago
There is an adjacent initiative just about this that you might find useful and addresses many of the same things https://www.sigstore.dev/
0000 sats
tinfoil hash13d ago
because they’re (mostly? all?) centralized?
0000 sats
ChipTuner13d ago
Yeah this. I think the OP was a bit much. Yes the user could take verification into there own hands like we do, but most wont, so repos, repo maintainers and distributions already (at least the major modern repos) by default already have pretty good signature verification with a pretty user friendly way of verifying and installing keys if needed. 3rd party repos are often signed if users want to get signed packages from the devs too.
0000 sats
semisol13d ago
Every package manager under the sun already does signature verification.
0000 sats
franzap13d ago
You can do better
0000 sats
semisol13d ago
There is an adjacent initiative just about this that you might find useful and addresses many of the same things https://www.sigstore.dev/
0000 sats
ChipTuner13d ago
Yeah this. I think the OP was a bit much. Yes the user could take verification into there own hands like we do, but most wont, so repos, repo maintainers and distributions already (at least the major modern repos) by default already have pretty good signature verification with a pretty user friendly way of verifying and installing keys if needed. 3rd party repos are often signed if users want to get signed packages from the devs too.
0000 sats
franzap13d ago
I don't want to offend anyone. I'd like to see responses here explaining why I am wrong.
0000 sats
Max13d ago
Someone should do something about that...
0000 sats
franzap13d ago
If the market does not want it, not doing anything about it 🤷‍♂
0000 sats
Max13d ago
They're just asking for faster horses... But to be fair, there's like 101 packet managers on Linux already.
0000 sats
mIX13d ago
I really like that this is coming up. Verifying software is a painful process and a lot of people don't even know what you're talking about when they get asked. I'm barely able too. Even found the process annoying trying to check APKs with appverifier because the apk hash isn't always available... I've been trying to figure out how the NixOS (nixpkgs) works because I want to try helping with maintaining some software packages... and I wanted to know if the software I used was checking the devs signing correctly. At this point I just feel more confused than informed.
0000 sats
franzap13d ago
Yep. That's the whole point of Zapstore
0000 sats
mIX13d ago
I really like that this is coming up. Verifying software is a painful process and a lot of people don't even know what you're talking about when they get asked. I'm barely able too. Even found the process annoying trying to check APKs with appverifier because the apk hash isn't always available... I've been trying to figure out how the NixOS (nixpkgs) works because I want to try helping with maintaining some software packages... and I wanted to know if the software I used was checking the devs signing correctly. At this point I just feel more confused than informed.
0000 sats
franzap13d ago
Yep. That's the whole point of Zapstore
0000 sats
Silberengel13d ago
I Nostr-sign my commits and releases, now. It's really easy to do, but I wonder if it will catch on.
0000 sats
tinfoil hash13d ago
how do you do this? how does a consumer verify a release?
0000 sats
Silberengel12d ago
I produce a release event that contains the associated commit hash and the download URL for the tag.
0000 sats
Leo Wandersleb13d ago
It's pragmatism. People want to get stuff done so they get their tools from 12 different package managers and trust those. Those repositories all have reputation to lose, so there is some incentive to hunt down bad stuff. Is it enough? Probably not for every use case but the right amount of resources to check everything all the time is certainly not "all resources". I'm embarrassed to admit not to use NixOS yet but there's a million things on my todo list and that's one of those.
0000 sats
franzap13d ago
Good point
0000 sats
ChipTuner13d ago
Windows by default requires 3rd party executables to be signed by Microsoft certificate chains.
0000 sats
ChipTuner13d ago
Windows by default requires 3rd party executables to be signed by Microsoft certificate chains.
0000 sats
Sebastix13d ago
Installing LibreOffice with pacman failed for me due invalid signatures
0000 sats
franzap13d ago
Cool but does this prove anything? The signatures are pretty much centralized
0000 sats
Sebastix13d ago
Dunno My knowledge around this stuff is lacking 🤨
0000 sats
DireMunchkin13d ago
I'm not an expert on this but I know Linux Mint uses APT as the package manager - How APT does things is that each repository has a GPG key that signs each package. The repository itself is imported from a list embedded in the OS. So you really don't need to verify signatures in normal operation. You should mainly do it when downloading the OS itself and making bootable media since this is the start of the trust chain.
0000 sats
DireMunchkin13d ago
FWIW I asked Maple about this and here's what it said: ***** Yes, on all major Linux distributions, package installation is cryptographically signed and verified by default—but the implementation varies by distribution and package format. ## How Major Distros Handle Signing **Debian/Ubuntu (APT)** - **Repository metadata** is signed with GPG keys. APT verifies the `Release` file signature before trusting any package lists. - **Individual packages** are typically signed by the maintainer's key, though APT primarily trusts the repository metadata rather than verifying every package signature independently by default. - Keys are stored in `/etc/apt/trusted.gpg.d/` or managed via `signed-by` in sources lists. **RHEL/CentOS/Fedora (RPM/DNF/YUM)** - **Packages** are GPG-signed by the packager (the `.rpm` file contains the signature). - **Repository metadata** is also signed. - DNF/YUM verify package signatures before installation using keys in `/etc/pki/rpm-gpg/`. - You can check a package's signature with: `rpm -K package.rpm` **Arch Linux (Pacman)** - **Packages** are signed by Arch Linux developer or Trusted User keys. - Pacman has a web of trust model; the `archlinux-keyring` package distributes trusted keys. - Signatures are stored as separate `.sig` files. **Alpine Linux (APK)** - Uses **RSA signatures** (not GPG). Each package has a corresponding `.rsa.sig` file. - Public keys are stored in `/etc/apk/keys/`. **openSUSE (ZYpp/RPM)** - Similar to Fedora: RPM packages are GPG-signed, and repository metadata is signed. ## Universal Package Formats - **Flatpak**: OSTree commits are signed with GPG; apps are verified against remotes. - **Snap**: Packages are signed; the snapd daemon verifies signatures from the Snap Store. - **AppImage**: Generally **not signed** by default (though some projects embed signatures separately). ## Important Caveats 1. **Manual downloads**: If you manually download a `.deb` or `.rpm` from a website and install it with `dpkg -i` or `rpm -i`, signature verification may be skipped or require manual key import. Using the distro's package manager (APT/DNF) enforces verification. 2. **Disabled verification**: You can disable signature checking (e.g., `apt-get --allow-unauthenticated` or `rpm --nosignature`), but this defeats the security model. 3. **Third-party repositories**: When adding a new repo, you must manually import the GPG key. The security depends on whether you verify the key fingerprint through a trusted channel. 4. **Build-from-source**: Compiling from source code (e.g., `make install`) bypasses the package signing system entirely. ## Verification Commands ```bash # Debian/Ubuntu: Check repository key apt-key list # Fedora/RHEL: Verify a package signature rpm -qi package_name | grep Signature # Arch: Verify package databases pacman-key --list-sigs # Alpine: Check keys ls /etc/apk/keys/ ``` **Bottom line:** Modern Linux distributions treat cryptographic signing as mandatory for their official repositories, protecting against man-in-the-middle attacks and package tampering. However, the security is only as strong as your key management practices and whether you verify keys when adding third-party repositories.
Alan11d ago
One critique I rarely find mitigated is that the hash is stored alongside the binary. So if the attacked can swap out the binary, the hash is right there (vs somewhere more protected). Also hash verification vs checking a pgp --verify is depending on wot. I would love to see nostr signatures here and nostr wot integrated into pgp.
0000 sats
franzap13d ago
OP was meant to be over the top, correct. > pretty user friendly way of verifying and installing keys if needed Not my experience. That's totally fine, this issue is subjective.
0000 sats
ChipTuner13d ago
Do you verify every IP packet that is forwarded through your firewall? Or do you trust your firewall maintains a robust state table? You do use recursive DNS with strict signature verification? Do you read the headers (and DKIM signatures) in your email client before reading them or do you trust you mail server did DMARC, DKIM, SPF, rDNS, and IP verification? Unless you're using your using using IPTables as your firewall with debug logging on, your own recursive DNS resolver with a verifying server in front of it, or for email using K9-Mail on mobile or RoundCube on desktop to your self hosted mail server, chances are you didn't do any of those. Do I wish people did more verification, you bet I do. But we'd all defer that if we could, it's obnoxious for even the advanced linux user to do, and many of not most system-level applications don't even ship outside the distro's repo, so you couldn't verify if you wanted to. Not to mention still, few projects even sign there commits let alone sign their builds. I say this as someone who's built my own cli installer tool to manage my own dependencies because this is such a big deal. But I'm regularly interacting with normies on this (colleagues and customers) and know that they'd rather trust me to do it for them.
00
Zsubmariner13d ago
For end-users, yeah, the package manager is taking care of it. Even though the key layer actually sucks still, at least it's there. But most devs are way too blasé about supply chain security. Especially in js and rust. I cringe every time I see one of those pipe curl to bash oneliners.
0000 sats
tinfoil hash13d ago
because they’re (mostly? all?) centralized?
0000 sats
franzap13d ago
OP was meant to be over the top, correct. > pretty user friendly way of verifying and installing keys if needed Not my experience. That's totally fine, this issue is subjective.
0000 sats
ChipTuner13d ago
Do you verify every IP packet that is forwarded through your firewall? Or do you trust your firewall maintains a robust state table? You do use recursive DNS with strict signature verification? Do you read the headers (and DKIM signatures) in your email client before reading them or do you trust you mail server did DMARC, DKIM, SPF, rDNS, and IP verification? Unless you're using your using using IPTables as your firewall with debug logging on, your own recursive DNS resolver with a verifying server in front of it, or for email using K9-Mail on mobile or RoundCube on desktop to your self hosted mail server, chances are you didn't do any of those. Do I wish people did more verification, you bet I do. But we'd all defer that if we could, it's obnoxious for even the advanced linux user to do, and many of not most system-level applications don't even ship outside the distro's repo, so you couldn't verify if you wanted to. Not to mention still, few projects even sign there commits let alone sign their builds. I say this as someone who's built my own cli installer tool to manage my own dependencies because this is such a big deal. But I'm regularly interacting with normies on this (colleagues and customers) and know that they'd rather trust me to do it for them.
00
Zsubmariner13d ago
For end-users, yeah, the package manager is taking care of it. Even though the key layer actually sucks still, at least it's there. But most devs are way too blasé about supply chain security. Especially in js and rust. I cringe every time I see one of those pipe curl to bash oneliners.
0000 sats
elsat12d ago
Generally, this process is not for the consumer. Some power users will go in and verify based on provided instructions from the depths. @78ce6faa…f026307d brings in sig verification as a core part of the UX.
0000 sats
Silberengel12d ago
I invented some new kinds, including a release note from the publisher.
0000 sats
Silberengel12d ago
Zapstore is more like Google Play; it's for Android app downloads. Different sector. I'm signing git commits and git commit tags, inside of the source repo.
0000 sats
Sebastix13d ago
Oh and the packages are signed by the author / published if I’m correct So I’m curious what is centralized?
0000 sats
0000 sats
0
0 sats
franzap13d ago
Agree. I think UX has a lot of room for improvement as you can probably tell from what I'm building
0000 sats
Diacone Frost13d ago
And then you find some page on the interweb with instruction to use arbitrary copr repo to install a "fixed" version of something. pubkey is presented, you press yes (or use -y in the first place). done. even if you verify the key, what's the point. you can't verify every build, you wouldn't be doing anything else.
0000 sats
ChipTuner13d ago
Sigh. I know. Most people argue the trade offs. "Wouldn't you rather have software that's risky and poorly distributed than none at all?" Or something to that effect, maybe with less verbosity. I still love the Obtainium model though. Like let me get the package from the maintainers github, website, ftp site etc. Albeit id prefer more verification... Some maintainers _do_ care about secure supply chains. And even the repeatable build from source argument is a loss imo. My projects can take anywhere from 5-25 minutes to build from source with powerful processors.
0000 sats
ChipTuner13d ago
I also think maintainers should do their best to support all walks on this. Signed, unsigned, repo managed, direct package download, build from source, and signed commits.
0000 sats
ChipTuner13d ago
dnf repo info Just because it's simple doesn't mean its easy, you're right... But it's on the education front at this point imo. There is only so much hand holding a distro can do for users without really getting in the way.
0000 sats
ChipTuner13d ago
`dnf repo info` > I cringe every time I see one of those pipe curl to bash oneliners. Yup. Side note, I use Taskfile.dev in my projects and it has a neat side effect that end-users or contributors can do a --dry-run to see all of the commands the "script" will run before before it does them, and it will echo them during a normal build. For me it's just a nod to my users imo.
0000 sats
Zsubmariner13d ago
Nice. I recently did a two step on one of my projects, so that the script the user should read is tiny, grabs the more fullsome script from two locations (codeberg and website) compares them and then uses that to fetch platform specific build, signatures, etc. If you have our tool already installed, it will even give a QR code of the projects npub which is cooked into the build sig. (Kinda neat, still minisign compatible.) https://zsubmesh.net/downloads/
0000 sats
0
0 sats
franzap13d ago
Agree. I think UX has a lot of room for improvement as you can probably tell from what I'm building
0000 sats
Diacone Frost13d ago
And then you find some page on the interweb with instruction to use arbitrary copr repo to install a "fixed" version of something. pubkey is presented, you press yes (or use -y in the first place). done. even if you verify the key, what's the point. you can't verify every build, you wouldn't be doing anything else.
0000 sats
ChipTuner13d ago
Sigh. I know. Most people argue the trade offs. "Wouldn't you rather have software that's risky and poorly distributed than none at all?" Or something to that effect, maybe with less verbosity. I still love the Obtainium model though. Like let me get the package from the maintainers github, website, ftp site etc. Albeit id prefer more verification... Some maintainers _do_ care about secure supply chains. And even the repeatable build from source argument is a loss imo. My projects can take anywhere from 5-25 minutes to build from source with powerful processors.
0000 sats
ChipTuner13d ago
I also think maintainers should do their best to support all walks on this. Signed, unsigned, repo managed, direct package download, build from source, and signed commits.
0000 sats
ChipTuner13d ago
dnf repo info Just because it's simple doesn't mean its easy, you're right... But it's on the education front at this point imo. There is only so much hand holding a distro can do for users without really getting in the way.
0000 sats
ChipTuner13d ago
`dnf repo info` > I cringe every time I see one of those pipe curl to bash oneliners. Yup. Side note, I use Taskfile.dev in my projects and it has a neat side effect that end-users or contributors can do a --dry-run to see all of the commands the "script" will run before before it does them, and it will echo them during a normal build. For me it's just a nod to my users imo.
0000 sats
Zsubmariner13d ago
Nice. I recently did a two step on one of my projects, so that the script the user should read is tiny, grabs the more fullsome script from two locations (codeberg and website) compares them and then uses that to fetch platform specific build, signatures, etc. If you have our tool already installed, it will even give a QR code of the projects npub which is cooked into the build sig. (Kinda neat, still minisign compatible.) https://zsubmesh.net/downloads/
0000 sats
franzap13d ago
Is Obtainium better than Zapstore?
0000 sats
Diacone Frost13d ago
not for me. but it takes time to make sure that an app is genuine when a key changes...
0000 sats
Diacone Frost13d ago
I don't know the solution. If some dev goes rouge even your WoT is only able to tell you "i have this version too" is there a way to signal fraud? what if someone from WoT signals it wrong?
0000 sats
ChipTuner13d ago
I haven't used Zapstore or Obtainium in a while. TLDR; I basically don't use a smartphone.
0000 sats
Alan11d ago
The problem with Obtainium is normies don't know how to choose alternate builds. The prompt they get is ...x86_64, fdroid, gplay, arm64v7, arm64v8, or whatever naming convention they come up with arbitrarily.
0000 sats
franzap13d ago
Is Obtainium better than Zapstore?
0000 sats
Diacone Frost13d ago
not for me. but it takes time to make sure that an app is genuine when a key changes...
0000 sats
Diacone Frost13d ago
I don't know the solution. If some dev goes rouge even your WoT is only able to tell you "i have this version too" is there a way to signal fraud? what if someone from WoT signals it wrong?
0000 sats
ChipTuner13d ago
I haven't used Zapstore or Obtainium in a while. TLDR; I basically don't use a smartphone.
0000 sats
Alan11d ago
The problem with Obtainium is normies don't know how to choose alternate builds. The prompt they get is ...x86_64, fdroid, gplay, arm64v7, arm64v8, or whatever naming convention they come up with arbitrarily.
0000 sats
franzap11d ago
I have used Obtainium a LOT and I am glad it exists but the UX is terrible
0000 sats
franzap11d ago
I have used Obtainium a LOT and I am glad it exists but the UX is terrible
0000 sats