Who wants to keep the secrets? #34

Ghost commented 2022年11月12日 22:18:42 +01:00

Dear @codename/Owners,

We all have all the keys to everything related to codename. It's not a heavy responsibility to bear right now because ... there is not much of anything anyway 🙂

As codename is about to get a name and grows, this burden will become a little heavier as time passes. The governance will eventually establish a process for the whole community to decide who and how people should be trusted with those secrets. But for now it has to be a group of people who are willing to be careful not to leak these keys. And promise to transfert them to their successors.

If you are willing to keep the codename secrets (with 2FA activated), keep up to date with GPG key signing etc. and promise to transfert them to your successors, please say so here.

Unless there is an objection, the temporary group of "secret keepers" will be decided November 16th, 2022 based on who among the current @codename/Owners answered this call.

Cheers

Dear @codename/Owners, We all have all the keys to everything related to codename. It's not a heavy responsibility to bear right now because ... there is not much of anything anyway 🙂 As `codename` is about to get a name and grows, this burden will become a little heavier as time passes. The governance will eventually establish a process for the whole community to decide who and how people should be trusted with those secrets. But for now it has to be a group of people who are willing to be careful not to leak these keys. And promise to transfert them to their successors. **If you are willing to keep the `codename` secrets (with 2FA activated), keep up to date with GPG key signing etc. and promise to transfert them to your successors, please say so here.** Unless there is an objection, the temporary group of "secret keepers" will be decided November 16th, 2022 based on who among the current @codename/Owners answered this call. Cheers

Ghost commented 2022年11月12日 22:19:48 +01:00

I'm willing to be a member of the group keeping secrets for codename and promise to transfert those secrets to the people appointed by the future governance of codename. I have 2FA activated.

I'm willing to be a member of the group keeping secrets for codename and promise to transfert those secrets to the people appointed by the future governance of codename. I have 2FA activated.

Gusted commented 2022年11月12日 22:23:52 +01:00

I'm willing to be part of this.

I'm willing to be part of this.

Ryuno-Ki commented 2022年11月12日 22:30:01 +01:00

I lack the technical knowledge to accomplish such a transfer in the first place.

I have used GPG keys as well. But never figured out how I would extend their lifespan or similar.

I lack the technical knowledge to accomplish such a transfer in the first place. I have used GPG keys as well. But never figured out how I would extend their lifespan or similar.

caesar commented 2022年11月12日 23:05:17 +01:00

As per codename/secrets#2, 2FA should be a hard requirement for whoever has access to the secrets (as well as commit access to any of the repos IMO).

I'm willing to be part of it if anyone wants me to but I'm also a relative outsider so I don't see why anyone would trust me.
I propose that access be limited to @dachary and @Gusted for now, until elections of some sort can be held.
[EDIT: actually I think there should probably be three people with full access to sufficiently reduce the bus factor]

I'm curious about two things:

1. How the delegated access suggested by @fnetX would work. I imagine it would involve some infrastructure beyond a flat file system in the repo. What does anyone think about setting up our own Vaultwarden server which would allow delegation on a per-entry basis?

2. I assume anyone in the owners group could override permissions on the secrets repo? So presumably we're implicitly talking about limiting the owners group to the people selected here. Is that right? (Unless an out-of-band system like I mentioned above were adopted.)

As per https://codeberg.org/codename/secrets/issues/2, 2FA should be a hard requirement for whoever has access to the secrets (as well as commit access to any of the repos IMO). I'm willing to be part of it if anyone wants me to but I'm also a relative outsider so I don't see why anyone would trust me. I propose that access be limited to @dachary and @Gusted for now, until elections of some sort can be held. *[**EDIT:** actually I think there should probably be three people with full access to sufficiently reduce the bus factor]* I'm curious about two things: 1. How the delegated access suggested by @fnetX would work. I imagine it would involve some infrastructure beyond a flat file system in the repo. What does anyone think about setting up our own Vaultwarden server which would allow delegation on a per-entry basis? 2. I assume anyone in the owners group could override permissions on the secrets repo? So presumably we're implicitly talking about limiting the owners group to the people selected here. Is that right? (Unless an out-of-band system like I mentioned above were adopted.)

