From: Carlos O'Donell <carlos@redhat.com>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: cti-tac@lists.linuxfoundation.org
Subject: General keyring process questions.
Date: Thu, 29 Feb 2024 09:55:45 -0500 [thread overview]
Message-ID: <343c164c-a49a-4ece-97b8-a28eb7b84da2@redhat.com> (raw)
Konstantin,
I'm dog-fooding the trusted introducer process with one of the CTI TAC
members as a way to work out the kinks for the general developer
workflow of adding and removing people.
Questions:
- Does adding a key to allowed-signers give access to also update
allowed-signers itself?
- The answer I epxect is "No" because I want a distinction between
community "admin" and community "developer" (which write access
to the repository).
- I assume the answer is that only trusted indtroducers can update
the keyring, and that the keyring is only an intermediary keyring
because it doesn't look like a normal gitolite admin repo.
- What is the syntax of allowed-signers?
- What does 'namespace="git"' mean?
- Are new account requests sent to it-coreprojects-helpdesk@linuxfoundation.org?
- What are the implications of selecting a username?
- I assume the answer is that the username is not visible anywhere, but
is the username used during the ssh connection to the gitolite server
and as such is the name used in the gitolite admin repo with the keys?
- How do we authorize group membership?
- How do we know what groups to request in the email to LF IT?
- Group membership is a gitolite repo policy detail and some groups may
have distinct project policy e.g. web repo vs. code repo.
How do we enforce that policy?
For example, a gitolite project will usually have an admin repo with
configuration and keys, and the code repos. In the current setup it
LF IT is the maintainer of the admin repo, and the community maintains
the keyring and content repos. If we have several content repos, how
do we authorize only access to one of them? Is that encoded in the
allowed-signers in some way?
--
Cheers,
Carlos.
next reply other threads:[~2024-02-29 14:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-29 14:55 Carlos O'Donell [this message]
2024-02-29 14:50 ` General keyring process questions Konstantin Ryabitsev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=343c164c-a49a-4ece-97b8-a28eb7b84da2@redhat.com \
--to=carlos@redhat.com \
--cc=cti-tac@lists.linuxfoundation.org \
--cc=konstantin@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).