Package Details: keybase-bin 5.6.1_20210125164223+f3b21527b9-1

Git Clone URL: (read-only, click to copy)
Package Base: keybase-bin
Description: the Keybase Go client, filesystem, and GUI
Upstream URL:
Licenses: BSD
Conflicts: kbfs, keybase, keybase-git, keybase-gui, keybase-release
Provides: kbfs, keybase, keybase-gui
Submitter: oconnor663
Maintainer: oconnor663 (keybase)
Last Packager: keybase
Votes: 144
Popularity: 2.10
First Submitted: 2016-06-22 16:52
Last Updated: 2021-01-25 19:22

Latest Comments

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

milouse commented on 2017-09-05 09:23


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

oconnor663 commented on 2017-08-17 17:41

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

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

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

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

@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


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 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${deb_pkgver}_${deb_arch}.deb I can only verify it with${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

@Eschwartz done.

eschwartz commented on 2017-07-28 20:41

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

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