Pull Crypto out to its own library

[spheromak]

would be nice to pull the chef-crypto out into its own library. Was discussing this a bit with @ctdk merging client and server crypto into a separate lib. open for more thoughts on this.

[marpaia]

Mmm yes, this would be interesting. The privateEncrypt function actually implements the rsa_private_encrypt function from OpenSSL. It didn't exist in Go so I had to inline it. It would be nice to get this committed into crypto/rsa but I'm definitely not a cryptographer :P

Is there enough custom cryptography in the server to warrant breaking out to another library?

For what it's worth, on a tangentially related topic, I'd rather chef-golang not have any dependencies outside of the standard library (as it does now) if we can help it. However, I would be totally down to do it and take the github.com/coreos/etcd third-party directory approach, just so it's all bundled together.

[spheromak]

yea i think when we start using external deps we will want to vendor. there are a few tools for that. @ctdk @marpaia there might even be a go-chef org we could use to handle the server/client-api/client and other supporting stuff if we get to that point.

[spheromak]

I got the idea of pulling the crypto out cause thats what @ctdk has pretty much started here: https://github.com/ctdk/goiardi/tree/master/chef_crypto He implemented the other side of the crypto.

I agree that it would be much better for that bit of stuff to be upstream tho.

[marpaia]

That's pretty funny :) literally implemented the opposite sides of the crypto system

[ctdk]

Yeah, much the same way you found crypto/rsa didn't have the rsa_private_encrypt function you needed, it didn't have the rsa_private_decrypt either. Funny, that.

There might be some other areas with crypto that chef-golang and goiardi have in common too, with generating the signed headers and such, that we should at least coordinate even if they don't end up sharing a library in common. I'm not as worried about dependencies since that ship's already sailed on my end.

[spheromak]

common request signing would be very good.

[marpaia]

We had to implement this functionality because of a lack of parity in OpenSSL and crypto/rsa. Obviously it was by design to ditch OpenSSL in Go and that has proved to be a good decision. I still feel as though that it wouldn't hurt to add PrivateEncrypt (from this repo) and the equivalent PrivateDecrypt to Go source in an effort to add rsa_private_encrypt and rsa_private_decrypt to crypto/rsa.

Then, in our case at least, we wouldn't need any third party libs or external packages for crypto at all. Thoughts?

Alternatively, we could just take all of the crypto out of both repos and make a single repo that we both use and maintain?

[ctdk]

I assumed an independent crypto library that both chef-golang and goiardi could use was what @spheromak had in mind.

[spheromak]

that was my thought, but also if we can get a patch in on crypto/rsa that would be great.