Ryuno-Ki commented 2022年11月12日 23:06:22 +01:00

Delegation could happen by means of different repositories that each are accessible by other teams.

Delegation could happen by means of different repositories that each are accessible by other teams.

fnetX commented 2022年11月12日 23:41:00 +01:00

As to me: I am open to be part of the secretkeepers, but I am also fine if I'm not.

Regarding the access delegation: If I (for example, and I'm actually willing to) commit myself for doing social media work, it's okay to just receive the plain login data instead of a complex access control. Same for e.g. an email account if there is one. Don't make it complicated, I'd just copy-paste it into my personal password manager and done.

As to me: I am open to be part of the secretkeepers, but I am also fine if I'm not. Regarding the access delegation: If I (for example, and I'm actually willing to) commit myself for doing social media work, it's okay to just receive the plain login data instead of a complex access control. Same for e.g. an email account if there is one. Don't make it complicated, I'd just copy-paste it into my personal password manager and done.

caesar commented 2022年11月12日 23:42:37 +01:00

As an aside, I strongly suggest we avoid the use of the term "Owners" as much as possible. It is misleading / gives the wrong impression, as in fact the owners of the project are the community and the people running it are (or should be) elected representatives.
It always struck me as an odd term in Gitea's governance - "elected owners" is an oxymoron - and to be honest the sense of "ownership" probably contributed to the current situation.

I don't have a good alternative term to suggest off the top of my head, but I suggest we give it some thought.

As an aside, I strongly suggest we avoid the use of the term "Owners" as much as possible. It is misleading / gives the wrong impression, as in fact the owners of the project are the community and the people running it are (or should be) elected representatives. It always struck me as an odd term in Gitea's governance - "elected owners" is an oxymoron - and to be honest the sense of "ownership" probably contributed to the current situation. I don't have a good alternative term to suggest off the top of my head, but I suggest we give it some thought.

Ryuno-Ki commented 2022年11月13日 00:06:44 +01:00

I don't have a good alternative term to suggest off the top of my head, but I suggest we give it some thought.

Steward would come to my mind. Thesaurus has more suggestions.

I feel like this could be another meta issue, though.

> I don't have a good alternative term to suggest off the top of my head, but I suggest we give it some thought. Steward would come to my mind. [Thesaurus](https://www.thesaurus.com/browse/owner) has more suggestions. I feel like this could be another meta issue, though.

Ghost commented 2022年11月13日 00:11:10 +01:00

I updated with the 2FA requirement, good point, forgot about it.

I updated with the 2FA requirement, good point, forgot about it.

Ghost commented 2022年11月13日 00:19:19 +01:00

With @caesar @Gusted @fnetX and myself, I think that's good enough for the bus factor.

At this point it's fairly easy to trust each other because there is very little at stake. I would also not worry too much about how to delegate things: this will be settled with the governance and I fully expect there will be discussions and debates before that happens. For now whatever works is good enough, IMHO.

The important thing, during this interim period, as @fnetX reminded me, is to not give access to secrets to people without them explicitly accepting to take such a responsibility.

With @caesar @Gusted @fnetX and myself, I think that's good enough for the bus factor. At this point it's fairly easy to trust each other because there is very little at stake. I would also not worry too much about how to delegate things: this will be settled with the governance and I fully expect there will be discussions and debates before that happens. For now whatever works is good enough, IMHO. The important thing, during this interim period, as @fnetX reminded me, is to not give access to secrets to people without them explicitly accepting to take such a responsibility.

Gusted commented 2022年11月13日 00:32:29 +01:00

At this point it's fairly easy to trust each other because there is very little at stake. I would also not worry too much about how to delegate things: this will be settled with the governance and I fully expect there will be discussions and debates before that happens. For now whatever works is good enough, IMHO.

Yeah, I'm going to post my proposal here:

https://codeberg.org/codename/secrets is the canonical point to store the secrets that lies with Codename.

The secretkeepers obviously have access to all secrets and have write/read access to that repository.

It's possible that an external human or application has access to one or more secrets, this must be logged in the repository, so each secret also has a list of things that are using that secret(so called users) who has access to that secret.

Arraning a secure exchange of secrets is up to the secretkeeper.

