Package Details: keybase-bin 5.9.3_20220216215910+c82d65a685-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: 146
Popularity: 0.169295
First Submitted: 2016-06-22 16:52 (UTC)
Last Updated: 2022-02-16 22:22 (UTC)

Latest Comments

evybongers commented on 2022-01-06 11:53 (UTC)

@wget I just opened https://github.com/keybase/client/pull/24778 to have the dependencies updated.

wget commented on 2020-11-17 10:59 (UTC)

@keybase @oconnor663 would you mind patching this PKGBUILD to pull gtk3 dependencies instead since this commit is now merged for a bunch of time now? Thanks :)

oconnor663 commented on 2020-04-22 19:04 (UTC)

@milouse @zwork I've opened https://github.com/keybase/client/pull/23909.

zwork commented on 2020-04-21 02:24 (UTC)

I think the gconf requirement for this package ought to be removed, would that be possible?

milouse commented on 2020-01-07 12:17 (UTC)

I just checked today, I can confirm that this package run as expected without the gconf dependency. I cannot test further without the gtk2 deps, because it's still required by some other stuff on my machine.

eschwartz commented on 2019-08-16 19:18 (UTC)

It's unlikely to find desktop systems without gtk3 installed, which is I guess the only reason why this gtk3-using package which has a dependency on gtk2, works. Clearly, no one has kept track of what system dependencies are used by the mysterious thirdparty electron binary included verbatim in the package "because electron as a GUI programming paradigm". :p

(Once again, this is why I like using system electron.)

eschwartz commented on 2019-08-16 19:14 (UTC)

That should probably be revisited, then.

$ pkg-list-linked-libraries ./keybase-bin-4.3.1_20190813132700+6f497ec371-1-x86_64.pkg.tar.xz
==> checking linked libraries for keybase-bin-4.3.1_20190813132700+6f497ec371-1-x86_64.pkg.tar.xz ...
/opt/keybase/chrome-sandbox
  NEEDED               libpthread.so.0
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
/opt/keybase/Keybase
  NEEDED               libffmpeg.so
  NEEDED               libdl.so.2
  NEEDED               libpthread.so.0
  NEEDED               librt.so.1
  NEEDED               libgobject-2.0.so.0
  NEEDED               libglib-2.0.so.0
  NEEDED               libgio-2.0.so.0
  NEEDED               libnss3.so
  NEEDED               libnssutil3.so
  NEEDED               libsmime3.so
  NEEDED               libnspr4.so
  NEEDED               libgdk_pixbuf-2.0.so.0
  NEEDED               libgtk-3.so.0
  NEEDED               libgdk-3.so.0
  NEEDED               libpangocairo-1.0.so.0
  NEEDED               libpango-1.0.so.0
  NEEDED               libatk-1.0.so.0
  NEEDED               libcairo.so.2
  NEEDED               libdbus-1.so.3
  NEEDED               libXext.so.6
  NEEDED               libX11.so.6
  NEEDED               libXcomposite.so.1
  NEEDED               libXrender.so.1
  NEEDED               libX11-xcb.so.1
  NEEDED               libxcb.so.1
  NEEDED               libXcursor.so.1
  NEEDED               libXdamage.so.1
  NEEDED               libXfixes.so.3
  NEEDED               libXi.so.6
  NEEDED               libXtst.so.6
  NEEDED               libexpat.so.1
  NEEDED               libuuid.so.1
  NEEDED               libXrandr.so.2
  NEEDED               libXss.so.1
  NEEDED               libasound.so.2
  NEEDED               libatk-bridge-2.0.so.0
  NEEDED               libatspi.so.0
  NEEDED               libcups.so.2
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
  NEEDED               ld-linux-x86-64.so.2
/opt/keybase/libEGL.so
  NEEDED               libdl.so.2
  NEEDED               libpthread.so.0
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
/opt/keybase/libffmpeg.so
  NEEDED               libpthread.so.0
  NEEDED               librt.so.1
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
/opt/keybase/libGLESv2.so
  NEEDED               libdl.so.2
  NEEDED               libpthread.so.0
  NEEDED               librt.so.1
  NEEDED               libX11.so.6
  NEEDED               libxcb.so.1
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
  NEEDED               ld-linux-x86-64.so.2
/opt/keybase/swiftshader/libEGL.so
  NEEDED               libdl.so.2
  NEEDED               libpthread.so.0
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
/opt/keybase/swiftshader/libGLESv2.so
  NEEDED               libdl.so.2
  NEEDED               libpthread.so.0
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
  NEEDED               ld-linux-x86-64.so.2
