enigma(1): Restyle code, fix salt bug, reword manual, other improvements

[sg]

Summary

I was working on making a portable version of crypt and decided to use
the FreeBSD version. I cleaned up the source and fixed a small bug in
the process, which I've merged back here:

• Reformat code to conform to style(9) guide.
• Use getopt for option handling.
• Replaced getpass(3) with the better readpassphrase(3).
• Since we use the first two bits of the key as the salt, check if the key contains valid DES contains valid characters.
• Replace error message code with err/x.
• Change variable types to be more consistient.

Also, this is my first time using Phab. I may not get everything right.

Test Plan

I did not compile this, as I currently don't have access to a FreeBSD
dev machine. However, I did test the portable version using files
generated from a Solaris 10 machine, and they decrypted fine.

[sg]

I setup my src tree on freefall and realised my work was very sloppy:
missing semicolons, incorrect function declarations and a subtle bug
with using err(). These are now fixed.

I also changed the manual slightly by adding dollar ('$') chars to code
that is to be run in the shell.

[bcr]

The man page looks good so far. Can you give it a run with "igor <path/to/manpage" and "mandoc -Tlint" to see if they emit any warnings?
@imp: Can you help review the code changes whether they make sense? Thank you!

[bcr]

Adding Ed, maybe he has time to review the code. I don't want to add the whole secteam yet...

[emaste]

I don't want to add the whole secteam yet...

I'll try to look at this, but there's no need for secteam's involvement in changes to this code.

[sg]

Run enigma.c through FreeBSD clang-format

[sg]

@bcr I already check my manuals with mandoc -Tlint and igor and can confirm that there are no warnings/errors.

[bcr]

OK, looks good to me from the manpage side of things.

[0mp]

Any updates on this one?

[pstef]

usr.bin/enigma/enigma.1

60–64

The "rather small cryptographic value" is not wrong and "worse than useless" is unnecessarily contemptuous for a manual.

usr.bin/enigma/enigma.c

25–42

I see no reason to initialize these.

[emaste]

usr.bin/enigma/enigma.1

49

this seems to imply that it the ability to examine environment variables is (part of) the reason for this option.

How about something like either

This option is provided for compatibility with other implementations; environment variables can also be examined with ps.

or

This option is provided for compatibility with other implementations.
Note that environment variables can also be examined with ps.

55–56

I wouldn't even say "supposedly more secure" here, perhaps
the encryption engine is modified in a way that is incompatible with other implementations.

and then maybe expand with

"This was previously documented as being more secure, but .Nm has no cryptographic value with or without the -s option."

[emaste]

usr.bin/enigma/enigma.c

195–197

it's hard to review when functional changes are combined with whitespace changes. I would suggest submiting a change to fix style(9) issues first followed by functional changes