Sadly, we cannot restrict (easily, would require some plugin/submit rule work) on the Gerrit side. If we're going to be using http password auth I'd like if the bot could rotate its password pretty often since +2 is a pretty big ask of an automated thing (nb: Translatewiki uses SSH auth for its work, but it's also offsite from us)

In T174760#3573697, @demon wrote:

Sadly, we cannot restrict (easily, would require some plugin/submit rule work) on the Gerrit side.

Hm, OK. I could implement this on the bot's side then?

If we're going to be using http password auth I'd like if the bot could rotate its password pretty often since +2 is a pretty big ask of an automated thing (nb: Translatewiki uses SSH auth for its work, but it's also offsite from us)

How often would you suggest? I could look into using SSH auth but the whole process is automated (I just manually start it), so I don't think I can exactly type in a passphrase? But whatever you think is most secure, I'll attempt to figure out a way to implement it :)

In T174760#3573713, @Legoktm wrote:

In T174760#3573697, @demon wrote:

Sadly, we cannot restrict (easily, would require some plugin/submit rule work) on the Gerrit side.

Hm, OK. I could implement this on the bot's side then?

That's what I assumed from the start. But tbh, it might not be *that* hard to implement a rule plugin, just never tried!

If we're going to be using http password auth I'd like if the bot could rotate its password pretty often since +2 is a pretty big ask of an automated thing (nb: Translatewiki uses SSH auth for its work, but it's also offsite from us)

How often would you suggest? I could look into using SSH auth but the whole process is automated (I just manually start it), so I don't think I can exactly type in a passphrase? But whatever you think is most secure, I'll attempt to figure out a way to implement it :)

Not really sure. Basically just kind of thinking the whole "don't depend on VMs in Cloud Services to ever be...completely private...." like has been said before.

SSH isn't inherently more secure than HTTPS operations with git. Rotating the HTTP password can be done via the REST API. But maybe I'm just being overly paranoid here....

But also....if we're using the API we're having to auth using the actual LDAP password for the user...which is even more sensitive.... Suppose that could be passed as an argument when starting the process....

In T174760#3573774, @demon wrote:

Not really sure. Basically just kind of thinking the whole "don't depend on VMs in Cloud Services to ever be...completely private...." like has been said before.

SSH isn't inherently more secure than HTTPS operations with git. Rotating the HTTP password can be done via the REST API. But maybe I'm just being overly paranoid here....

Alternative idea, I can just keep the password in my password manager, and have the script prompt me for the password when I start it. The password won't be stored on disk - just in memory while the script runs. And I've already taken some precautions against the password leaking via the logs.

@demon we could do want upstream gerrit did for polygerrit. (without a plugin). it's done in the All-Project.

Do what? You can't do path-based matching in Gerrit ACLs. Just branch (maybe topic?) based.

You can do paths. Upstream did it.

See https://gerrit-review.googlesource.com/#/c/gerrit/+/118072/3/rules.pl

Ugh, Prolog. Craziest idea they ever had. No.

(Also, those aren't ACLs, they're submit rules. I'd rather write a plugin in Java for that than do Prolog)

In T174760#3573778, @demon wrote:

But also....if we're using the API we're having to auth using the actual LDAP password for the user...which is even more sensitive.... Suppose that could be passed as an argument when starting the process....

I was going to use this to see if I could write a script to automatically rotate the password and it turns out you per https://gerrit.wikimedia.org/r/Documentation/rest-api.html#authentication and my testing you actually authenticate with the current HTTP password, not the LDAP password.

If your using HTTP digest authentication, note that this was removed with gerrit 2.14.

In T174760#3574763, @Paladox wrote:

If your using HTTP digest authentication, note that this was removed with gerrit 2.14.

What's the recommended way to authenticate now? And will it still work on 2.13 that we currently run? Otherwise I'll just change it whenever we upgrade.

To address the account security concerns, I wrote the following:

• https://gerrit.wikimedia.org/r/#/c/375500/ - Prompt for HTTP password instead of keeping it on disk
• https://gerrit.wikimedia.org/r/#/c/375501/ - Add a script to rotate the Gerrit HTTP password

@Legoktm see https://gerrit-review.googlesource.com/Documentation/rest-api.html#authentication (this is from the master doc)

Ah they switched to HTTP Basic Auth. That'll be trivial to migrate to in the future.

HTTP basic authentication is recommended now. (sorry posted this without refreshing, before i saw your comment).

Yep, they did this as digest would have exposed your password to everyone in a plaintext file. in All-User or All-Project

So are there any remaining issues with giving libraryupgrader +2?

I think we'll be fine.

Change 380064 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[labs/libraryupgrader@master] Auto-approve files that only touch composer/package.json and phpcs.xml

https://gerrit.wikimedia.org/r/380064

Change 380064 merged by jenkins-bot:
[labs/libraryupgrader@master] Auto-approve files that only touch composer/package.json and phpcs.xml

https://gerrit.wikimedia.org/r/380064