/usr/bin/git-remote-keybase
  NEEDED               libresolv.so.2
  NEEDED               libpthread.so.0
  NEEDED               libdl.so.2
  NEEDED               libc.so.6
/usr/bin/kbfsfuse
  NEEDED               libpthread.so.0
  NEEDED               libresolv.so.2
  NEEDED               libdl.so.2
  NEEDED               libc.so.6
/usr/bin/kbnm
  NEEDED               libpthread.so.0
  NEEDED               libc.so.6
/usr/bin/keybase
  NEEDED               libresolv.so.2
  NEEDED               libpthread.so.0
  NEEDED               libdl.so.2
  NEEDED               libc.so.6
/usr/bin/keybase-redirector
  NEEDED               libpthread.so.0
  NEEDED               libc.so.6

oconnor663 commented on 2019-08-16 18:28 (UTC)

@ava1ar see https://github.com/keybase/client/issues/7866

ava1ar commented on 2019-08-16 03:56 (UTC)

Why does it depend on gconf?

keybase commented on 2019-01-25 16:38 (UTC)

@securetodeath

Fixed.

securetodeath commented on 2018-10-27 13:05 (UTC)

Why isn't the source just https://prerelease.keybase.io/linux_binaries/deb* ?

oconnor663 commented on 2018-08-17 14:09 (UTC)

Today's glibc update included the fix for this issue. Thanks @nallekarhu and @Eschwartz for finding it.

oconnor663 commented on 2018-08-14 21:08 (UTC)

