Add support for transitioning from PROXY V1 protocol on the incoming side to X-Forwarded-For on the outgoing side

[afterfate]

Might not be of interest to a general audience however in our hosting environment we wanted to add some features. We did this a couple of years ago with stud, ending up having changes pulled into insom/stud. This is a hand merge of the changes into hitch, merging with git itself was do-able but ended up being a very large set of changes(obviously). This would make reviewing the changes a painful exercise.

• Added arguments and configuration options for config file.
  • pem-keypass -- supply password for key file
  • write-xff -- take information from PROXY V1 protocol and write X-Forwarded-For on clear side
  • read-proxy -- only read in PROXY V1 protocol, do not pass it on, for use with write-xff option to translate PROXYV1 to X-Forwarded-For during ssl unwrap.
• Change to autoconf to detect type of time structs available in the stat struct on platform and use correct struct for nanosecond resolution of mtime.

[lkarsten]

Hi.
Sorry for not getting back to you earlier.

First of all, hitch is protocol agnostic, and we prefer to keep it that way. Adding support for X-Forwarded-For is not something we're looking to do.

The PEM passphrase support is interesting, although I think most installations runs unprotected keys. Would it be possible for you to split that into a separate PR?

Can you expand on what platforms the nanosecond changes are relevant for?

[daghf]

Hi

I commited bbb4215 and will take a look at the PEM passphrase commit when I get around to it. Thanks :)

[afterfate]

Sorry about my own delay there, I added the nanosecond configuration differences after hitting issues building on OSX el cap. If necessary I can try to take a look at breaking out the xff feature if it isn't possible to cherry pick it out of the existing commits.

[dridi]

I'd rather avoid putting a pass-phrase in clear text with the rest of the configuration. I'd rather reference a file containing the pass-phrase or a command to run in order to retrieve it.

This allows you to manage pure configuration without overhead (think versionning of your config file, hype continuous deployment tool of the moment etc). The pass-phrase would be obtained from a different channel and require the proper privileges (eg. with file permissions).

[fgsch]

Perhaps it could support both using some special syntax, e.g. @/some/path/to/passphrase?

[glensc]

indent change

[dridi]

@afterfate this pull request has been conflicting with the master branch for a while. I hope you will still be interested submitting a new one without the X-Forwarded-For handling, but for now I'm closing this one.