Mentioned in SAL (#wikimedia-cloud) [2024-11-21T20:43:15Z] <lucaswerkmeister> add toolforge-standards-committee as maintainer for processing of T380537

I request that the secrets not be removed in this case — the only sensitive secret is the Spur.us API key which is already expired per T380193

I suppose it’s a somewhat moot point as you’re a Toolforge root per T317438 (i.e. you can look at the secrets already), but I don’t understand the rationale for this request. If the key is expired anyway, why not remove it?

Also, can you clarify that qualifier “sensitive secrets”? I see several secrets in ~tools.bullseye/www/python/src/bullseye/settings.py, including (I think the existence of these is fine to discuss publicly):

• a SECRET_KEY – if it’s anything like Flask / ItsDangerous (and it sounds like it is), this is used to sign the session cookie; probably not much harm in keeping it, but I could also see some value in refreshing it (effectively logging everyone out of the tool, so they can log back in and start with a fresh session)
• the database credentials in replica.my.cnf – the policy asks us to delete these (and I believe there is a process for regenerating them), though it’s not really clear to me what the point is… are we supposed to also clear s54856__bullseyedb in ToolsDB?
• an IPCHECK_KEY – I assume this is used with some external service that I know nothing about
• a SPUR_KEY, as you mentioned – ditto
• a SHODAN_KEY – ditto
• an OAuth client credential pair for the bullseye consumer – as the consumer only has the user identity verification grant, I think we can justify keeping this one, even if the policy doesn’t have an exception for it

Can you shed light on some of these? :)

In T380537#10346360, @LucasWerkmeister wrote:

• a SECRET_KEY – if it’s anything like Flask / ItsDangerous (and it sounds like it is), this is used to sign the session cookie; probably not much harm in keeping it, but I could also see some value in refreshing it (effectively logging everyone out of the tool, so they can log back in and start with a fresh session)
• the database credentials in replica.my.cnf – the policy asks us to delete these (and I believe there is a process for regenerating them), though it’s not really clear to me what the point is… are we supposed to also clear s54856__bullseyedb in ToolsDB?
• an IPCHECK_KEY – I assume this is used with some external service that I know nothing about
• a SPUR_KEY, as you mentioned – ditto
• a SHODAN_KEY – ditto
• an OAuth client credential pair for the bullseye consumer – as the consumer only has the user identity verification grant, I think we can justify keeping this one, even if the policy doesn’t have an exception for it

Can you shed light on some of these? :)

oh I just didn't want to have to spend too much time getting it back up and running again :) if these things need to be done, by all means please do. It'd be nice if s54856__bullseyedb didn't need to be cleared though.

In T380537#10346360, @LucasWerkmeister wrote:

• the database credentials in replica.my.cnf – the policy asks us to delete these (and I believe there is a process for regenerating them), though it’s not really clear to me what the point is… are we supposed to also clear s54856__bullseyedb in ToolsDB?

Resetting the database credentials seems pointless to me as well, since the new credentials would have exactly the same access. The policy appears to allow using discretion: "The committee has the power to ... decide if obvious secret information such as SUL account passwords, database passwords, and OAuth secrets should be removed or not."

I also think clearing the database defeats the point of adopting the tool. At that point you might as well take the code and redeploy it as a new tool. The databases belong to the tool, and should be accessible to whoever is in charge at the moment.

• an IPCHECK_KEY – I assume this is used with some external service that I know nothing about
• a SPUR_KEY, as you mentioned – ditto
• a SHODAN_KEY – ditto

On the other hand, use of the 3rd party API keys could potentially incur charges to the former maintainer. I think these should be removed as it's unfair to them that someone they haven't authorized is able to control their bank balance. (Might not be as expensive as leaving an EC2 running, but still...)

• IPCHECK_KEY is https://ipcheck.toolforge.org/, which is still half-alive but not actively maintained by @SQL and @MusikAnimal.
• SPUR_KEY was a WMF grant funded key for https://spur.us/ that has since expired (which caused this adoption request). WMF now has a subscription to the same service and it would make sense to use that instead.
• SHODAN_KEY was a WMF grant funded key for https://shodan.io/ that has probably also expired.

Grant requests:

• https://meta.wikimedia.org/wiki/Grants:Project/Rapid/GeneralNotability/Bullseye
• https://meta.wikimedia.org/wiki/Grants:Programs/Wikimedia_Community_Fund/Rapid_Fund/Bullseye_2_(ID:_22140665)

Alright, suggested course of action:

• keep SECRET_KEY and replica.my.cnf as relatively harmless
• keep IPCHECK_KEY to reduce disruption – if the IPCheck owners disagree, they can probably revoke the key themselves (or ask the committee or the new bullseye maintainers to change it)
• clear out SPUR_KEY as expired
• clear out SHODAN_KEY as probably expired (I tested it locally and got 403 Forbidden back – it’s possible I didn’t use the Python shodan library correctly but I think “expired” is the most likely explanation)
• leave a root-readable copy of the original file in place just in case we need the cleared out secrets after all

I’ll go ahead with this tomorrow if no other committee member objects :)

Mentioned in SAL (#wikimedia-cloud) [2024-12-18T18:00:39Z] <lucaswerkmeister> sudo install -m600 settings.py{,-before-T380537}

Mentioned in SAL (#wikimedia-cloud) [2024-12-18T18:03:25Z] <lucaswerkmeister> sed -i -E "/(SPUR|SHODAN)_KEY/ s/'[^']*'/'expunged (T380537)'/" settings.py

Mentioned in SAL (#wikimedia-cloud) [2024-12-18T18:04:17Z] <lucaswerkmeister> sudo rm __pycache__/settings*.pyc # T380537

Mentioned in SAL (#wikimedia-cloud) [2024-12-18T18:06:21Z] <lucaswerkmeister> add samtar and remove toolforge-standards-committee per T380537