ArgumentError (key must be 32 bytes) with Ruby 2.4.1

[bspellacy]

Shipit Version: 0.18.1
Ruby Version: ruby 2.4.1p111

Context
While upgrading from Shipit v0.14.0 to v0.18.1 I encountered the following error when visiting the root of the engine. I believe this has to do with the fact that the keys are not being truncated to 32 bytes, which before Ruby 2.4 wasn't an issue, I've noticed in the dev.yml you're using v2.2.x.

They had a comparable issue in Rails: rails/rails#25192 although our issue stems from the attr_encrypted gem.

I think just truncating the returned value of this method would be the quickest fix.

Thoughts? Is Shopify interested in supported > Ruby 2.2 with Shipit?

Partial Stack Trace

ArgumentError (key must be 32 bytes):

encryptor (3.0.0) lib/encryptor.rb:72:in `key='
encryptor (3.0.0) lib/encryptor.rb:72:in `crypt'
encryptor (3.0.0) lib/encryptor.rb:36:in `encrypt'
attr_encrypted (3.0.3) lib/attr_encrypted.rb:259:in `encrypt'
attr_encrypted (3.0.3) lib/attr_encrypted.rb:337:in `encrypt'
attr_encrypted (3.0.3) lib/attr_encrypted.rb:159:in `block (2 levels) in attr_encrypted'
attr_encrypted (3.0.3) lib/attr_encrypted/adapters/active_record.rb:76:in `block in attr_encrypted'
activemodel (5.1.1) lib/active_model/attribute_assignment.rb:46:in `public_send'
activemodel (5.1.1) lib/active_model/attribute_assignment.rb:46:in `_assign_attribute'
activemodel (5.1.1) lib/active_model/attribute_assignment.rb:40:in `block in _assign_attributes'
activemodel (5.1.1) lib/active_model/attribute_assignment.rb:39:in `each'
activemodel (5.1.1) lib/active_model/attribute_assignment.rb:39:in `_assign_attributes'
activerecord (5.1.1) lib/active_record/attribute_assignment.rb:26:in `_assign_attributes'
activemodel (5.1.1) lib/active_model/attribute_assignment.rb:33:in `assign_attributes'
attr_encrypted (3.0.3) lib/attr_encrypted/adapters/active_record.rb:29:in `perform_attribute_assignment'
attr_encrypted (3.0.3) lib/attr_encrypted/adapters/active_record.rb:36:in `assign_attributes'
activerecord (5.1.1) lib/active_record/persistence.rb:284:in `block in update'
activerecord (5.1.1) lib/active_record/transactions.rb:384:in `block in with_transaction_returning_status'
activerecord (5.1.1) lib/active_record/connection_adapters/abstract/database_statements.rb:225:in `block in transaction'
activerecord (5.1.1) lib/active_record/connection_adapters/abstract/transaction.rb:194:in `block in within_new_transaction'
/Users/brennanspellacy/.rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/monitor.rb:214:in `mon_synchronize'
activerecord (5.1.1) lib/active_record/connection_adapters/abstract/transaction.rb:191:in `within_new_transaction'
activerecord (5.1.1) lib/active_record/connection_adapters/abstract/database_statements.rb:225:in `transaction'
activerecord (5.1.1) lib/active_record/transactions.rb:210:in `transaction'
activerecord (5.1.1) lib/active_record/transactions.rb:381:in `with_transaction_returning_status'
activerecord (5.1.1) lib/active_record/persistence.rb:283:in `update'
shipit-engine (0.18.1) app/controllers/shipit/github_authentication_controller.rb:25:in `sign_in_github'
shipit-engine (0.18.1) app/controllers/shipit/github_authentication_controller.rb:11:in `callback'

[byroot]

I don't think it's due to 2.4, even though I haven't tested it yet.

IIRC in v0.14.0 we were using an older version of attr_encrypted, and it now requires a longer key.

I'd say just put a print here:

shipit-engine/app/models/shipit/user.rb

Line 11 in 7672980

attr_encrypted :github_access_token, key: Shipit.user_access_tokens_key

to check how long your key is. I'm pretty sure attr_encrypted requires at least 32 bytes, but you can give it more.

We default it to your secret key_base, and pre 5.0 Rails generated a smaller one.

[bspellacy]

I've tried with longer keys and is still raises. It seems to only work exactly when the key is 32 bytes.

Hmm based on some digging I think it's related to this addition to ruby: ruby/ruby@ce63526

More discussion can be related to attr_encrypted and encryptor can be seen here: attr-encrypted/encryptor#26

[byroot]

Interesting, you were right then :)

I'll dig into this on monday unless you submit a PR first.

[casperisfine]

Fixed in #706