Package Details: keybase-bin 6.2.8_20240306193933+e38523abbe-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: 145
Popularity: 0.003891
First Submitted: 2016-06-22 16:52 (UTC)
Last Updated: 2024-03-06 19:51 (UTC)

Latest Comments

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

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.

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