[aur-dev] [PATCH 1/2] Emit warning when TUs use their supowerpowers to overwrite a pkgbase
AUR_PRIVILEGED allows people with privileged AUR accounts to evade the block on non-fast-forward commits. While valid in this case, we should still provide a message saying that this happened, since in at least one case ( https://aur.archlinux.org/packages/rtmidi/ ) a TU did this without realizing there was an existing package. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> --- Similar to the warn_or_die function, except that doesn't take alternative messages and there is no nice universal message here. I think I prefer something that allows the TU to set whether they really mean to perform a privileged TU action, since accidentally overwriting something is kind of bad either way. The follow-up patch implements this -- instead? alongside? Either patch stands on its own, though I think I'd like to see both. aurweb/git/update.py | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/aurweb/git/update.py b/aurweb/git/update.py index c9a98d0..3b9ff97 100755 --- a/aurweb/git/update.py +++ b/aurweb/git/update.py @@ -258,11 +258,14 @@ def main(): conn = aurweb.db.Connection() # Detect and deny non-fast-forwards. - if sha1_old != "0" * 40 and not privileged: + if sha1_old != "0" * 40: walker = repo.walk(sha1_old, pygit2.GIT_SORT_TOPOLOGICAL) walker.hide(sha1_new) if next(walker, None) is not None: - die("denying non-fast-forward (you should pull first)") + if privileged: + warn("non-fast-forward push (are you absolutely sure you mean this?)") + else: + die("denying non-fast-forward (you should pull first)") # Prepare the walker that validates new commits. walker = repo.walk(sha1_new, pygit2.GIT_SORT_TOPOLOGICAL) -- 2.13.3
AUR_PRIVILEGED allows people with privileged AUR accounts to evade the block on non-fast-forward commits. While valid in this case, we should not do so by default, since in at least one case a TU did this without realizing there was an existing package. ( https://aur.archlinux.org/packages/rtmidi/ ) Use .ssh/config "SendEnv" on the TU's side and and sshd_config "AcceptEnv" in the AUR server to specifically request privileged access. TUs should use: `export AUR_PRIVILEGED=1; git push` Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> --- INSTALL | 1 + aurweb/git/auth.py | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/INSTALL b/INSTALL index 8c9c4dd..22bbe33 100644 --- a/INSTALL +++ b/INSTALL @@ -76,6 +76,7 @@ read the instructions below. PasswordAuthentication no AuthorizedKeysCommand /usr/local/bin/aurweb-git-auth "%t" "%k" AuthorizedKeysCommandUser aur + AcceptEnv AUR_PRIVILEGED 9) If you want to enable smart HTTP support with nginx and fcgiwrap, you can use the following directives: diff --git a/aurweb/git/auth.py b/aurweb/git/auth.py index 022b0ff..9aab417 100755 --- a/aurweb/git/auth.py +++ b/aurweb/git/auth.py @@ -51,7 +51,7 @@ def main(): env_vars = { 'AUR_USER': user, - 'AUR_PRIVILEGED': '1' if account_type > 1 else '0', + 'AUR_PRIVILEGED': os.environ.get('AUR_PRIVILEGED', '0') if account_type > 1 else '0', } key = keytype + ' ' + keytext -- 2.13.3
On Fri, 21 Jul 2017 at 06:13:40, Eli Schwartz wrote:
AUR_PRIVILEGED allows people with privileged AUR accounts to evade the block on non-fast-forward commits. While valid in this case, we should not do so by default, since in at least one case a TU did this without realizing there was an existing package. ( https://aur.archlinux.org/packages/rtmidi/ )
Use .ssh/config "SendEnv" on the TU's side and and sshd_config "AcceptEnv" in the AUR server to specifically request privileged access. TUs should use: `export AUR_PRIVILEGED=1; git push` [...]
I am not sure whether this is a good idea. AUR_PRIVILEGED is not only used for non-fast-forward pushes. It is used for every SSH interface command that requires TU privileges, such as disowning other users' packages or changing the keywords of a package one does not maintain. It seems rather inconvenient to require TUs to prefix all their superpower commands with AUR_PRIVILEGED=1. Actually, TUs should *never* make use of the forced push feature unless they are dealing with some copyright infringement or removing some other legally questionable stuff from the history. So it might make sense to either restrict this feature to very few TUs (those dealing with legal issues reported to aur-support@archlinux.org) or to add some kind of extra switch as you suggested -- but only for non-fast-forward pushes. The warning you implemented in patch 1/2 certainly is a good idea as well. Thanks! Regards, Lukas
participants (2)
-
Eli Schwartz
-
Lukas Fleischer