Add SPEC 6: Keys to the Castle #168
Conversation
tupui
left a comment
There was a problem hiding this comment.
Good idea 👍 I have some suggestions.
|
In general I think this is a good SPEC. For mybinder.org we have been doing essentially this using One "big picture" thing I wanted to point out, despite not having a good solution, is that command line tools like gopass and git-crypt don't have the same UX comfort factor as something with a GUI. Especially for people who don't spend all day using the terminal. This means for people like that you need to spend more time helping them, increase the chances of them storing the passwords in an additional location that is easier to access, increase the chance of being turned off because the friction is too high, etc. So I wonder if there is a tool that has a nice GUI that can be recommended. Or if there are password vault services that offer a free tier that allows sharing. In the past Keybase had a "not terrible" UX but their funding situation changed a few years ago (I think got bought by Zoom), which is a bit of a turn off. I don't think Firefox's password vault supports sharing, but maybe there is something to explore there (with Mozilla)? |
|
Good points 👍 AFAIK there are 2 viable options (OSS you can self-host) in terms of UI with sharing features (things like keepass are great for local use but not much for working with a team): Bitwarden and passbolt. In both cases, the difficulty will be trust. Either you trust their system and use their tiers (possible for big projects as we have funds), or you self-host. But unless you have a security expert in the team, I would personally have reservations. For some reason, we are not so much targeted by hackers yet. But once they realise we would be a great vector of attack, things would drastically change. So far it's just typo squatting and a bit of malware sharing on PyPi. But they could very easily target people with credentials to ship compromised binaries... And that's only the the easy quick thing someone could do. If you follow a bit the security and pen. test space, real life hacks are really crazy now (e.g. how they compromised LastPass.) |
|
+1 on having a more user friendly solution for sharing secrets, currently need to pass around the git-crypt one and it just doesn't seem right. It's possible to self host Bitwarden (either with the official one or vaultwarden) but even paying for Bitwarden turns out not to be super expensive (we can just use the "family" plan). Also a +1 on 2FA hardware based security key as part of the SPEC. PyPI already "forced" people to have 2FA so I think we can elevate that requirement as a SPEC. I'm not sure if conda-forge feedstocks force people to have 2FA enabled on github or not but having a general guideline like this would be great! |
|
We could probably get free accounts from Bitwarden if we pitch correctly the idea. |
|
The goal of the SPEC is to define principles, and any system that satisfies those principles is fine. We can give multiple examples. We obviously need at least one free implementation (which I provided), and self-hosting is not typically an option for most projects. In fact, most projects don't even have funds to pay for bitwarden, and the account needs to be accessible by all team members. |
@stefanv Note that https://github.com/numpy/vault is not publicly available. I don't have access to see the repo. |
|
I will write to Bitwarden to find out about community pricing. |
New link: https://github.com/scientific-python/vault-template |
So that goes from 3 USD per user per month to 2.25 per user per month, or 135 USD per year for a core team of 5. |
What I was hoping for is to get the "When setting things up, consider the UX comfort for all the different types of people involved. You don't want to create the equivalent of super-secure-password-complexity-and-rotation-rules that lead to people writing the password on a post-it stuck to the monitor". |
spec-0006/index.md
Outdated
|
|
||
| ### Alternative implementations | ||
|
|
||
| Unknown |
There was a problem hiding this comment.
I was trying to figure out some PyPI security stuff where 1password's "free team for open source" was recommended. It looks like it's quite popular with some large projects like: numfocus, jupyter, Python Software Foundation Infrastructure Team, and Rust.
https://github.com/1Password/1password-teams-open-source
I think a big advantage here is access controls, which I'm not sure you can get for free with bitwarden.
There was a problem hiding this comment.
oh thanks for sharing that! I even see Kali in the list. If that's not a good sign, I don't know what would be 😅
There was a problem hiding this comment.
Actually I just heard that NumFOCUS provide team accounts for affiliated projects.
There was a problem hiding this comment.
The NumFOCUS folks just point you to that 1Password page 😅 but yes, we are using 1Password for Teams for Open Source for napari and it was a smooth process.
There was a problem hiding this comment.
Oh really? I heard a different story from another project. That would be a bit underwhelming but ok still nice to have a central place saying what exists and is possible to do.
There was a problem hiding this comment.
@jni, could you add all the core devs to the team? It's been a little unclear to me if the team accounts were capped at 10.
There was a problem hiding this comment.
Well, not all 14 core devs have asked for invites so we haven't tested that hypothesis yet 😂 , but nothing in the process suggested that limit. They explicitly add for the number of core contributors in the PR template, so I presume that's the limit they set? But probably can be expanded?
There was a problem hiding this comment.
This is a great option; thanks for finding it! I've added it to the SPEC.
There was a problem hiding this comment.
1password's pricing page says the "teams" account is up to ten people, and after that it's called "business".
But not sure what this translates to for the open source projects.
|
The document has been updated with the feedback above; thanks everyone! |
|
I've widened the scope of the SPEC slightly (adding that projects should document who has access to which resources), made the note on scoped tokens / rotation more prominent, and moved the pass-based solution down as a second option. |
|
I didn't follow the entire convo so sorry if I missed it. Was https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/ considered? |
We use trusted publishing, but that doesn't alter the fact that we sometimes need to store and share credentials. |
@pllim I thought about your idea a bit more, and perhaps it's worth mentioning some of these commonly used mechanisms explicitly. I'll add a note to the PR. |
spec-0006/index.md
Outdated
|
|
||
| - **Publishing packages**: PyPi provides a [trusted publisher](https://docs.pypi.org/trusted-publishers/using-a-publisher/) mechanism for avoiding passwords | ||
|
|
||
| ### Other security considerations |
There was a problem hiding this comment.
This could also list a bullet point on what makes a secure secret in case of conventional passwords (e.g passphrases, minimal password length, etc). I imagine using the recommended password managers here, makes it easy to use long ones that don't have to be remembered and can just be copy-pasted. Or maybe just point out this fact.
Might be to detailed for the scope of this document though...
There was a problem hiding this comment.
Agreed on saying that password must be created only using generators from password managers.
|
|
||
| ## Implementation | ||
|
|
||
| ### Principles |
There was a problem hiding this comment.
Nitpick: Feels weird to me that "Principles" is in the section "Implementation". I'd make it its own level-## section after "Description" and before "Implementation".
tupui
left a comment
There was a problem hiding this comment.
I had another look 😃 I think if we want to move this forward it might be good to release. Then it will get more traction (e.g. as seen on SPEC4) and people will start to engage.
|
|
||
| It should be noted that, in many cases, secrets & passwords can be avoided. | ||
| Most online services (GitHub, PyPi, etc.), have permissioning systems through which developers can be given the required access. | ||
| Access to servers can be given through SSH keys, which each developer has to safeguard. |
There was a problem hiding this comment.
Slightly out of scope here.
"safeguard": it could read too vague. I think we need to provide some minimal recommendations like never have a ssh key without a passkey.
There was a problem hiding this comment.
Note passkeys are now an entirely new thing :)
spec-0006/index.md
Outdated
| The secrets are stored, encrypted, in a public Git repository. | ||
| The vault uses [gopass](https://github.com/gopasspw/gopass), a more user friendly implementation of [pass](https://www.passwordstore.org/), to manage access via GPG keys. | ||
| Each secret is encrypted using the public keys of all developers that should have access. | ||
| If a developer's access is removed, the vault is re-encrypted so that that developer cannot read future copies of the repository (but secrets should be considered compromised and, thus, rotated). |
There was a problem hiding this comment.
This should is also true if using other options and I think should be moved in the general section.
spec-0006/index.md
Outdated
|
|
||
| - **Publishing packages**: PyPi provides a [trusted publisher](https://docs.pypi.org/trusted-publishers/using-a-publisher/) mechanism for avoiding passwords | ||
|
|
||
| ### Other security considerations |
There was a problem hiding this comment.
Agreed on saying that password must be created only using generators from password managers.
Mention secret rotation on re-encryption of vault
jarrodmillman
left a comment
There was a problem hiding this comment.
There is a minor section rearrangement needed, but I will do that in a follow-up PR. Let's just merge this and then revise it as needed.
|
Great, and I'm happy to incorporate further suggestions. I found it quite helpful to aggregate these. |
/cc @jarrodmillman
I think the gopass implementation is user friendly enough that we can use it as an example.
Do you have any other ideas for principles the system should adhere to?