Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New app: "key must be 32 bits". #25185

Closed
elieteyssedou opened this issue May 28, 2016 · 30 comments
Closed

New app: "key must be 32 bits". #25185

elieteyssedou opened this issue May 28, 2016 · 30 comments

Comments

@elieteyssedou
Copy link

Steps to reproduce

Run rails s. No more... (new app)

Expected behavior

It should display my index.

Actual behavior

It fails.

Here is what is going wrong:
capture d ecran 2016-05-28 a 21 18 13

Can you help me? Don't understand at all.

System configuration

Rails version: 5.0.0.rc1

Ruby version: 2.4.0dev

@maclover7
Copy link
Contributor

Hmm, after some digging in some C code (💀), looks like there is a new breaking change in OpenSSL, which rejects certain values for key=, which is the bug you are running into. :(

Looking into fixes.

@Fudoshiki
Copy link
Contributor

Fudoshiki commented Jun 21, 2016

Same issue (Rails 5.1.0.alpha1, ruby-2.4.preview1)

@bisonhubert
Copy link

I was having this issue yesterday. Very frustrating. Today I tried using bundle install without the exclusion of the production environment, and the error message is no longer coming up when I view localhost:3000/users.

@jeremy
Copy link
Member

jeremy commented Jun 27, 2016

Fixed by #25192

@jeremy jeremy closed this as completed Jun 27, 2016
vipulnsward added a commit to vipulnsward/rails that referenced this issue Jun 28, 2016
…t can accept key lengths of 128, 192 or 256-bit, whereas currently we were providing twice the acceptable value.

ruby < 2.4 allowed accepting these values, as extra key bits were ignored. Since ruby/ruby@ce63526 this now has a strict checking on key length.

Default to key length 32 bytes, to match the compatible length for  aes-256-cbc

Fixes rails#25185
@elieteyssedou
Copy link
Author

Thank you ! 👍

@slhck
Copy link

slhck commented Jul 25, 2016

I'm still seeing this issue – freshly installed Ruby 2.4.0-dev and Rails 5.0.0.

Any idea what the problem could be?

koic pushed a commit to koic/rails that referenced this issue Aug 18, 2016
…t can accept key lengths of 128, 192 or 256-bit, whereas currently we were providing twice the acceptable value.

ruby < 2.4 allowed accepting these values, as extra key bits were ignored. Since ruby/ruby@ce63526 this now has a strict checking on key length.

Default to key length 32 bytes, to match the compatible length for  aes-256-cbc

Fixes rails#25185
@schneems
Copy link
Member

schneems commented Sep 6, 2016

Temporary solution is to use Ruby 2.3.1. We'll need that patch to be backported to Rails 5 though before Christmas cc/ @vipulnsward

@vipulnsward
Copy link
Member

It has been fixed by #25758 and backported in 15a972e

@schneems
Copy link
Member

schneems commented Sep 7, 2016

❤️ ❤️ ❤️

@jonlumb
Copy link

jonlumb commented Oct 3, 2016

Still experiencing this issue running Ruby 2.4.0preview2 and Rails 5.0.0.1

The "Welcome to Rails" index screen works, but problems occur as soon as I attempt to access a scaffold that I've generated.

@Marthyn
Copy link

Marthyn commented Oct 20, 2016

Fixed it with using the master branch. But Ruby 2.4.0preview2 and Rails 5.0.0.1 definitely does not work.

@guilleiguaran
Copy link
Member

@Marthyn what about branch 5-0-stable?

ojiry pushed a commit to ojiry/rails that referenced this issue Nov 9, 2016
…t can accept key lengths of 128, 192 or 256-bit, whereas currently we were providing twice the acceptable value.

ruby < 2.4 allowed accepting these values, as extra key bits were ignored. Since ruby/ruby@ce63526 this now has a strict checking on key length.

Default to key length 32 bytes, to match the compatible length for  aes-256-cbc

Fixes rails#25185
@jbae995
Copy link

jbae995 commented Jan 18, 2017

Hey Rafael,
in the screenshots attached, at my desktop it says i am running 5.0.1, then on my unisports directory (which is the app im trying to run on the rails server) it shows 5.0.0.1. I have also tried upgrading to 5.0.1 in the unisports directory (but as shown in the screenshot, it says "success", but then when i check rails -v again, it says i have 5.0.0.1 running....

Sorry about the constant questions and Thanks for the help!

screen shot 2017-01-18 at 1 18 39 pm

screen shot 2017-01-18 at 1 16 36 pm

@cpapidas
Copy link

cpapidas commented Feb 1, 2017

The problem is about the ruby 2.4.0, just for now if you want a quick solution use ruby 2.3.1

@kshyam
Copy link

kshyam commented Feb 15, 2017

I have got the same issue, while updating my ruby version and rails version.
@cpapidas : Thanks for your suggestion, I thought the same and changed my ruby version form 2.4.0 to 2.3.1 and it worked fine.

iwz pushed a commit to iwz/rails that referenced this issue Feb 15, 2017
We default to using aes-256-cbc as our verification/signing cipher.
It can accept key lengths of 128, 192 or 256-bit, whereas currently we
were providing twice the acceptable value.

ruby < 2.4 allowed accepting these values, as extra key bits were
ignored. Since ruby/ruby@ce63526 this now has a strict checking on key
length.

Default to key length 32 bytes, to match the compatible length for
aes-256-cbc

Backport to Rails 4.2.8 of fix for rails#25185

Credit to @vipulnsward

See: rails#25192
iwz added a commit to iwz/rails that referenced this issue Feb 15, 2017
We default to using aes-256-cbc as our verification/signing cipher.
It can accept key lengths of 128, 192 or 256-bit, whereas currently we
were providing twice the acceptable value.

ruby < 2.4 allowed accepting these values, as extra key bits were
ignored. Since ruby/ruby@ce63526 this now has a strict checking on key
length.

Default to key length 32 bytes, to match the compatible length for
aes-256-cbc

Backport to Rails 4.2.8 of fix for rails#25185

Credit to @vipulnsward, @matthewd

See: rails#25192
See: rails#25602
@matheussilvasantos
Copy link

I was using ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux] with rails 5.0.0.1. I update rails to 5.0.1 and it is fine now.

@benoittgt
Copy link
Contributor

 🚴  » rails -v
Rails 4.2.8
 🚴  » ruby -v
ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-darwin14]