After a removal of a external human to a secret, one of the secretkeepers must rotate the secrets that they had access to and must update every user of that secret with the new secret.

As for now we will not store the secrets encrypted on Codeberg, but if the secrets becomes promiment we can look into hardening the secrets.

---

I thought about doing funky cryptography ^_^, but that will just complicate things for now. So the trust lies with the secretkeepers.

> At this point it's fairly easy to trust each other because there is very little at stake. I would also not worry too much about how to delegate things: this will be settled with the governance and I fully expect there will be discussions and debates before that happens. For now whatever works is good enough, IMHO. Yeah, I'm going to post my proposal here: https://codeberg.org/codename/secrets is the canonical point to store the secrets that lies with Codename. The secretkeepers obviously have access to all secrets and have write/read access to that repository. It's possible that an external human or application has access to one or more secrets, this must be logged in the repository, so each secret also has a list of things that are **us**ing that secret(so called users) who has access to that secret. Arraning a secure exchange of secrets is up to the secretkeeper. After a removal of a external human to a secret, one of the secretkeepers must rotate the secrets that they had access to and must update every user of that secret with the new secret. As for now we will not store the secrets encrypted on Codeberg, but if the secrets becomes promiment we can look into hardening the secrets. ---- I thought about doing funky cryptography ^_^, but that will just complicate things for now. So the trust lies with the secretkeepers.

Ghost commented 2022年11月13日 00:36:18 +01:00

As an aside, I strongly suggest we avoid the use of the term "Owners" as much as possible. It is misleading / gives the wrong impression, as in fact the owners of the project are the community and the people running it are (or should be) elected representatives.
It always struck me as an odd term in Gitea's governance - "elected owners" is an oxymoron - and to be honest the sense of "ownership" probably contributed to the current situation.

I don't have a good alternative term to suggest off the top of my head, but I suggest we give it some thought.

We're stuck with the "Owners" team as it is hardcoded in Gitea. But I agree it is best avoided anywhere else.

> As an aside, I strongly suggest we avoid the use of the term "Owners" as much as possible. It is misleading / gives the wrong impression, as in fact the owners of the project are the community and the people running it are (or should be) elected representatives. > It always struck me as an odd term in Gitea's governance - "elected owners" is an oxymoron - and to be honest the sense of "ownership" probably contributed to the current situation. > > I don't have a good alternative term to suggest off the top of my head, but I suggest we give it some thought. We're stuck with the "Owners" team as it is hardcoded in Gitea. But I agree it is best avoided anywhere else.

circlebuilder commented 2022年11月13日 03:39:09 +01:00

As an aside, I strongly suggest we avoid the use of the term "Owners" as much as possible. It is misleading / gives the wrong impression, as in fact the owners of the project are the community and the people running it are (or should be) elected representatives.

In Forgers Guild terminology: Blacksmiths (maintainers) and Journeypersons (contributors)?

The Journeyperson idea also neatly encompasses onboarding, guidance, mentoring.. in other words apprenticeship to become a true forge craftsperson.

We're stuck with the "Owners" team as it is hardcoded in Gitea. But I agree it is best avoided anywhere else.

Can't you duplicate that team to a better-named one, and then use that throughout governance docs and other references?

> As an aside, I strongly suggest we avoid the use of the term "Owners" as much as possible. It is misleading / gives the wrong impression, as in fact the owners of the project are the community and the people running it are (or should be) elected representatives. In Forgers Guild terminology: Blacksmiths (maintainers) and Journeypersons (contributors)? The Journeyperson idea also neatly encompasses onboarding, guidance, mentoring.. in other words apprenticeship to become a true forge craftsperson. > We're stuck with the "Owners" team as it is hardcoded in Gitea. But I agree it is best avoided anywhere else. Can't you duplicate that team to a better-named one, and then use that throughout governance docs and other references?

realaravinth commented 2022年11月13日 11:24:21 +01:00

I'm willing to keep the secrets and promise to transfer them to elected Owners. But I'm also okay with @caesar's proposal:

I propose that access be limited to @dachary and @Gusted for now, until elections of some sort can be held.

