Converting .csv/.txt into .keychain?

Consider building a series of 'security' commands, which are then executed in sequence. In short, build a shell script file. This is just an idea based on the 'security' command's man page:

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/security.1.html

According to the man page, there are two sub-commands that add passwords: add-generic-password and add-internet-password. I hope that part of your cleanup managed to preserve this property from the original export, because it looks like you'll need it.

Each of these sub-commands has a host of options. After my brief reading, it appears that everything about the password entry can be specified with a suitable option.

So the way to proceed is to parse the .csv or .txt file, presumably getting the data from the proper column (field) using whatever delimiter you've got in there. Once you have a collection of fields, you emit text with the proper options and whitespace. Here's a simple example:

Suppose the fields consist of tab-delimited account, password, item-type, and kind (terminology per 'security' man page). In awk, these would be:
$1 = account
$2 = password (cleartext)
$3 = item-type
$4 = kind

The awk statement to print these would be:

Code:

print "security add-internet-password" "-a" $1 "-w" $2 "-C" $3 "-D" $4

Since the default output separate in awk is a space (the OFS variable), the above would be printed with a single space between the items.

Awk seems pretty well suited to doing this task, because it automatically does the "read a line and break into fields" for you, and can automatically match input patterns to specific actions. The output from awk would look like a series of 'security ...' commands. You could copy and paste one into a Terminal window to make sure it works before committing to the whole sequence.

If there are more than just password entries, you'll have to produce 'security' command-lines that do the correct thing according to the entry's type: add a cert, add a private key, etc.

The output of awk can also be piped into a shell, which would then interpret the commands produced. This would be the daredevil approach. Safer would be to redirect awk's output to a file, which you then review carefully, try one or two commands individually, then if all proves well, you can tell the shell to run.

Personally, I'd go one step further and write only to a nonce keychain created expressly for testing (see the 'security' man page). To complete the test, open the repopulated keychain with the Keychain utility app and make sure it works. If not, it's much easier to close that file and trash it than it is to manually remove a bunch of borked entries from your main login keychain.


Think of it as writing a program in awk that takes the input data and produces a shell script. Executing the shell script is what writes all the keychain entries, not the awk program itself.

 

I think it's a consequence of a couple factors: utility (who would use it, how often) and security.

One of the working principles of security is to keep secret things secret. That means private keys are kept wrapped (encrypted), even when exported. Same thing for all other secrets, including passwords. Exporting to cleartext defeats that. Furthermore, if there's a simple pathway to both export and import in which the intermediate form is cleartext, then that design is fundamentally encouraging users to break the important principle of secrets remaining secret.

If a person has need to move keys, passwords, etc. around as files, then that's what keychain files are for. Since they're wrapped (encrypted), they don't defeat the secrecy principle. Moving content using files is one of the main purposes of import/export, so that purpose is better served using keychain files. Granted, one of the other purposes of import/export is interoperability, and that requires an external compatible format. That's why all the exporting typically wraps secrets by default, and you have to make an effort to export secret items in cleartext.

I'm not saying that cleartext import wouldn't be useful. It would. It's just that on balance, relatively few people would use it, and its presence would undermine security in a significant way. As a directly accessible feature, it's a casualty of utility and security tradeoffs.