Lot's of fails during tests :

      ArgumentError:
        key must be 32 bytes
      # /Users/bti/.rvm/gems/ruby-2.4.0/gems/activesupport-4.2.8/lib/active_support/message_encryptor.rb:79:in `key='
      # /Users/bti/.rvm/gems/ruby-2.4.0/gems/activesupport-4.2.8/lib/active_support/message_encryptor.rb:79:in `_encrypt'
      # /Users/bti/.rvm/gems/ruby-2.4.0/gems/activesupport-4.2.8/lib/active_support/message_encryptor.rb:60:in `encrypt_and_sign'

@benoittgt
Copy link
Contributor

Error is correct. We have a key size at 128. Sorry

@AlexCppns
Copy link

The whole thread assumes a ruby version of 2.4.0 but we are having the problem with ruby 2.3.3 and rails 4.2.3. We truncated the key...

@benoittgt
Copy link
Contributor

@AlexCppns Maybe you should check #28401

@AlexCppns
Copy link

@benoittgt I couldn't relate to your link, however we upgraded to ruby 2.4.0/rails 4.2.8 and with the truncation trick, our app seems to be running again... touching wood.

@codeinaire
Copy link

I'm not sure if this will help anyone. I was having the same error and I ran $ bundle update to update my gem files and it also updated to the latest version of rails. This fixed the problem.

@wisetara
Copy link

One of my gems was using the encryptor gem as a dependency, and if it went above 1.3.0, this happened. Added encryptor to my Gemfile, locked it at 1.3.0, and all is good again.

Ruby 2.3.4/Rails 5.0.1 (and Rails 4.2)

rbf added a commit to basimilch/basimilch-app that referenced this issue Aug 18, 2017
seanpdoyle added a commit to thoughtbot/ember-cli-rails that referenced this issue Mar 30, 2018
seanpdoyle added a commit to thoughtbot/ember-cli-rails that referenced this issue Mar 30, 2018
AdrianCann added a commit to sophomoric/secret that referenced this issue Jul 1, 2018
rails/rails#25185
maclover7:
```
Hmm, after some digging in some C code (💀), looks like there is a new breaking change in OpenSSL, which rejects certain values for key=, which is the bug you are running into. :(
```
AdrianCann added a commit to sophomoric/secret that referenced this issue Jul 1, 2018
rails/rails#25185
maclover7:
```
Hmm, after some digging in some C code (💀), looks like there is a new breaking change in OpenSSL, which rejects certain values for key=, which is the bug you are running into. :(
```
AdrianCann added a commit to sophomoric/secret that referenced this issue Jul 1, 2018
rails/rails#25185
maclover7:
```
Hmm, after some digging in some C code (💀), looks like there is a new breaking change in OpenSSL, which rejects certain values for key=, which is the bug you are running into. :(
```
@rikbw
Copy link

rikbw commented Jul 17, 2018

I still have the same issue when upgrading from ruby version 2.2.8 to 2.5.1. My rails version is 5.1.5. I have a key that has a size of 40 bytes. Is this considered an issue with rails and will this be patched in future versions or not?

@iarobinson
Copy link
Contributor