I'm willing to keep the secrets and promise to transfer them to elected Owners. But I'm also okay with @caesar's proposal: > I propose that access be limited to @dachary and @Gusted for now, until elections of some sort can be held.

onepict commented 2022年11月13日 11:47:38 +01:00

I don't need access to most of the secrets. Although depending on how we figure out the communications strategy.

I may need access to the social media accounts, or we work out a process.

See my ideas for the F3 and general forge friends ideas.

https://forum.forgefriends.org/t/community-management-and-project-communication/942/2

I tend to see community management as a balance between protecting the community, but also protecting the developers. But we also want to think about our reporting duties to our community and any public funding Codename gets.

I would also need access to the moderation channels and tools etc.

I have 2FA, I haven't figured out GPG signing yet.

I don't need access to most of the secrets. Although depending on how we figure out the communications strategy. I may need access to the social media accounts, or we work out a process. See my ideas for the F3 and general forge friends ideas. https://forum.forgefriends.org/t/community-management-and-project-communication/942/2 I tend to see community management as a balance between protecting the community, but also protecting the developers. But we also want to think about our reporting duties to our community and any public funding Codename gets. I would also need access to the moderation channels and tools etc. I have 2FA, I haven't figured out GPG signing yet.

Ryuno-Ki commented 2022年11月13日 12:19:42 +01:00

I'm happy to give up my secrets (i.e. be transferred to a team with less privileges).

GPG signing is basically git commit -S once you created and assigned a key to git.

Might be a good idea to document the process somewhere (could be a section with links to authorative pages).

I'm happy to give up my secrets (i.e. be transferred to a team with less privileges). GPG signing is basically `git commit -S` once you [created and assigned a key to git](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work). Might be a good idea to document the process somewhere (could be a section with links to authorative pages).

oliverpool commented 2022年11月14日 10:33:51 +01:00

I have activated 2FA, however I am not very comfortable with GPG for now (specifically extending lifespan), but I can give it another try.

For some time, I used a go project, which encrypts team secrets with GPG like pass : https://www.gopass.pw/

I used it sucessfully between 2 computers of mine for a year or so (but switched to bitwarden eventually, which syncs better with my phone).

---

In any case, if appointed, I promise to do my best to keep those secrets and I promise to transfert those secrets to the people appointed by the future governance of codename.

I have activated 2FA, however I am not very comfortable with GPG for now (specifically extending lifespan), but I can give it another try. For some time, I used a go project, which encrypts team secrets with GPG like [pass](https://www.passwordstore.org/) : https://www.gopass.pw/ I used it sucessfully between 2 computers of mine for a year or so (but switched to bitwarden eventually, which syncs better with my phone). --- In any case, if appointed, I promise to do my best to keep those secrets and I promise to transfert those secrets to the people appointed by the future governance of codename.

Ghost commented 2022年11月16日 09:08:22 +01:00

The volunteer "secret keepers" temporarily appointed until the governance is established are:

@Gusted @oliverpool @caesar @fnetX @dachary @realaravinth

They will be the only members of the "Owners" group because anyone in this group effectively has access to everything.

There have ben insightfull suggestions and ideas in this issue that could be collected to establish a security policy / security guidelines. Something to keep in mind or maybe open another issue for that purpose.

The volunteer "secret keepers" temporarily appointed until the [governance is established](https://codeberg.org/codename/meta/issues/19) are: @Gusted @oliverpool @caesar @fnetX @dachary @realaravinth They will be the only members of the "Owners" group because anyone in this group effectively has access to everything. There have ben insightfull suggestions and ideas in this issue that could be collected to establish a security policy / security guidelines. Something to keep in mind or maybe open another issue for that purpose.

Ghost commented 2022年11月16日 09:21:17 +01:00

@fr33domlover @circlebuilder @Ryuno-Ki @onepict @xy you are now members of the Admins group which should preserve all the permissions you previously had as members of the Owners group, with the exception of the secrets repository.

Please let me know if something seems wrong!

@fr33domlover @circlebuilder @Ryuno-Ki @onepict @xy you are now members of the [Admins group](https://codeberg.org/org/codename/teams/admins) which should preserve all the permissions you previously had as members of the Owners group, with the exception of the secrets repository. Please let me know if something seems wrong!