This change merges in Daniel Palacio's updates to support a ":salt" option (from https://github.com/danpal/encryptor) but modifies the "crypt" method to fall back to "compatibility mode" (i.e. the existing behaviour) if this option is not specified. This means that existing users of the gem can continue to use it without making any changes to their code and can opt into the extended functionality by adding the ":salt" option to their code in the future. This change also adds compatibility tests to ensure that encrypted values created using previous versions of the gem will roundtrip if the user updates to newer versions. This is intended to detect breaking changes in the API, for example.
I would be really pleased if you could merge this pull request into shuber/encryptor as this will form the basis of a new version of shuber/attr_encrypted I am working on that will support this strong encryption scheme. It might back sense to bump the minor version too.
This change merges in Daniel Palacio's updates to support a ":salt" option (from https://github.com/danpal/encryptor) but modifies the "crypt" method to fall back to "compatibility mode" (i.e. the existing behaviour) if this option is not specified. This means that existing users of the gem can continue to use it without making any changes to their code and can opt into the extended functionality by adding the ":salt" option to their code in the future. This change also adds compatibility tests to ensure that encrypted values created using previous versions of the gem will roundtrip if the user updates to newer versions. This is intended to detect breaking changes in the API, for example.
I would be really pleased if you could merge this pull request into shuber/encryptor as this will form the basis of a new version of shuber/attr_encrypted I am working on that will support this strong encryption scheme. It might back sense to bump the minor version too.