Some commands (add account|group, del account|group, get group@account) require one argument which is the combination of the group name and account name joined with the @ sign. When a user creates a new group or account the internal.Account and internal.Group types must validate the names in their valid function. Especially required are checks for names as they must not contain the @ sign since names with this char will cause the internal.splitQuery to bug out.

somehow long random password with a big entropy will be evaluated as security.Low. The func PasswordStrength should be re-written following some standards.

• time to brute-force
• entropy of characters
• length

currently some actual secure passwords can only be inserted by using the --insecure flag...

IMO the user should be able to delete a group - however there are some things to consider:

• should groups be deleted if its last account has been deleted?
• deleting an entire group sounds like a dangerous thing. Should there be a different conformation dialog? a rollback option?

reference for creating snap

https://snapcraft.io/docs/go-applications

The idea it to either have an separate command like sherlock gen to generate a password based on some flags (length, special chars, numbers, etc.)

Another option which would be nice is to have a flag --gen for Sherlock add account which will generate a password for the new account. Open for suggestions

Listing all accounts for a given group already works with sherlock list group-name, here the default if no argument is given will be the default group. Having a separated command to list all groups would not be nice from a users point of view. Therefore, I feel the sherlock list command needs to change a bit.

Maybe the command could check if the argument is something like all to display all groups or simply use a flag --all?

if a user creates and account the command first asks for the group password and then for the account password. in case the group password is wrong or the group does not exists it would be good if the user would not need to type in the accounts password first just to see that

Hi, I interested in your works. may I contribute? I have an idea. How about we add more command to show list of commands available. like -h or --help flags perhaps? that would be nice. what do you think ? thanks.

there should be command like sherlock update group@account which lets you update account information.
Not sure what information can be updated. Obviously the password is something the user must be able to update. However, if the user can also update things like the account name we need to check if the name is colliding with other existing names in the group.

the internal.Account struct should also be appended with a UpdatedOn field which can be displayed for sherlock list group.

currently the sherlock add command takes care of adding new groups as well as new accounts. It would be more explicit if the command would be build like sherlock add group --name and sherlock add account --name --tag.
However, I am not sure if the --name flags would than be still required?

the user should be able to delete an existing account. for the command I imagine something like sherlock del account group@account. Optional the command can have a --force flag which will not prompt the user for conformation else the user should be prompt to confirm the deletion with [y/N]

All constants and exported funcs should have a proper comment.

1. While adding a group, --group is required

Readme says:

sherlock add group detective

Existing behavior:

# sherlock add group g7
❗ account name required (--name)

2. While adding an account to a group, --name is required

Readme says:

sherlock add account bakerstreet --gid detective --tag 221b

Existing behavior:

# sherlock add account  g1-a2 --gid g8 --insecure
❗ account name required (--name)

If the user hits CTL-C mid command, sherlock needs take care of open files and more importantly unwritten data which might only be in-memory.

Each sherlock.Func must receive the ctx context.Background() as a first parameter and handle cancelation.

When creating a new group the user needs to set a password to encrypt and decrypt the vault. As of now the password is not checked for its strength.

If the user adds a new group the password should be checked for its strength by using the security.PasswordStrength function altering if the password is insecure.

sherlock add group (not implemented but will be as laid out it #9) should therefore also have a --insecure flag to allow insecure passwords.

Furthermore the password check should also be implemented for setting up the default group when running sherlock setup