forked from rails/rails
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
When encrypting attributes we need to do it just before inserting the data into the database, so after any other serialization steps, e.g. for serialized types or normalization. And we need things to happen in reverse order when decrypting. With attribute decoration we end up with initial type nested in other types. To ensure that the encryption happens in the right place, the EncryptedAttributeType first serializes the value with the type it is wrapping and then encrypts it. And in reverse it decrypts then deserializes with the wrapped type. There's an assumption here, which is that the wrapped type doesn't need to do anything in between the database and the encryption layer - so any database specific casting is skipped. This works fine for String columns as there's nothing for them to do. It also works for binary columns for MySQL and SQLite. But not for PostgreSQL which needs to receive the data as Binary::Data and has to call `PG::Connection.unescape_bytea` when deserializing the data. The serialization part was fixed in rails#50920, where the encryption output is wrapped in Binary::Data, which let's the PostgreSQL adapter know to convert the value [here](https://github.com/rails/rails/blob/5a0b2fa5a3be6ffd49fa7f1c3544c1da403c9cb5/activerecord/lib/active_record/connection_adapters/abstract/quoting.rb#L83). That PR however didn't fix deserializing the data when it comes back out of the database (it wasn't round-tripping the data properly in the tests). We need to deserialize binary types before decrypting them - and we'll have to just assume that the wrapped type can do that for us. This won't work for serialized types as they'll also attempt to convert the data with the coder which needs to happen after decryption, so we need to special case them and extract the subtype instead. This isn't ideal but it should work ok for all built in types. But if you have a custom binary type that does something that needs to happen both before and after decryption then it may not work as expected. I think that's a rare case though and it's more important to have encryption of binary types working on PostgreSQL.
- Loading branch information
Showing
5 changed files
with
79 additions
and
9 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters