Search Criteria
Package Details: keybase-bin 6.4.0_20240821175720+3212f60cc5-1
Package Actions
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) |
Dependencies (4)
- fuse (fuse2)
- gtk3 (gtk3-no_deadkeys_underlineAUR, gtk3-classicAUR, gtk3-classic-xfceAUR, gtk3-patched-filechooser-icon-viewAUR)
- libxss
- lsof (lsof-gitAUR)
Required by (5)
- kbfs (requires keybase)
- keybase (requires kbfs) (optional)
- keybase-bash-completion-git (requires keybase)
- keybase-gui (requires kbfs)
- keybase-gui (requires keybase)
Latest Comments
« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »
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)
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.
« First ‹ Previous 1 2 3 4 5 6 7 8 9 Next › Last »