| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
If one created Rails 5.1 app and then updated to 5.2,
`secret_key_base` defined in `config/secrets.yml` is ignored for
`development` and `test` environment.
A change in `secret_key_base` in turn breaks
`Rails.application.key_generator`.
If one encrypt data in Rails 5.1, she cannot decrypt it in Rails 5.2
for `development` and `test` environment.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because the UJS library creates a script tag to process responses it
normally requires the script-src attribute of the content security
policy to include 'unsafe-inline'.
To work around this we generate a per-request nonce value that is
embedded in a meta tag in a similar fashion to how CSRF protection
embeds its token in a meta tag. The UJS library can then read the
nonce value and set it on the dynamically generated script tag to
enable it to execute without needing 'unsafe-inline' enabled.
Nonce generation isn't 100% safe - if your script tag is including
user generated content in someway then it may be possible to exploit
an XSS vulnerability which can take advantage of the nonce. It is
however an improvement on a blanket permission for inline scripts.
It is also possible to use the nonce within your own script tags by
using `nonce: true` to set the nonce value on the tag, e.g
<%= javascript_tag nonce: true do %>
alert('Hello, World!');
<% end %>
Fixes #31689.
|
|
|
|
|
|
|
|
|
| |
To prevent errors from being raise in environments where credentials
is unnecessary.
Context: https://github.com/rails/rails/issues/31283#issuecomment-348801489
Fixes #31283
|
|
|
|
| |
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
|
|
|
|
|
| |
Own style guide says we should be using parentheses for method calls
with arguments.
|
| |
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To edit/show encrypted file:
```
bin/rails encrypted:edit config/staging_tokens.yml.enc
bin/rails encrypted:edit config/staging_tokens.yml.enc --key config/staging.key
bin/rails encrypted:show config/staging_tokens.yml.enc
```
Also provides a backing Rails.application.encrypted API for Ruby access:
```ruby
Rails.application.encrypted("config/staging_tokens.yml.enc").read
Rails.application.encrypted("config/staging_tokens.yml.enc").config
Rails.application.encrypted("config/staging_tokens.yml.enc", key: "config/staging.key")
```
|
|
|
|
| |
This basically reverts 618268b4b9382f4bcf004a945fe2d85c0bd03e32
|
|
|
|
|
|
|
|
|
|
| |
See the changelog entry.
Remove `secrets.secret_token` from the bug report templates,
since we don't accept bug reports for Rails versions that
don't support a `secret_key_base`.
[ claudiob & Kasper Timm Hansen ]
|
|
|
|
|
|
| |
Using the action_dispatch.cookies_rotations interface, key rotation is
now possible with cookies. Thus the secret_key_base as well as salts,
ciphers, and digests, can be rotated without expiring sessions.
|
|
|
|
|
|
| |
Both classes now have a rotate method where new instances are added for
each call. When decryption or verification fails the next rotation
instance is tried.
|
|
|
|
|
|
|
| |
Removes most mentions of secrets.secret_key_base and explains
credentials instead.
Also removes some very stale upgrade notices about Rails 3/4.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* WIP: Add credentials using a generic EncryptedConfiguration class
This is sketch code so far.
* Flesh out EncryptedConfiguration and test it
* Better name
* Add command and generator for credentials
* Use the Pathnames
* Extract EncryptedFile from EncryptedConfiguration and add serializers
* Test EncryptedFile
* Extract serializer validation
* Stress the point about losing comments
* Allow encrypted configuration to be read without parsing for display
* Use credentials by default and base them on the master key
* Derive secret_key_base in test/dev, source it from credentials in other envs
And document the usage.
* Document the new credentials setup
* Stop generating the secrets.yml file now that we have credentials
* Document what we should have instead
Still need to make it happen, tho.
* [ci skip] Keep wording to `key base`; prefer defaults.
Usually we say we change defaults, not "spec" out a release.
Can't use backticks in our sdoc generated documentation either.
* Abstract away OpenSSL; prefer MessageEncryptor.
* Spare needless new when raising.
* Encrypted file test shouldn't depend on subclass.
* [ci skip] Some woordings.
* Ditch serializer future coding.
* I said flip it. Flip it good.
* [ci skip] Move require_master_key to the real production.rb.
* Add require_master_key to abort the boot process.
In case the master key is required in a certain environment
we should inspect that the key is there and abort if it isn't.
* Print missing key message and exit immediately.
Spares us a lengthy backtrace and prevents further execution.
I've verified the behavior in a test app, but couldn't figure the
test out as loading the app just exits immediately with:
```
/Users/kasperhansen/Documents/code/rails/activesupport/lib/active_support/testing/isolation.rb:23:in `load': marshal data too short (ArgumentError)
from /Users/kasperhansen/Documents/code/rails/activesupport/lib/active_support/testing/isolation.rb:23:in `run'
from /Users/kasperhansen/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/minitest-5.10.2/lib/minitest.rb:830:in `run_one_method'
from /Users/kasperhansen/.rbenv/versions/2.4.1/lib/ruby/gems/2.4.0/gems/minitest-5.10.2/lib/minitest/parallel.rb:32:in `block (2 levels) in start'
```
It's likely we need to capture and prevent the exit somehow.
Kernel.stub(:exit) didn't work. Leaving it for tomorrow.
* Fix require_master_key config test.
Loading the app would trigger the `exit 1` per require_master_key's
semantics, which then aborted the test.
Fork and wait for the child process to finish, then inspect the
exit status.
Also check we aborted because of a missing master key, so something
else didn't just abort the boot.
Much <3 to @tenderlove for the tip.
* Support reading/writing configs via methods.
* Skip needless deep symbolizing.
* Remove save; test config reader elsewhere.
* Move secret_key_base check to when we're reading it.
Otherwise we'll abort too soon since we don't assign the secret_key_base
to secrets anymore.
* Add missing string literal comments; require unneeded yaml require.
* ya ya ya, rubocop.
* Add master_key/credentials after bundle.
Then we can reuse the existing message on `rails new bc4`.
It'll look like:
```
Using web-console 3.5.1 from https://github.com/rails/web-console.git (at master@ce985eb)
Using rails 5.2.0.alpha from source at `/Users/kasperhansen/Documents/code/rails`
Using sass-rails 5.0.6
Bundle complete! 16 Gemfile dependencies, 72 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
Adding config/master.key to store the master encryption key: 97070158c44b4675b876373a6bc9d5a0
Save this in a password manager your team can access.
If you lose the key, no one, including you, can access anything encrypted with it.
create config/master.key
```
And that'll be executed even if `--skip-bundle` was passed.
* Ensure test app has secret_key_base.
* Assign secret_key_base to app or omit.
* Merge noise
* Split options for dynamic delegation into its own method and use deep symbols to make it work
* Update error to point to credentials instead
* Appease Rubocop
* Validate secret_key_base when reading it.
Instead of relying on the validation in key_generator move that into
secret_key_base itself.
* Fix generator and secrets test.
Manually add config.read_encrypted_secrets since it's not there by default
anymore.
Move mentions of config/secrets.yml to config/credentials.yml.enc.
* Remove files I have no idea how they got here.
* [ci skip] swap secrets for credentials.
* [ci skip] And now, changelogs are coming.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit changes encrypted cookies from AES in CBC HMAC mode to
Authenticated Encryption using AES-GCM. It also provides a cookie jar
to transparently upgrade encrypted cookies to this new scheme. Some
other notable changes include:
- There is a new application configuration value:
+use_authenticated_cookie_encryption+. When enabled, AEAD encrypted
cookies will be used.
- +cookies.signed+ does not raise a +TypeError+ now if the name of an
encrypted cookie is used. Encrypted cookies using the same key as
signed cookies would be verified and serialization would then fail
due the message still be encrypted.
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, `read_encrypted_secrets` is set with initializer.
Therefore if refer to `secrets` in config, `read_encrypted_secrets` is false,
so can not get the value of `secrets.yml.enc`.
In order to be able to refer to secrets in config, modified to refer to
`config.read_encrypted_secrets` when calling `secrets`.
Fixes #28618.
|
| |
|
| |
|
| |
|
|
|
|
| |
(I personally prefer writing one string in one line no matter how long it is, though)
|
|
|
|
| |
[ci skip]
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inherits from Rails::Application
Until Rails 4.1, `before_configuration` run as soon as the application constant
inherits from `Rails::Application`.
However, in d25fe31c40928712b5e08fe0afb567c3bc88eddf, it has been modified to
run at instantiation process.
This modify to `before_configuration` is run at same timing as to Rails 4.1.
Fixes #19880
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
| |
environments
|
|
|
|
|
| |
Idiomatically trailing hashes in method calls do not use
explicit curlies.
|
|
|
|
|
|
| |
With the exception of what is loaded in active_support/rails,
each file is responsible for its own dependencies. You cannot
rely on runtime order of execution.
|
|
|
|
| |
Adding period in the end.
|
|
|
|
|
|
| |
These should allow external code to run blocks of user code to do
"work", at a similar unit size to a web request, without needing to get
intimate with ActionDipatch.
|
|
|
|
|
|
| |
s/config\/production/config\/environments\/production/
[ci skip]
|
|
|
|
| |
That would make possible to use it with action cable configuration.
|
| |
|
|
|
|
|
|
|
| |
If `SECRET_KEY_BASE` or other `secret` gets passed as other then string
we need to raise `ArgumentError` to know that it's a wrong argument.
Closes #22072
|
|\ |
|
| | |
|
| | |
|
|/
|
|
|
| |
We shouldn't merge the app middleware in to the config middleware for
engines.
|
|
|
|
|
|
|
|
|
| |
Stems from https://github.com/rails/rails/pull/20105#issuecomment-100900939
where @senny said:
> From my point of view, all the docs (guides, API) are version bound.
> They should describe that version and continue to be available when newer versions are released.
> The cross referencing can be done by the interested user.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Removing `#build_original_fullpath` because it is no longer
used by the Rails' source code or called in the `#call` method becasue
the previous commit now uses `fullpath` from Rack.
The method was nodoc'ed so it's safe to remove.
NOTE: I did this as a separate commit so if this does cause a problem
with engines etc reverting is easy.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Rack, `#fullpath` checks if there is a query string and builds the
query correctly:
```
def path
script_name + path_info
end
def fullpath
query_string.empty? ? path : "#{path}?#{query_string}"
end
```
We can utilize this instead of manually building the fullpath because
they are the same result. This also reduces allocations in `#call`
because we don't need `build_original_fullpath` to create the paths and
query strings. We don't need to build `fullpath` twice.
|
|
|
|
|
|
| |
* Fix a few typos
* Wrap some lines around 80 chars
* Rephrase some statements
|
| |
|
|
|
|
|
| |
A special `if` statement to support `Psych` for Ruby < 2.0 can be
dropped now that Rails requires Ruby >= 2.0.
|
| |
|