Skip to content
  • Donal McBreen's avatar
    1d996ee0
    Fix binary decryption on Postgres · 1d996ee0
    Donal McBreen authored
    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 types 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 is doesn't 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 https://github.com/rails/rails/pull/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.
    1d996ee0
    Fix binary decryption on Postgres
    Donal McBreen authored
    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 types 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 is doesn't 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 https://github.com/rails/rails/pull/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.
Loading