Tiny tweaks ('del'ete and show login)

[dirkx]

Few tiny tweaks ot mc-cli to make it a bit more useful in automated issue/management settings.

[dirkx]

On 7 Jan 2019, at 17:16, raoulh notifications@github.com wrote:

• if subCmd == "get" {
• if subCmd == "get" || subCmd == "del" { That's wrong... To delete a credential you need to put the device into "Memory Management Mode", and deal with the MMM api then. Your path add a del command that does the same as get... What the point.

Well - it works rather nicely. And it lets us auto-mange pre-issued keys. Which is what we need for auto provisioning/recall.

Though not in bulk. That would be the next useful things - to sent a list of them to be done in one swell swoop under MMM.

[raoulh]

delshould delete a credential right?

The code does:

if subCmd == "get" || subCmd == "del" {
        m.Msg = "get_data_node"
}

So it sends get_data_node when you want to delete a credential. How could it work on your side then? Am I missing something?

[dirkx]

So it sends get_data_node when you want to delete a credential. How could it work on your side then? Am I missing something

Quite honestly - I have no idea. I put it in on whim; guessing/cargo-culting how it should work and then was surprised it did.

But it went into MMM mode (which was sort of blocking an easy approach for bulk-delete on my demo/acceptance tests) - and bulk delete seemed out of quick reach.

So I left it at that.

[dirkx]

(and would assume … else if subCmd == "del” { m.Msg = “del_credential”… to do the trick. No idea - Sorry!

[raoulh]

Ok, actually I misread the diff from github... It works for login, as it correctly set the command to del_credential.

The code where I commented is for data management, not credentials. And for that the code is actually not good, as it use the same get_data_node for the del command.

The del command for data management involves MMM. You need to send start_memorymgmt wait for the approval on the device, then send delete_data_nodes with a list of data sercices to delete

For this PR, it would be ok for me to just merge the delete part for credentials. But you would need to remove the data part as it is not good as it is.

[dirkx]

Totally fine.

The ultimate long term use case for us are things such as:

./generate_otp 'project X' | load-into-mooltipass

where the first generates something like a CVS file with site/project names, user IDs and passwords. And then loads this into the key.

Either under one context/site name as passed - or just taking that from the CSV file (I guess the generic use case is command line import from CSV).

With a matching command such as

    ./delete-from-mooltipass 'project X'

Where the latter simply deletes everything where the context/site matches 'project X' from the key again. Or (as as we will generally ALSO need to schred the chip card for a project) something like a command such as:

./wipe-memory-for-currently-inserted-chipcard

./get-chipcard-ID
./wipe-memory  <chipcard-ID>

Dw.