Proposal: Cracking Continued
Timed out 2-0 with 1 DEF, enacted by Zack.
Adminned at 30 Jan 2024 20:55:57 UTC
Rewrite the shell command in “Brute Force” as follows:
As a Daily Shell Command, a Client may brute force a Target, specifying the name of another Client. If the Target does not have a Brute Force Attempt which names the Agent performing the command, the Mainframe will create a new Brute Force Attempt on the Target Client with the Agent’s name and a Progress of 0.
The Mainframe will increase the Progress of the Agent’s Brute Force Attempt on the Target Client by the Agent’s CPU Cycles.
* If the entry’s Progress is greater than or equal to the Target’s Passcode Complexity, the Mainframe shall secretly communicate the Target’s Passcode to the Agent.
* Otherwise, the Mainframe shall inform the Agent of the current Progress of their Brute Force Attempt on the Target.The Mainframe will include the name of the Target and the current Progress of the attempt in the log of the action.
If the majority of EVCs on this proposal contain “_REPEAL_” then repeal the rule “Brute Force” and remove the sentence “The Client’s Brute Force Attempts are reset to an empty list and the Mainframe should recalculate its Passcode Complexity.” from “Best Practices”.
As written, if the Progress is not greater than or equal to the Passcode Complexity the action fails, and if a virtual action fails it has no effect on gamestate, so you need to have enough CPU cycles to crack the passcode in one go or else nothing happens. Also, it says to log something that isn’t the occurrence of a shell command, so it just creates a log entry with a bunch of gaps in it. I believe this addresses both of those.
JonathanDark: he/him
I’m not sure of the necessity of this, because I think we’ll wind up replacing the Brute Force mechanic entirely. That said, if any alternative ideas don’t come along, we’ll need this, so I won’t vote against it just yet, but I’ll probably hold my vote for a bit.