Skip to content

Use the exactly 32 byte long version of db_key_base with aes-256-gcm

Kim Lindberger requested to merge talyz/gitlab:master into master

What does this MR do?

Treewide, usage of a truncated version of db_key_base has been common and it works fairly well with aes-256-cbc. However, with aes-256-gcm the key must be exactly 32 bytes long - if it's longer it has to be truncated, but if it's shorter it has to be padded. For this reason the such a version of the key, attr_encrypted_db_key_base_32, was introduced in 777b6713. This changes all occurrences of attr_encrypted_db_key_base_truncated being used with aes-256-gcm.

I ran into this issue when trying to upgrade our local instance of GitLab, which used a key shorter than 32 bytes. Unfortunately, there's no easy way to rotate the key, as far as I know, so until there is, shorter keys need to keep working for us.

/cc @gitlab-com/gl-security/appsec

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team
Edited by Kim Lindberger

Merge request reports

Loading