I was experiencing this issue earlier my solution is described beneath the heading element at the bottom of this comment.

screen shot 2018-09-20 at 7 53 50 am

Rails and Ruby version:

$ ruby -v 
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17]
$ rails -v
Rails 5.0.7

Stack trace:

activesupport (5.0.0) lib/active_support/message_encryptor.rb:72:in `key='
activesupport (5.0.0) lib/active_support/message_encryptor.rb:72:in `_encrypt'
activesupport (5.0.0) lib/active_support/message_encryptor.rb:58:in `encrypt_and_sign'
actionpack (5.0.0) lib/action_dispatch/middleware/cookies.rb:592:in `commit'
actionpack (5.0.0) lib/action_dispatch/middleware/cookies.rb:465:in `[]='
actionpack (5.0.0) lib/action_dispatch/middleware/session/cookie_store.rb:117:in `set_cookie'
rack (2.0.1) lib/rack/session/abstract/id.rb:353:in `commit_session'
rack (2.0.1) lib/rack/session/abstract/id.rb:224:in `context'
rack (2.0.1) lib/rack/session/abstract/id.rb:216:in `call'
actionpack (5.0.0) lib/action_dispatch/middleware/cookies.rb:613:in `call'
activerecord (5.0.0) lib/active_record/migration.rb:552:in `call'
actionpack (5.0.0) lib/action_dispatch/middleware/callbacks.rb:38:in `block in call'
activesupport (5.0.0) lib/active_support/callbacks.rb:97:in `__run_callbacks__'
activesupport (5.0.0) lib/active_support/callbacks.rb:750:in `_run_call_callbacks'
activesupport (5.0.0) lib/active_support/callbacks.rb:90:in `run_callbacks'
actionpack (5.0.0) lib/action_dispatch/middleware/callbacks.rb:36:in `call'
actionpack (5.0.0) lib/action_dispatch/middleware/executor.rb:12:in `call'
actionpack (5.0.0) lib/action_dispatch/middleware/remote_ip.rb:79:in `call'
actionpack (5.0.0) lib/action_dispatch/middleware/debug_exceptions.rb:49:in `call'
actionpack (5.0.0) lib/action_dispatch/middleware/show_exceptions.rb:31:in `call'
railties (5.0.0) lib/rails/rack/logger.rb:36:in `call_app'
railties (5.0.0) lib/rails/rack/logger.rb:24:in `block in call'
activesupport (5.0.0) lib/active_support/tagged_logging.rb:70:in `block in tagged'
activesupport (5.0.0) lib/active_support/tagged_logging.rb:26:in `tagged'
activesupport (5.0.0) lib/active_support/tagged_logging.rb:70:in `tagged'
railties (5.0.0) lib/rails/rack/logger.rb:24:in `call'
sprockets-rails (3.1.1) lib/sprockets/rails/quiet_assets.rb:13:in `call'
actionpack (5.0.0) lib/action_dispatch/middleware/request_id.rb:24:in `call'
rack (2.0.1) lib/rack/method_override.rb:22:in `call'
rack (2.0.1) lib/rack/runtime.rb:22:in `call'
activesupport (5.0.0) lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
actionpack (5.0.0) lib/action_dispatch/middleware/executor.rb:12:in `call'
actionpack (5.0.0) lib/action_dispatch/middleware/static.rb:136:in `call'
rack (2.0.1) lib/rack/sendfile.rb:111:in `call'
railties (5.0.0) lib/rails/engine.rb:522:in `call'
puma (3.6.0) lib/puma/configuration.rb:225:in `call'
puma (3.6.0) lib/puma/server.rb:578:in `handle_request'
puma (3.6.0) lib/puma/server.rb:415:in `process_client'
puma (3.6.0) lib/puma/server.rb:275:in `block in run'
puma (3.6.0) lib/puma/thread_pool.rb:116:in `block in spawn_thread'

Running bundle update was the key. I upgraded Ruby from 2.0 to 2.5.1 yesterday so that may have played a role. Here's the terminal readout of the successful update which solved the problem:

screen shot 2018-09-20 at 8 04 50 am

How I Got it Running Locally

I ran bundle install then I followed up with bundle update.

Then I reset the server (CMD+C then rails s)

After updating bundle, I forgot to restart the server and spent a few minutes researching the error needlessly. So.... restarting the server is important. 🥇

My motivation for putting this solution here is that I found this thread while seeking a solution to the error. The above conversation is helpful for understanding how problems in Rails are diagnosed. There was no specific solution for a young Rails developer like myself.

buermann added a commit to buermann/introspective_grape that referenced this issue Mar 22, 2019
@mvondoyannick
Copy link

Hi, have the same issue on rails 7.0.4 and ruby 3.1.2

$ ruby -v
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]
$ rails -v
Rails 7.0.4

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests