#KEYBASE API UPDATE#

(The 2.3 failure was a simple type error.) Second problem: testing the CLI # run tests as normal, assuming a real Keybase installation $ rake test # run tests with Keybase stubs $ TEST_NO_KEYBASE =1 rake testīoth of these were placed under the make test target, to prevent me from accidentally introducingĬhanges that broke one or the other while developing locally. Thus, there were two ways to run the unit tests: I completed my first version of this on August 1, and you can (testing for a keybase process or similar) Avoid require-ing any KBSecret or Keybase files that would throw exceptions on load.Stub out calls like Keybase.current_user with 'dummy'.Create a temporary directory somewhere and pretend it’s the KBFS mount.Check for the presence of TEST_NO_KEYBASE in the environment, and….At a high level, the stubbing looked like My first approach to running the KBSecret tests on a CI was to abandon Keybase entirely, andĪttempt to stub a subset of Keybase functionality 2. Auto-generated coverage reports are also nice, as they provide a Impossible to forget to run your tests, 1 and they give new contributors immediate and automatedįeedback on their changes. However, I really like farming out the work of testing to a CI service - CIs make it I canĪutomate the suspension of my own (real) KBSecret state, and I certainly have Keybase and KBFS The current KBSecret state won’t interfere with or clobber the unit testsĪs a developer testing on my own system, these are mostly reasonable assumptions to make.KBFS is running and mounted, ideally at /keybase.A Keybase user is logged in with a valid session.Since KBSecret integrates tightly with Keybase and KBFS, its unit tests need to make severalĪssumptions about the test host in order to do any meaningful testing: Both the API and CLI have unit tests to prevent regressions and provide a semi-rigorous It exposes both a public API (in Ruby, of course) and a well-featured CLI via the kbsecretĬommand. KBSecret is written in Ruby and interacts with Keybase through a I maintain an open source secret manager, KBSecret, that uses KeybaseĪnd the Keybase filesystem (KBFS) for encryption and synchronization. Half dozen other people running Keybase in a CI setting. This is a post-mortem analysis of my work on getting the keybase help oneshot has all of the details, and you can find an example of it in use

#KEYBASE API UPDATE#

Update (5/16/18): Much of the information below is now obsolete, thanks to the new keybase oneshotĬommand. You can find the recent changes for the extension in the history of the 'browser' directory.Keybase on the CI ENOSUCHBLOG Programming, philosophy, pedaling. Keybase is open source, and so is this extension: This is end-to-end encryption, powered by the convenience of public social media usernames.

Toggle specific features in the extension options (chrome://extensions/ and click on 'options')Īt no point in Keybase's protocol does Keybase ever have the keys necessary to read your messages.

Look for the 'Keybase Chat' button on profiles around the web.No one (at Keybase or the social networks) can read your private exchanges.You don't need to know the recipient's email address or phone number or Keybase username-just a social media username is enough.Everyone with a social network account has a Keybase inbox, *even before they join Keybase*.This works even if they have yet to join Keybase. It's an easier chat, and it's end-to-end encrypted. Keybase for Chrome is an official Keybase extension for composing ENCRYPTED messages to any Twitter, Facebook, Reddit, HackerNews, or Github user, from the convenience of your browser.

Keybase api