The testing version of the glibc package (https://www.archlinux.org/packages/testing/x86_64/glibc/) contains a temporary patch to mitigate this (https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/glibc&id=f2aaaac68876f6959c62ea09dcdda5d441bf4ff7). As soon as that lands we should be good.

dstokes commented on 2018-08-14 20:24 (UTC) (edited on 2018-08-14 20:26 (UTC) by dstokes)

You can patch the binary with glibc-2.27 as a workaround.

https://archive.archlinux.org/packages/g/glibc/glibc-2.27-3-x86_64.pkg.tar.xz

mkdir /opt/glibc-2.27
sudo tar xf /var/cache/pacman/pkg/glibc-2.27-3-x86_64.pkg.tar.xz -C /opt/glibc-2.27

sudo patchelf --set-interpreter /opt/glibc-2.27/usr/lib/ld-linux-x86-64.so.2 --set-rpath \$ORIGIN:\$ORIGIN/lib/:/opt/glibc-2.27/usr/lib/ /opt/keybase/Keybase

dmp1ce commented on 2018-08-14 17:57 (UTC)

I'm experiencing the same issue with the GUI not showing. electron /opt/keybase/resources/app/ works for me.

oconnor663 commented on 2018-08-07 22:19 (UTC)

@Eschwartz thank you so much for all the work you do around these packages. (@nallekarhu you were totally right.) I'm away from work for a few months, so my response times are longer than usual on issues like this.

electron /opt/keybase/resources/app/ seems like the workaround until https://bugs.archlinux.org/task/59550 is fixed. In the longer term, I agree with @Eschwartz that depending on system electron is the right play. (One of the frustrations there is that distros other than Arch will probably still need to ship the electron binaries, since we can't depend on their system packages being recent enough.)

eschwartz commented on 2018-08-07 18:13 (UTC)

Okay, the problem is that using prebuilt electron binaries is somehow breaking since the glibc 2.28 update. See https://bugs.archlinux.org/task/59550

Also if you use the keybase-gui package I maintain in [community] you will not have this issue (although you might have other issues like https://github.com/keybase/kbfs/issues/1655 which I have submitted pull requests to fix, but without luck).

vendion commented on 2018-08-07 18:10 (UTC)

I'm running into this issue as well, I've even tried reinstalling the electron package with pacman then rebuilding and installing this package.

Running /opt/keybase/Keybase results in a seg fault whereas electron /opt/keybase/resources/app/ works

eschwartz commented on 2018-08-07 17:22 (UTC)

Can you try running both:

/opt/keybase/Keybase

and

pacman -S --needed electron
electron /opt/keybase/resources/app/

nallekarhu commented on 2018-08-07 05:58 (UTC) (edited on 2018-08-07 06:10 (UTC) by nallekarhu)

@oconnor663 the problem started right after updating to linux 4.17.12-arch1-1 this morning. We actually have two computers with linux 4.17.12-arch1-1 having the problem and a third Arch still with linux 4.17.11-1 that shows no problems. But I filed a bug with Keybase on Github nevertheless.

oconnor663 commented on 2018-08-07 04:31 (UTC)

@nallekarhu that might not be Arch specific. Could you file a bug with the regular Keybase project please?

nallekarhu commented on 2018-08-06 23:51 (UTC)

Keybase is running, but can't start gui. I see errors in journalctl: [ERRO keybase main.go:90] 001 dial unix /run/user/1000/keybase/keybased.sock: connect: no such file or directory ... keybase.gui.service: Main process exited, code=dumped, status=11/SEGV ... keybase.gui.service: Failed with result 'core-dump' Also in dmesg: [ 662.304095] Keybase[5508]: segfault at b87650 ip 0000000000b87650 sp 00007fff392c1d18 error 15 in Keybase[200000+160c000]

oconnor663 commented on 2018-08-06 00:18 (UTC)

@badpixelbr it sounds like you did a Ctrl-C during a previous install or something like that. Probably (hopefully) not an issue specific to this package. Take a look at the solutions mentioned here: https://bbs.archlinux.org/viewtopic.php?id=220552

badpixelbr commented on 2018-08-05 20:49 (UTC)

cant update keybase. when run makepkg -sriC at the end i have:

resolving dependencies... looking for conflicting packages... warning: could not fully load metadata for package keybase-bin-2.5.0_20180803162902+dee7010d7a-1 error: failed to prepare transaction (invalid or corrupted package) ==> WARNING: Failed to install built package(s).

and previous instalation cant work after try to update. after i remove keybase package and try to install again i have the same error.

axionl commented on 2018-05-30 00:50 (UTC)

keybase-bin E: Missing custom license directory (usr/share/licenses/keybase-bin)

oconnor663 commented on 2018-03-04 20:05 (UTC)

We're working on replacing the "mount helper" entirely with a small root process that will serve symlinks pointing to a user-specific mount under your homedir. That should both avoid some security issues and support the "multiple users on the same system" case properly for the first time. So in short, all of this stuff is in flux. (Folks who prefer to disable all of this, see https://github.com/keybase/client/pull/10724.)

eschwartz commented on 2018-03-04 00:10 (UTC)

@eduard, see https://github.com/keybase/client/issues/10487 and note that the latest git version of keybase will "fix" this by simply running the mount helper as SUID root.

eduard commented on 2018-03-03 07:46 (UTC)

/usr/bin/run_keybase: line 121: 4298 Segmentation fault keybase-mount-helper -user-mount "$mountdir"

gdamjan commented on 2018-02-25 18:03 (UTC)

@Eschwartz I agree completely with you.

eschwartz commented on 2018-02-25 17:53 (UTC) (edited on 2018-02-25 20:37 (UTC) by eschwartz)

Currently /keybase is just a pointless symlink to /var/lib/keybase/mount1 which is itself a pointless symlink to ~/.local/share/keybase/fs for the first user account on the computer that used keybase.

This obviously requires something to perform the symlinking. The keybasehelper user and suid binary manage this to ensure that /keybase remains a symlink to wherever your kbfs mountpoint is truly located. This achieves no goal other than to ensure that people can reference /keybase and the filepath will work everywhere... assuming that by everywhere you mean on single-user systems...

So:

1) it doesn't even really work entirely, and maintaining this legacy symlink is inferior to simply using the correct location.

2) It requires having yet another /etc/passwd entry, and on top of that requires running a suid binary -- which is admittedly not so bad considering that it only runs as a restricted user account. https://github.com/keybase/client/pull/10250 Now instead of a world-writable mountpoint directory in root, there is a symlink in root to a symlink owned by a suid binary that points to a mountpoint.

Since I'm the one who is packaging the community package, I'm the one who gets to say I won't implement this, and people should just join the future and use ~/.local/share/keybase/fs or configure their own mountdir via keybase config. ;)

gdamjan commented on 2018-02-25 17:30 (UTC)

What exactly is "suid-keybasehelper-and-extra-system-user shenanigans"?

setting homedir as / for a uid that doesn't do much, is fine

eschwartz commented on 2018-02-23 19:22 (UTC)

FWIW I've just updated keybase and added a new kbfs package in [community].

I'm not doing this suid-keybasehelper-and-extra-system-user shenanigans though, so if you use the community packages you'll just have to use ~/.local/share/keybase/fs or set the configuration yourself. ;)

eschwartz commented on 2018-02-23 17:42 (UTC)

