Use Case For Developers - Storing and Sharing Credentials

[solvingj]

I'm novice and new to keybase, but I have seen a common problem I'm hoping Keybase could potentially solve.

Many integration tests require credentials like connection strings to be used during development on many different developer machines. Some credentials are user-specific, others are shared. Many teams have many methods for sharing these, few of which are ideal, almost none of which are encrypted end to end.

Is it possible to have an effective workflow using Keybase where: -Each developer has a standard file or location for personal test credentials -Teams can have a standard file or location for shared test credentials

[zQueal]

Yes to both. Specifically leveraging KBFS private folders would be helpful here.

Let's say you have a team of 6 developers, Dev{A,B,C,D,E,F} and three developer keys, Key{1,2,3}, which needs to be shared between developers. Dev{A,B} need Key1, Dev{C,D} need Key2, and Dev{E,F} need Key3. Just make the folder structure below in the ~/private/ folder subtree;

• DevA,DevB -> Key1.asc
• DevC,DevD -> Key2.asc
• DevE,DevF -> Key3.asc

You can also do more than two users per folder;

• DevA,DevB,DevC -> Key1.asc
• DevD,DevE,DevF -> Key2.asc
• Key3.asc (backup)

I still don't recommend storing an access key in plain text--but this method would be far better than any method their currently using because it's entirely end-to-end and encrypted with their personal PGP keys.

[solvingj]

So I started naming folders this way and a big problem jumped out: adding someone to an existing folder means renaming, is that right? If so that invalidates anything I specified the path for. The path is coupled to the membership, doesn't seem remotely practical (unless I'm missing something which is possible).

Sent from my iPhone

On Jan 28, 2017, at 3:12 PM, Zach Queal notifications@github.com wrote:

Yes to both. Specifically leveraging KBFS private folders would be helpful here.

Let's say you have a team of 6 developers, Dev{A,B,C,D,E,F} and three developer keys, Key{1,2,3}, which needs to be shared between developers. Dev{A,B} need Key1, Dev{C,D} need Key2, and Dev{E,F} need Key3. Just make the folder structure below in the ~/private/ folder subtree;

DevA,DevB -> Key1.asc DevC,DevD -> Key2.asc DevE,DevF -> Key3.asc You can also do more than two users per folder;

DevA,DevB,DevC -> Key1.asc DevD,DevE,DevF -> Key2.asc Key3.asc (backup) I still don't recommend storing an access key in plain text--but this method would be far better than any method their currently using because it's entirely end-to-end and encrypted with their personal PGP keys.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[strib]

We will eventually support having group names as folder names, so you won't have to rename, but we don't yet, sorry. But, you can always make a new folder with the new set of people, and symlink the old files into the new folder (for Linux/macOS users, anyway).

because it's entirely end-to-end and encrypted with their personal PGP keys.

KBFS data is encrypted for each user's NaCL device keys, not PGP. Of course you can always PGP-encrypt it yourself before putting it in KBFS, if you want.

[solvingj]

Is it correct to say that Keybase is unique in the way that an owner can add other people's public keys to an encrypted file and effectively grant them permission to it? And the owner can also remove a key from such a file and revoke that persons access, is that also correct? Sorry, I'm still struggling to grasp some of the concepts, as the diagram here doesn't provide much context as to what the graph relationships signify. Perhaps to people who understand encryption better it's obvious.

https://keybase.io/blog/keybase-new-key-model

Edit: I see now that GPG does support encrypting a file for multiple recipients.