Package Details: keybase-bin 1.0.29_20170818161957+4d0259c85-1

Git Clone URL: (read-only)
Package Base: keybase-bin
Description: the Keybase Go client, filesystem, and GUI
Upstream URL:
Licenses: BSD
Conflicts: keybase, keybase-git, keybase-release
Submitter: oconnor663
Maintainer: oconnor663 (keybase)
Last Packager: keybase
Votes: 54
Popularity: 4.092816
First Submitted: 2016-06-22 16:52
Last Updated: 2017-08-18 16:29

Latest Comments

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

oconnor663 commented on 2017-07-25 19:28

@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 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 We're getting into "trusting trust" territory.

[Maybe more realistic than any of that, if 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.]

All comments