No, they are using systemd-sysusers actually...

oconnor663 commented on 2018-02-23 17:11 (UTC)

@gdamjan thanks for pointing that out. It looks like what other services are doing is setting their users' homedirs to /. Does that sound right to you?

gdamjan commented on 2018-02-23 11:52 (UTC)

sudo /usr/bin/pwck -r

user 'keybasehelper': directory '/home/keybasehelper' does not exist

eschwartz commented on 2018-02-22 18:14 (UTC)

Currently /keybase is just a pointless symlink to /var/lib/keybase/mount1 which is itself a pointless symlink to ~/.local/share/keybase/fs for the first user account on the computer that used keybase.

It would make far, far more sense to simply drop the directory altogether. But the keybase developers do not want to break the expectations of people who expected to see /keybase and therefore any replacement at all would be rejected on the grounds that it, well, isn't /keybase.

gdamjan commented on 2018-02-22 18:10 (UTC)

@milouse it's probably better to put the path under /run/user/1000 ie. $XDG_RUNTIME_DIR

@oconnor663

jangho commented on 2018-01-27 02:13 (UTC) (edited on 2018-01-27 03:12 (UTC) by jangho)

PKGBUILD for keybase-bin-1.0.40_20180127012637+2887fffa7 seems to have a problem. The variable ${src_prefix} was used before it was defined.

Update: Fixed via https://github.com/keybase/client/pull/10363

oconnor663 commented on 2018-01-24 19:39 (UTC)

The "prerelease.keybase.io" domain is indeed a bit of legacy in our packaging layout that we haven't gone back to clean up yet.

noirbizarre commented on 2018-01-21 11:15 (UTC)

No offenses, it was just a suggestion.

It make sense when you know the process, but from a end user point of view the fact that binaries are updated on a daily basis is not documented anywhere, the only reference to versioning is the releases/tags on the github repository. There is also no "current release" reference on the keybase website, only install sections and link to the github repository. Another thing which mislead me: the binaries are downloaded from prerelease.keybase.io (which is also the case on the keybase website): I think this is why many of us where not understanding the releases flow and asked for stable releases (until now I was just thinking the website was outdated and still linking to prereleases)

eschwartz commented on 2018-01-21 00:31 (UTC) (edited on 2018-01-21 00:33 (UTC) by eschwartz)

This bin package is being updated by the upstream keybase release process, to correspond to the latest bin uploaded by the keybase team. It is therefore fulfilling the duty of all bin packages, to track, not "stable versions", but "binary releases from upstream". Which are not marked as betas or alphas or even RCs.

I am assuming for the sake of my sanity, that the keybase team are publishing the bin snapshots when they feel it is stable enough to, you know, publish as the official snapshots for all Debian and Fedora users ever. Given which, it seems to make sense to publish that as the unified release to all Linux platforms, including Arch Linux.

It is, after all, additionally linked and updated as the "current release" on the official website.

Speaking with my official TU hat on, I see no reason to get on their cases about this. In fact, if I were the package maintainer, I would endeavor to update just as frequently to the latest version being encouraged by upstream's primary download page...

noirbizarre commented on 2018-01-20 10:50 (UTC)

I was going to suggest the same thing. The practice on packages is to have: - xxxx: src package tracking stable versions - xxxx-bin: binary package tracking stable versions - xxxx-git: src package updated regulary to track the master changes In your case, keybase is already taken, so maybe just: - keybase-bin tracking stable versions - keybase-git tracking master on daily basis

aytekinar commented on 2018-01-18 09:36 (UTC)

I agree with @jemadux. Is there any chance to track only the stable versions, i.e., the tagged versions on GitHub? Right now, I feel that we are tracking the master, and I would not like to install all the new hashes.

I am not sure if that is possible at all, but could we set up keybase-git to track master and keybase-bin to track only the tagged versions (v1.0.39 as of January 18, 2018)?

oconnor663 commented on 2017-12-01 19:57 (UTC)

This package is always updated to the latest released Keybase version, and so far we've been publishing new Keybase versions daily on Linux. We could define a separate package that we only update on Mondays, or something like that, but so far slowing down updates just for the sake of slowing them down has seemed not worth it?

jemadux commented on 2017-12-01 19:05 (UTC)

why every time new update ?

yan12125 commented on 2017-11-23 18:09 (UTC)

@oconnor663: Thanks for pointing out the correct place. I've opened https://github.com/keybase/client/issues/9671.

oconnor663 commented on 2017-11-23 15:38 (UTC) (edited on 2017-11-23 15:38 (UTC) by oconnor663)

There's a discussion of signature checking below. Look for the comment containing the line "I worry the (small but non-zero) usability downsides of sig checking outweigh the (possibly actually zero) security benefits." If you want to discuss it more, it might be easier to file an issue in the upstream GitHub repo and tag @oconnor663.

yan12125 commented on 2017-11-23 15:30 (UTC)

+1 for verifying pgp signatures!

emlun commented on 2017-11-22 12:08 (UTC)

I suggest the following patch for enabling PGP signature checking. diff --git a/PKGBUILD b/PKGBUILD index 5fda4e1..56a3da9 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -18,10 +18,13 @@ depends=(fuse gconf libxss gtk2) # don't change this without changing the SRCINF conflicts=(keybase keybase-release keybase-git) source_i686=( "https://s3.amazonaws.com/prerelease.keybase.io/linux_binaries/deb/keybase_${deb_pkgver}_i386.deb" + "https://s3.amazonaws.com/prerelease.keybase.io/linux_binaries/deb/keybase_${deb_pkgver}_i386.deb.sig" ) source_x86_64=( "https://s3.amazonaws.com/prerelease.keybase.io/linux_binaries/deb/keybase_${deb_pkgver}_amd64.deb" + "https://s3.amazonaws.com/prerelease.keybase.io/linux_binaries/deb/keybase_${deb_pkgver}_amd64.deb.sig" ) +validpgpkeys=(222B85B0F90BE2D24CFEB93F47484E50656D16C7) install=keybase.install package() { @@ -43,5 +46,5 @@ package() { rm -rf "$pkgdir/etc/cron.daily" } -sha256sums_i686=(994998f8093474330a1249e75963cacc948b8011ef5dff6e2e98085fa58448ba) -sha256sums_x86_64=(35bd09c324828c125ecb68e83b3c54a36f8c48d61b09352593a62d64476f2802) +sha256sums_i686=(994998f8093474330a1249e75963cacc948b8011ef5dff6e2e98085fa58448ba 'SKIP') +sha256sums_x86_64=(35bd09c324828c125ecb68e83b3c54a36f8c48d61b09352593a62d64476f2802 'SKIP')

oconnor663 commented on 2017-09-19 14:34 (UTC)

@Eschwartz we should be hosting .sig files next to every new build file, including the older-than-most-recent ones, starting today.

oconnor663 commented on 2017-09-05 15:06 (UTC)

The /keybase path is deliberate, to make it possible for filepaths to be portable to other systems. (For example, /keybase/public/oconnor663/id_rsa.pub.) It's possible to use a ~ to almost get the same effect, but there are many contexts where that doesn't work. It's a cool patch though, for sure. Power users who want that kind of control will appreciate it.

milouse commented on 2017-09-05 09:23 (UTC) (edited on 2017-09-05 09:28 (UTC) by milouse)

Hi! I've just written a little patch, which relocate /keybase inside the user $HOME directory instead of at the root of the file system (https://milouse.keybase.pub/). Is it something you may add to your pkgbuild or no ?

oconnor663 commented on 2017-08-17 17:41 (UTC)

As Eschwartz mentioned, that would be pretty nonstandard for an Arch package. For example, wiki instructions for installing a service usually have at least two separate steps: 1) pacman -S ${something}, 2) systemctl enable ${something}. Even if we didn't want to follow the Arch convention there, though, an extra hurdle for the Keybase package is that we need to run as your regular user, not as root. We'd have to figure out what user you *were* before you ran `sudo` or whatever, which isn't always possible.

eschwartz commented on 2017-08-17 17:18 (UTC)

That would be silly, since since it starts it irrespective of whether it had been previously running. Also it is gross and against Arch packaging policy.

Redrield commented on 2017-08-17 17:14 (UTC)

Would you be able to add `run_keybase` to post_install/post_upgrade so that we don't need to do it after every update?

Redrield commented on 2017-08-17 17:14 (UTC)

Would you be able to add `run_keybase` to post_install/post_upgrade so that we don't need to do it after every update?

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.

dakra commented on 2017-07-20 02:48 (UTC)

Why is this package updating almost every day? Feels like a `-git` version. Is there another, more "stable" version I could use?

oconnor663 commented on 2017-07-08 18:53 (UTC)

@ShionRyuu I'm not able to repro when reinstalling `keybase-bin` just now. Could you please file an issue at github.com/keybase/client with as many details as possible about your system?

