[p11_crypto_plugin] mkek_length has no default but the logic uses
implicit default value (32) internally.
Change-Id: I8743457aab9f0ce4982fcb9255dc86050b791308
Since we removed certificate order, we no longer have to maintain
these logics.
This also removes the release note for deprecation of symantec
certificate plugin, which was added during this cycle, because
the plugin is also being removed by this change.
Change-Id: I8e901024677e889d05ad8653389fb46487bc7745
It was announced that this resource will be removed in Pike release.
Multiple cycles have passed since then, so we may be really ready to
remove it.
Note that this is the first step and removes only API layer logic.
Further logic removal will be done in the subsequent change.
Change-Id: Ib0eb3b11815b40237d42735097076b7c89cf9516
Currently Barbican is not using the periodic_task framework implemented
in oslo_service but implements its own mechanism based on the lower-
level thread group.
Change-Id: Idc69d61e07826923f3227aad6249252c3f739362
Barbican does not provide wsgi server based on oslo.service library,
thus these options are not used.
Change-Id: I74c67b61796bcc7e5418144b10134e6171b1777f
This was removed [1] recently and is preventing us bumping the upper
constraint.
[1] 0035c11382
Change-Id: I77debbfa35a8eeeb30ce83a32954da21d9c9ba62
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Currently Barbican is not using oslo.db to set up database connection
but it's own implementation directly using sqlalchemy. Because of this
the database parameters were not updated and these are based on
the names in quite old oslo.db library.
This change updates the database options so that the name of these
parameters become consistent with oslo.db.
This would help us replace current own implementation by oslo.db in
the future.
Change-Id: I36926e62842780068f7e66564233c121c37565d0
This plugin has never been updated for 7 years. This plugin requires
the symantecssl library but the library can't be found in the Internet
and is not generally available. We have never tested it in upstream
CI because of lack of that dependent library.
Change-Id: I26493c2b0130f3cb86d866bd08fa5bbacbcc4725
Per the SQLAlchemy docs [1]:
The relationship.backref keyword should be considered legacy, and use
of relationship.back_populates with explicit relationship() constructs
should be preferred.
A blog post is available to explain what's going on here [2] and might
be worth a read. The learnings from that blog post do have the benefit
of allowing us to simplify some existing relationships that had
unnecessary arguments defined.
[1] https://docs.sqlalchemy.org/en/14/orm/backref.html
[2] https://that.guru/blog/sqlalchemy-relationships-without-foreign-keys/
Change-Id: I882e9a918ab1a44b205fc86bbcbb6fef5209ab76
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Resolve the following RemovedIn20Warning warning:
The legacy calling style of select() is deprecated and will be removed
in SQLAlchemy 2.0. Please use the new calling style described at
select().
For more information, refer to http://sqlalche.me/e/b8d9.
Change-Id: I59e694358dfb3e6e6d0412a5519a412404260937
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Resolve the following RemovedIn20Warning warning:
"SecretStoreMetadatum" object is being merged into a Session along the
backref cascade path for relationship "Secret.secret_store_metadata";
in SQLAlchemy 2.0, this reverse cascade will not take place. Set
cascade_backrefs to False in either the relationship() or backref()
function for the 2.0 behavior; or to set globally for the whole
Session, set the future=True flag
In effect, this means if you have a model that refers to another model,
creating/saving the former will no longer create/save the latter. We
have only one instance of this error - the error message above - and in
our case we are explicitly saving the 'Secret' instance before saving
the 'SecretStoreMetadatum' instance. As such, we can opt-in to the 2.0
behavior with no further changes. We do this for all relationships to be
safe.
More information on this issue can be found at [1].
[1] https://groups.google.com/g/sqlalchemy/c/VoY-qEiJA3U?pli=1
Change-Id: I4b4fa4c224113863643e16153478183447796146
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Well, sort of. We enable them but immediately filter out the ones we're
actually seeing, the rationale being that we can address these in a
piecemeal fashion without the risk of introducing new issues.
There's a bit more to be done here. However, the work done in oslo.db
and other projects [1] should provide a guide for how to resolve the
outstanding issues.
[1] https://review.opendev.org/q/topic:sqlalchemy-20
Change-Id: I36a79377016a6913f2c63cac4c820ad8342ffbf6
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
These were highlighted by the new 'WarningsFixture'.
Change-Id: I07beae9c9e518eeaae66d8d6accfdd16753de152
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Add the warnings fixture so we can catch deprecation warnings earlier.
Change-Id: I37a349237470beb60240d0b6c208aa75f2a075ac
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Currently a secret can be orphan, if the project that owns it
is deleted by an user that doesn`t have permission on the
project.[1]
The orphan secret cannot be deleted because the current rule
enforces a scoped token on that project to delete it (that
doesn't exist anymore).
To solve this issue, it's necessary to override the secret:delete
policy rule to allow the cloud admin to delete it.
The secret:get policy rule also needed to be changed because the
Python Barbican client gets the secret to check if it has
consumers before actually deleting it. This patch is making these
updates by default
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1932705
Co-author: Mauricio Harley <mharley@redhat.com>
Change-Id: Id755a9efd896b900d31eca93c0136398ed1925b8
As specified in Phase 1 of the Consistent and Secure Default RBAC
goal [1] policies have been updated to remove "system" scope and
only use "project" scope in all policies.
APIs with policies that previously required "system" scope have been
updated to accept "project" scoped tokens with the "admin" role instead.
[1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-1
Change-Id: I3b781112fc6ced7b73196f973cefd6a30ef99dd3
Change https://review.opendev.org/c/openstack/castellan/+/810124
added support for Vault namespaces to castellan.
In order to be able to use that functionality in Barbican, we need
to register and pass a corresponding config option in Barbican as well.
Change-Id: I4abb46dba51a00628c58eeb516074e1a149b8f35
Python 2 is no longer supported, thus usage of six can be removed.
Also, This removes B314 test from documentation because its actual
implementation was already removed[1].
[1] 9dbeefb55e
Change-Id: Ib01714e6462470dd5c3f6f06b52a3afeff573696
After migrating from cryptography===36.0.2 to 38.0.2, the function
generating a not signed CSR fails during the serialization process.
This fix returns a pre-generated CSR from cryptography===36.0.2
Change-Id: Ib538184bf224fd76a892509752fdb2000c205f38
This patch fixes a security vunlerability where the contents of a
request query string were mistakenly being used in the RBAC policy
engine.
Change-Id: I5797988e4c63c75fccf85277c52815d9bf684cff
Takashi Kajinami