Bug #78088 HISTIGNORE should be applied when writing to the disk
Submitted: 16 Aug 2015 0:28 Modified: 19 Nov 2015 14:55
Reporter: Wayne Walker Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Command-line Clients Severity:S4 (Feature request)
Version:5.6.8 OS:Any
Assigned to: CPU Architecture:Any
Tags: EASILY_REMEDIED, FRUSTRATING

[16 Aug 2015 0:28] Wayne Walker
Description:
Applying HISTIGNORE in client is excessive.  One cannot up arrow the line one just entered to correct it:

update participants p join passwords pw on pw.password = p.old_password set p.encrypted_password = pw.encrypted_password;

Because there are no string literals in the above statement, there is no reason for it to not be available for me to up arrow and run again, and it is even safe to be written to a history file.

Since commands I enter in the client are not written to the history file until I exit the client, the filtering could be done then rather than when I enter the data and may still need it (since I typoed that command a dozen times before I got it right; having to retype or cut and paste it each time).

How to repeat:
in the client, enter the completely non-sensitive query:

update participants p join passwords pw on pw.password = p.old_password set p.encrypted_password = pw.encrypted_password;

Now hit up arrow.  It's gone.

Enter:

select coutn(*) from users where (encrypted_password) !=60;
 
Hit up arrow to fix "count", you can't.

Suggested fix:
Apply the filtering when writing the history to disk, rather than when adding the command to the in memory history.  Or at least put it in the history as REDACTED FOR SECURITY so that people understand it is not a bug but an active choice.

Additionally, I think the pattern (using regex since I don't know the pattern language of histignore) should be .*IDENTIFIED.*['"`].*:.*PASSWORD.*['"`].* so that it is only not recorded if it possibly has sensitive data.
[19 Nov 2015 14:55] Georgi Kodinov
thank you for the reasonable feature request.