ShionRyuu commented on 2017-07-08 16:00 (UTC)

build fail ```shell $ yaourt -s keybase-bin ... ==> Continue installing keybase-bin ? [Y/n] ==> [v]iew package contents [c]heck package with namcap ==> --------------------------------------------------- ==> c keybase-bin E: ELF file ('opt/keybase/libffmpeg.so') outside of a valid path. keybase-bin E: ELF file ('opt/keybase/Keybase') outside of a valid path. keybase-bin E: ELF file ('opt/keybase/libnode.so') outside of a valid path. keybase-bin W: ELF file ('opt/keybase/Keybase') has executable stack. keybase-bin E: Missing custom license directory (usr/share/licenses/keybase-bin) keybase-bin W: Referenced library 'libffmpeg.so' is an uninstalled dependency keybase-bin W: Referenced library 'libnode.so' is an uninstalled dependency keybase-bin W: Unused shared library '/usr/lib/libcups.so.2' by file ('opt/keybase/Keybase') keybase-bin E: Dependency gtk2 detected and not included (libraries ['usr/lib/libgdk-x11-2.0.so.0', 'usr/lib/libgtk-x11-2.0.so.0'] needed in files ['opt/keybase/Keybase']) keybase-bin E: Dependency libxtst detected and not included (libraries ['usr/lib/libXtst.so.6'] needed in files ['opt/keybase/Keybase']) keybase-bin E: Dependency nss detected and not included (libraries ['usr/lib/libsmime3.so', 'usr/lib/libnssutil3.so', 'usr/lib/libnss3.so'] needed in files ['opt/keybase/Keybase']) keybase-bin E: Dependency alsa-lib detected and not included (libraries ['usr/lib/libasound.so.2'] needed in files ['opt/keybase/Keybase']) keybase-bin W: Dependency included and not needed ('fuse') ```

oconnor663 commented on 2017-02-21 19:57 (UTC)

@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.

dbrgn commented on 2017-02-21 09:11 (UTC)

GPG signatures for the Debian packages are now available! https://keybase.io/docs/the_app/install_linux Would be great if these could be checked on install.

oconnor663 commented on 2017-02-14 18:44 (UTC)

Confirmed, will fix. Thanks for catching that.

DriverChief commented on 2017-02-14 01:18 (UTC)

I was missing libxss to get the GUI running. Maybe that should be an optional dependancy?

oconnor663 commented on 2017-02-08 23:07 (UTC)

@ethanmad could you please file a bug at https://github.com/keybase/client/issues, tag @oconnor663 in it, and include the log id from `keybase log send`?

ethanmad commented on 2017-02-08 21:53 (UTC) (edited on 2017-02-08 22:03 (UTC) by ethanmad)

Getting problems with chat: ``` Error: KBFS client wasn't found at t (file:///opt/keybase/resources/app/desktop/dist/index.bundle.js:15:31264) at new t (file:///opt/keybase/resources/app/desktop/dist/index.bundle.js:16:80) at s (file:///opt/keybase/resources/app/desktop/dist/index.bundle.js:15:31660) at i (file:///opt/keybase/resources/app/desktop/dist/index.bundle.js:15:31588) at file:///opt/keybase/resources/app/desktop/dist/index.bundle.js:12:14327 at file:///opt/keybase/resources/app/desktop/dist/index.bundle.js:78:27307 at e.t.Deferrals.e._call (file:///opt/keybase/resources/app/desktop/dist/index.bundle.js:56:29476) at file:///opt/keybase/resources/app/desktop/dist/index.bundle.js:56:29627 at c (file:///opt/keybase/resources/app/desktop/dist/index.bundle.js:56:29254) at e.t.Deferrals.e._fulfill (file:///opt/keybase/resources/app/desktop/dist/index.bundle.js:56:29586). ``` From CLI, `keybase chat send $username "testing keybase chat"` gives `▶ ERROR failed to open chat conversation: KBFS client wasn't found`. Furthermore, `/keybase/public/ethanmad/` is not a directory I can cd to.

oconnor663 commented on 2016-09-25 17:10 (UTC)

@earfolds this package includes the KBFS bits, which more or less require the GUI to work properly. We might define a separate package in the future that's command-line-only though.

earfolds commented on 2016-09-24 18:29 (UTC)

I think GTK2 might be an optional dependency. The GUI doesn't seem to load if I don't have it installed.

chungy commented on 2016-06-29 22:05 (UTC)

Thank you for this, very much. Building it from source takes over an hour on my machine. :)