+1 On Wed, 4 Jun 2025 at 11:32, Yoann Rodiere via hibernate-dev < hibernate-dev(a)lists.jboss.org&gt; wrote: > Hello, > > As part of the move to Commonhaus, I'm currently going through our GitHub > setup, and I'm noticing we have a lot of users with extensive (and I mean > *extensive*, sometimes admin or even owner) access to our > organization/repositories, but who are no longer regular contributors. > > Additionally, we also have organization members on GitHub who are not > technically Hibernate members: they have never actually contributed to > Hibernate, but are there for technical reasons, for example because they're > coworkers who helped out with some infrastructure issue. > > While it's fine in principle, because we trust these people, it's very, > very far from security best practices. Account hacking happens, email > addresses get stolen, and the people using these GitHub accounts might one > day be an attacker instead of the person we trust. > > According to Commonhaus' automated report, we're currently at 32 people > having admin rights on one Hibernate repository or another. Which I think > we can all agree is much more than necessary. > > For that reason, I'd like to propose that: > > 1. *We create an "Alumni" team in our GitHub organization*, moving to that > team anyone who is actually a member, but hasn't contributed for... let's > say 2 years? Of course this isn't a permanent thing, and we can simply move > alumni back to the relevant team if they become active again. > 2. *We move non-members out of our GitHub organization*, or to "external > collaborators" (that's a GitHub feature) if still necessary. > 3. *We schedule yearly audits of our GitHub configuration* to review access > rights again in the future, and move people to the Alumni team as > necessary. > > Note moving people in and out of teams will get them notified, so I would > send another email directly to impacted people before/during the move, to > avoid this being seen as personal/insulting. It's really not. > > *Thoughts, opinions, +1s?* > > Yoann Rodière > Hibernate team > _______________________________________________ > hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org > To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org > Privacy Statement: https://www.redhat.com/en/about/privacy-policy > List Archives: > https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/messa... > _______________________________________________ hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/messa...

On 4 Jun 2025, at 12:21, Yoann Rodiere via hibernate-dev <hibernate-dev(a)lists.jboss.org&gt; wrote: Hello, As part of the move to Commonhaus, I'm currently going through our GitHub setup, and I'm noticing we have a lot of users with extensive (and I mean *extensive*, sometimes admin or even owner) access to our organization/repositories, but who are no longer regular contributors. Additionally, we also have organization members on GitHub who are not technically Hibernate members: they have never actually contributed to Hibernate, but are there for technical reasons, for example because they're coworkers who helped out with some infrastructure issue. While it's fine in principle, because we trust these people, it's very, very far from security best practices. Account hacking happens, email addresses get stolen, and the people using these GitHub accounts might one day be an attacker instead of the person we trust. According to Commonhaus' automated report, we're currently at 32 people having admin rights on one Hibernate repository or another. Which I think we can all agree is much more than necessary. For that reason, I'd like to propose that: 1. *We create an "Alumni" team in our GitHub organization*, moving to that team anyone who is actually a member, but hasn't contributed for... let's say 2 years? Of course this isn't a permanent thing, and we can simply move alumni back to the relevant team if they become active again. 2. *We move non-members out of our GitHub organization*, or to "external collaborators" (that's a GitHub feature) if still necessary. 3. *We schedule yearly audits of our GitHub configuration* to review access rights again in the future, and move people to the Alumni team as necessary. Note moving people in and out of teams will get them notified, so I would send another email directly to impacted people before/during the move, to avoid this being seen as personal/insulting. It's really not. *Thoughts, opinions, +1s?* Yoann Rodière Hibernate team _______________________________________________ hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/messa...

+1 Am 04.06.2025 um 12:21 schrieb Yoann Rodiere via hibernate-dev: > Hello, > > As part of the move to Commonhaus, I'm currently going through our GitHub > setup, and I'm noticing we have a lot of users with extensive (and I mean > *extensive*, sometimes admin or even owner) access to our > organization/repositories, but who are no longer regular contributors. > > Additionally, we also have organization members on GitHub who are not > technically Hibernate members: they have never actually contributed to > Hibernate, but are there for technical reasons, for example because they're > coworkers who helped out with some infrastructure issue. > > While it's fine in principle, because we trust these people, it's very, > very far from security best practices. Account hacking happens, email > addresses get stolen, and the people using these GitHub accounts might one > day be an attacker instead of the person we trust. > > According to Commonhaus' automated report, we're currently at 32 people > having admin rights on one Hibernate repository or another. Which I think > we can all agree is much more than necessary. > > For that reason, I'd like to propose that: > > 1. *We create an "Alumni" team in our GitHub organization*, moving to that > team anyone who is actually a member, but hasn't contributed for... let's > say 2 years? Of course this isn't a permanent thing, and we can simply move > alumni back to the relevant team if they become active again. > 2. *We move non-members out of our GitHub organization*, or to "external > collaborators" (that's a GitHub feature) if still necessary. > 3. *We schedule yearly audits of our GitHub configuration* to review access > rights again in the future, and move people to the Alumni team as necessary. > > Note moving people in and out of teams will get them notified, so I would > send another email directly to impacted people before/during the move, to > avoid this being seen as personal/insulting. It's really not. > > *Thoughts, opinions, +1s?* > > Yoann Rodière > Hibernate team > _______________________________________________ > hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org > To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org > Privacy Statement: https://www.redhat.com/en/about/privacy-policy > List Archives: https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/messa... _______________________________________________ hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/messa...