Package Details: keybase-bin 6.4.0_20240821175720+3212f60cc5-1

Git Clone URL: https://aur.archlinux.org/keybase-bin.git (read-only, click to copy)
Package Base: keybase-bin
Description: the Keybase Go client, filesystem, and GUI
Upstream URL: https://keybase.io
Licenses: BSD
Conflicts: kbfs, keybase, keybase-git, keybase-gui, keybase-release
Provides: kbfs, keybase, keybase-gui
Submitter: oconnor663
Maintainer: keybase
Last Packager: keybase
Votes: 147
Popularity: 0.25
First Submitted: 2016-06-22 16:52 (UTC)
Last Updated: 2024-08-21 18:09 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »

oconnor663 commented on 2017-08-02 17:37 (UTC)

@Eschwartz good point, it shouldn't be too much trouble to persist the sig files the same way we do the packages. Apologies for all the rough edges you're hitting -- you might be the first person who's tried coding anything against these sigs.

eschwartz commented on 2017-08-02 17:28 (UTC)

Thanks. I was trying to add the signature checking myself (it's quite easy to use git rebase for local changes), but I couldn't figure out where the signatures were actually kept... I think I've figured it out though. In build_and_push_packages.sh the signatures are only created by another_copy(), for the third copy you make, the one without a version in the filename. So, assuming I read this right, if I wanted to download any given version of https://s3.amazonaws.com/prerelease.keybase.io/linux_binaries/deb/keybase_${deb_pkgver}_${deb_arch}.deb I can only verify it with https://prerelease.keybase.io/keybase_${deb_arch}.deb.sig assuming "any given version" means strictly "nope, just the last one". I suppose for the first, deb/rpm repo, copy, it makes sense to not include .sig files in that directory in favor of using whatever the repository management software uses (which for Arch Linux would still be .sig files), but I was kind of expecting that the second linux_binaries copy would have persistent, versioned .sig files.

oconnor663 commented on 2017-08-01 19:29 (UTC)

@Eschwartz done.

eschwartz commented on 2017-07-28 20:41 (UTC)

Please use e.g. `deb_pkgver=${pkgver/_/-}; deb_pkgver=${deb_pkgver/+/.}` to set a variable for use in source_* and deb_package as this makes it easier to see what else changed in `git log -p`.

eschwartz commented on 2017-07-25 19:40 (UTC)

The general argument would be that you can verify the same key is signing sources each time, whereas checksums don't really say anything about authorship. But I suppose it is a fair point that these are the checksums provided by upstream, so we can probably assume the PKGBUILD maintainer didn't get tricked at the same time as users. That being said, makepkg tells you when it is verifying GPG, and anything other than a source+=(*sig); validpgpkeys=(qwerty1234); e.g. redefining the makepkg function responsible for verification? would be a hugely noticeable red flag I think. Anyway, at the end of the day I tend to err on the side of more capable users...

oconnor663 commented on 2017-07-25 19:28 (UTC) (edited on 2017-07-25 19:36 (UTC) by oconnor663)

@Eschwartz I agree that skipping security measures in a security product isn't a good idea in general :) In this case, though, it's not clear to me that the signatures provide any value over the hashes that we already include. The current PKGBUILD is totally locking down the file it's getting, so I don't think there's any opening for the server to give you bad bits once the build has started. The remaining open question is then, is the PKGBUILD *itself* correct? (For example, might aur.archlinux.org have slipped in evil hashes? Maybe even just for me personally, so that no one else could detect the attack?) Could including a GPG signature verification step help us be more confident, if we were auditing the PKGBUILD code? It might sound helpful, but I'm afraid there's some circular logic there. Can a script really verify that its own code isn't malicious? Would an evil PKGBUILD include the right Keybase PGP fingerprint? Are there ways to disable GPG verification entirely that an auditor might never notice (in the spirit of http://www.underhanded-c.org)? We're getting into "trusting trust" territory. [Maybe more realistic than any of that, if aur.archlinux.org simply decided to delete the verification step for targeted users, as part of changing the hashes and shipping evil bits, do we expect those targeted users to realize that a verification step *should have* been there?] So at the end of the day, I worry the (small but non-zero) usability downsides of sig checking outweigh the (possibly actually zero) security benefits. [One thing I might be happier to do, would be to publish signatures of the PKGBUILD scripts themselves, so that users who really cared about this could verify them out of band. But I'm skeptical that anyone would ever actually go through that procedure, even if we documented it.]

eschwartz commented on 2017-07-25 19:04 (UTC)

@oconnor663 > @dbrgn I like that idea, though is it ok to import a PGP key into someone's local keyring from inside a PKGBUILD script? I'd prefer not to have one of those "this doesn't work unless you run this gpg command first" packages. This is explicitly documented on the Makepkg wiki page and in the manpages. Please add the signature files to the source=() array, and add the PGP signing key fingerprint to the validpgpkeys=() array. makepkg will take care of checking the signature. It will emit a descriptive error if the user has not imported the key at any point in their computer's history. AUR users are expected to understand at least a little part of the basic process of using makepkg, and that includes knowing how to deal with the many packages which have signed sources. Personally, I recommend setting your gpg.conf to "keyserver-options auto-key-retrieve". Is it worth lessening the security for *everyone*, in order to cater to the minority of people using a security application who do not know enough to apply this onetime solution? If so, a better approach would be to leave a pinned comment explaining what they should do. :p

oconnor663 commented on 2017-07-21 17:18 (UTC) (edited on 2017-07-21 18:11 (UTC) by oconnor663)

Good catch, thanks Mark! Fix will go out in the next build.

mpcsh commented on 2017-07-21 15:49 (UTC)

@oconnor663 there's a missing dependency - on a fresh arch install with just bspwm and a terminal, I get: ```bash mpcsh at alpamayo in ~/dotfiles on master » /opt/keybase/Keybase /opt/keybase/Keybase: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory ``` The fix is that I didn't have gtk2 installed - none of the other packages I have pulled it in as a dependency, so keybase-bin should probably depend on gtk2.

oconnor663 commented on 2017-07-20 04:44 (UTC)

This package is updated when we publish our Debian and RPM binary releases, and in fact it works by extracting binaries from the .deb. It's built from our master branches, with the caveat that we only ship builds that pass our CI tests. We really don't have a concept of "stable" beyond that.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »