Package Details: keybase-bin 1.0.34_20171018161310+ca1f3168a-1

Git Clone URL: https://aur.archlinux.org/keybase-bin.git (read-only)
Package Base: keybase-bin
Description: the Keybase Go client, filesystem, and GUI
Upstream URL: https://keybase.io
Licenses: BSD
Conflicts: keybase, keybase-git, keybase-release
Submitter: oconnor663
Maintainer: oconnor663 (keybase)
Last Packager: keybase
Votes: 67
Popularity: 9.814829
First Submitted: 2016-06-22 16:52
Last Updated: 2017-10-18 16:23

Latest Comments

oconnor663 commented on 2017-09-19 14:34

@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

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

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

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

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

@Eschwartz done.

All comments