I reviewed barbican version 1:2.0.0-0ubuntu1; this shouldn't be considered a full audit, but rather a quick gauge of maintainability.
Barbican appeared to be developed to professional standards but it feels like it's still making larger architectural decisions and I'm not sure who the consumers of Barbican are supposed to be. There's more than the usual amount of TODO notes. It's nice to know the developers have thought through their goals enough to add notes to the future but it gives the impression that there's a lot of changes, perhaps changes that will influence consumers. I couldn't tell if Barbican is intended for use only by OpenStack services or if it is intended for use by the applications and management infrastructure that individual tenants would use. I couldn't tell if Barbican is actually intended to be used on systems without hardware security modules to provide backing storage. There is a simple_crypto_plugin that provides much of the functionality of the HSM wrappers but the docstring for the class indicates that it's "insecure". This simple_crypto_plugin (intends) to store all secrets in the databases using a key hardcoded in the sources or a key in /etc/barbican/barbican.conf -- which also appears to be hard-coded in our installation, rather than generated at install or first run. crypto.py SYMMETRIC_ALGORITHMS, SYMMETRIC_KEY_LENGTHS, and ASYMMETRIC_KEY_LENGTHS -- includes vastly unsafe DES, vastly unsafe 64 bit length symmetric keys, and unsafe 1024 bit length asymmetric keys. Secrets are documented to be stored with per-tenant encryption keys but I did not see a way for the tenants to supply the decryption keys; those per-tenant keys are probably stored in the database and protected solely by the kek configured in barbican.conf. Access to secrets within a tenant's storage can apparently be scoped using ACLs to any keystone-ids, but I didn't see any documentation or recommendation that e.g. user services should have their own keystone authentication mechanisms, nor how it would be accomplished. This is definitely a grey area. - Will future modifications cause compatibility problems? - This secret storage is best considered "obfuscation" rather than "encrypted". If all the keys are available in the sources or a configuration file, no amount of intermediate steps makes them safe. Perhaps this is why the simple_crypto_plugin is labeled "insecure", perhaps secrets are only stored privately when using an HSM. If an HSM is the only safe way to store secrets, why even have an "insecure" mode? So while this code looks professionally written I'm concerned that it may give a false sense of safety when storing keys and it may not have matured to the point of API or storage stability yet. I'd be more worried about promoting barbican to main for an LTS release; we still have a few releases for it to mature, so the risk doesn't feel overwhelming. So, do we still want barbican? Thanks -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1543754 Title: [MIR] barbican, python-pykmip To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/barbican/+bug/1543754/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
