No way to verify releases.

[MicahZoltu]

I just received a prompt to update to version 2.5.2 of Keybase desktop app. Being the paranoid person I am, I went online to verify that this is a legitimate release and not someone compromising the application upgrade process. Unfortunately, I found the following:

1. The website doesn't maintain a list of versions.
2. New versions do not result in a blog post.
3. New versions are not always announced via twitter.
4. The GitHub releases page does not have the latest release version.
5. The downloads page doesn't have any links that include the version being downloaded.
6. There is no changelog in the GitHub repository.

Basically after doing a non-trivial amount of research (way more than I should have to in order to verify a new release), I have come to the conclusion that the Keybase update process has been compromised and the latest version is 2.5.0 (per GitHub releases page) and I should not apply this update.

[danschultzer]

I agree. There shouldn't be a lack of clear release information. In particular when the updater asks for root privileges.

If you dig through the keybase.updater.log you can get an idea if the release was legit. That's how I found the changelog location, the package update API endpoint, and the download url. The version (2.5.2-20180906142014+a801e75b82) matches the default dmg version pulled from their website.

It would be best if at minimum all releases are listed on either the keybase.io website or in the github repo.

Any @keybase team members who have some thoughts on this? Looks like @keybase/react-hackers gets pinged with changelog updates.

[cjb]

Hi folks -- I've pushed GitHub "releases" for 2.5.1 and 2.5.2 now. Today's release of 2.5.2 with the updater asking for root privileges is legitimate.

(As @danschultzer says, the updater hits our API endpoint over TLS with a pinned cert, and checks a Keybase signature on the download.)

[eli-schwartz]

So uh, hey, interesting. No wonder, once again, my distribution packages which build from source, are out of date by multiple invisible versions.

[eli-schwartz]

By the way, tagging the kbfs repository with three different new tags for the exact same commit, is line noise. Why am I supposed to rebuild the same code with no changes, just to change the version number?

I get that it makes sense to update the client repository with a new version, but if you're hotfixing that and not the kbfs repo, then why do you need to bump the git tag of the kbfs repo?

[strib]

By the way, tagging the kbfs repository with three different new tags for the exact same commit, is line noise. Why am I supposed to rebuild the same code with no changes, just to change the version number?

I get that it makes sense to update the client repository with a new version, but if you're hotfixing that and not the kbfs repo, then why do you need to bump the git tag of the kbfs repo?

@eli-schwartz I tag kbfs specifically for you, because you told me you wanted kbfs tags that match the client tags.

[eli-schwartz]

I want tags that match the released code, yes... in this case, I'm just not sure why you "upgraded" the version of kbfs to begin with? You released the same git commit of kbfs, for client 2.5.0, 2.5.1, and 2.5.2

[strib]

The new kbfs v2.5.2 commit is what went out in the official Keybase 2.5.2 release (along with the client 2.5.2 commit). Yes, it's the same as v2.5.0 and 2.5.1, but I assume you (and others) want to know what matches the public release.

[eli-schwartz]

Actually, huh, the client code consists only of an electron update and an OSX-specific update: https://github.com/keybase/client/commit/a801e75b82bf5f6a2f5891ef7bcc9317e7d72adb, neither of which should affect my package...

but I assume you (and others) want to know what matches the public release.

Oh, hmm. I guess this might just be, once again, down to the confusion of "what is client and what is kbfs"...

Separate repos (which I package as separate packages) would, usually, have separate release versioning even if both get updated in parallel.

Whereas you're treating them as one unified codebase.

[fortran77]

I looked for the keybase client's Help => About menu item (a de facto standard location for version information), and found no such menu item.

If your build scripts embed version information into each binary in the format $keyword: text $, the standard ident command will find them quickly.

[MrPaz]

Bump. Why are there no signature files or signed checksums for the releases?? If I'm overlooking them, please provide a link. These should be available and easily accessible on the install page of the website (https://keybase.io/download), or at an absolute minimum here on Github.

[eli-schwartz]

On the Linux download page:

If you want our code signing key, you can get it here and verify it here. Detached PGP signatures for all the package files below are available by appending .sig to the package URL, like this.

It's true this isn't the case for source tarballs, or for macOS/Windows prebuilt artifacts.

[zanderz]

There is a page with some more information, including the thumbprint of our windows codesigning key.

Not sure we're encouraging this for public consumption, but this page has links to recent builds and matching metadata files. These metadata files contain the keybase signatures used by the updater to verify updates, which you can also try yourself.