As shown here:
https://storage.gra1.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_d9c/680481/1/check/ec2
-api-functional-neutron/d9c3627/logs/etc/keystone/keystone.conf.txt.gz
You are using 'backend = oslo_cache.dict' this is no way is
representative of any
Added Keystonemiddleware and documentation tags. Marked as "medium"
importance as it requires documentation changes but is not
critical/RC/otherwise impacting. Clear communication of expected
behavior is important and should be found in Horizon and
Keystonemiddleware's documentation.
I am marking
Discussed in IRC[0] - conclusion is this is a Valid bug but there is no
reasonable attack vector (the data could be used in determining whom to
attempt to gain access to, but does not provide any means of direct
attack). The data is *NOT* intended to be public but is not really
explicitly
This isn't really a good idea. The way keystone's internal notification
framework is implemented, errors in that framework can leave the DB in
inconsistent states. If this were to be implemented any implementations
that are 3rd party could not reasonably be supported by the Keystone
team
Public bug reported:
There has been some confusion about the Application Credential API.
Specifically that application credentials can be created even if the
auth method is not enabled. The request is to make the Application
Credential API return a 403 (Forbidden) if the auth method is not
As discussed at the Denver PTG this is not really something we want to
handle. Breaking the catalog representation in the token could break
huge swaths of consumers and adding this as functionality is pretty low
priority vs. considering a new catalog form/mechanism.
** Changed in: keystone
Keystone is fixed with oslo.cache fix, marked as invalid for keystone
** Changed in: keystone
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
only thing affected by the network
partitioning).
This similarly needs to be addressed in pymemcache when it is utilized
in lieu of python-memcached.
** Affects: keystone
Importance: High
Assignee: Morgan Fainberg (mdrnstm)
Status: New
** Affects: keystonemiddleware
Import
Please do not try and make the NFV-feature specific bug something
different. Please open a new bug for features to bootstrap. Second,
there are bugs to open with the NFV plugins to support system scope.
This bug remains opinion.
** Changed in: keystone
Status: New => Opinion
--
You
I disagree with this needing to be in bootstrap. The main reason is that
bootstrap is intended to simply get a deployment to a place where it can
be setup. Since this is only some 3rd party plugins for NFV, this is
something the deployment can choose to do.
Bootstrap is and always will be
Discussed this with the Keystone core team and we came to the following
conclusions:
* This is prone to errors. It is easy to create an unusable password and
short of also submitting the plaintext password keystone can't ensure
the hash, ident, and metadata is sane.
* This doesn't meaningfully
Importance: Wishlist
Assignee: Morgan Fainberg (mdrnstm)
Status: Triaged
** Changed in: keystone
Status: New => Triaged
** Changed in: keystone
Importance: Undecided => Wishlist
** Changed in: keystone
Assignee: (unassigned) => Morgan Fainberg (mdrnstm)
--
You
Marking this as invalid in Triple-O, there is an underlying issue in
keystone causing the "recursive" error. The OPTIONS bug solved the issue
directly.
** Changed in: tripleo
Status: Triaged => Invalid
** Summary changed:
- Keystone circular reference on OPTIONS
+ Keystone 500 on OPTIONS
Assignee: (unassigned) => Morgan Fainberg (mdrnstm)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1801778
Title:
Keystone circular reference on OPTIONS
Status in OpenSt
Revisiting to mark as wont fix after reading through it. This is a
misunderstanding of the fernet packing and that the token payload is
intended to be a blackbox and decoded/expanded by keystone itself.
ID formats (dashes, no dashes, etc) are the purview of keystone.
** Changed in: keystone
This is not really in the plans. Bootstrap is meant to get you to a
place you can setup the rest of the system via the APIs. It is
intentionally very narrow. Marking as wont fix.
** Changed in: keystone
Status: Triaged => Won't Fix
--
You received this bug notification because you are a
Keystone no longer has v2/v3 split. V3 is always explicit about domain
membership (as per the description of the bug). Moving this to "Wont
Fix" for the server.
** Changed in: keystone
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Dependency Injection was removed/reworked. This is no longer an issue.
** Changed in: keystone
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
This is in violation of the rolling upgrade plans. Marking as "wont fix"
** Changed in: keystone
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
Marking as "invalid" now.
** Changed in: keystone
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1660603
Title:
Difference in
Marking as wont fix, the -1 is correct behavior for "no limit".
** Changed in: keystone
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
We should fix keystoneclient. KeystoneAuth is not doing anything wrong
here. I am against a "temp hack" like this. Secondarily, please submit
this patch to gerrit at review.openstack.org so that it can be
considered. Posting patches here is unlikely to be seen as
easily/readily.
** Changed in:
** Changed in: keystoneauth
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1498556
Title:
Reasonable assumptions concerning
** Changed in: pycadf
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1659053
Title:
use uuids with pycadf
Status in
@Ben, this is nothing to do with oslo-policy. it has to do with the
values passed to oslo-policy in the creds dict. If the creds dict does
not have domain-id populated in it, you can't enforce on it.
** Changed in: oslo.policy
Status: Incomplete => Invalid
--
You received this bug
** Changed in: python-keystoneclient
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1687593
Title:
Create OAUTH request
Is this something in the Keystone Server? this doesn't seem to be KSC
specific.
** Changed in: python-keystoneclient
Status: In Progress => Incomplete
** Also affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
removed keystonemiddleware as LP will timeout when trying to update.
** No longer affects: keystonemiddleware
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1266962
Title:
Remove
Revocations are no longer exposed with keystone. Marking this bug as
invalid.
** Changed in: keystonemiddleware
Status: Triaged => Won't Fix
** Changed in: keystonemiddleware
Status: Won't Fix => Invalid
--
You received this bug notification because you are a member of Yahoo!
marking as invalid for ksm.
** Changed in: keystonemiddleware
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1440493
Title:
I don't know how we'll address this. Realistically, I think this is
going to have to be marked as invalid/wont fix/opinion. I'm going to
mark it as wont fix, we can circle back on it if there is more
discussion to be had.
** Changed in: keystone
Status: New => Won't Fix
--
You received
newton is EOL
** Changed in: keystone/newton
Status: In Progress => Won't Fix
** Changed in: keystone/ocata
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity
This isn't something Keystone directly has control over, what is in our
requirements/g-r is what we ship with. Marking as invalid for keystone
server.
** Changed in: keystone
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
Marking as incomplete for OSC, please re-visit if it is still an issue
(many things have changed across the board) and invalid for keystone.
** Changed in: keystone
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
Marking as wont fix. The solution has been discussed and is recommended
that the public_endpoint be unset.
** Changed in: keystone
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
Marked as invalid. Not a lot we can do about python-memcached, but with
the py3-first testing i think we are beyond this as a bug.
** Changed in: keystone
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
** Changed in: keystone/newton
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1630092
Title:
Admin password reset
** Changed in: keystone/newton
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1635306
Title:
After newton deployment
** Changed in: keystone
Status: Fix Committed => Fix Released
** Changed in: python-keystoneclient
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
I'm going to mark this as opinion. It likely will get better with scope-
types and policy-in-code, but this bug in itself isn't relevant due to
how trusts were architected.
** Changed in: keystone
Status: Confirmed => Opinion
--
You received this bug notification because you are a member
** Changed in: keystone/newton
Status: Fix Committed => Fix Released
** Changed in: keystone/ocata
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
** Changed in: keystone/ocata
Status: Fix Committed => Fix Released
** Changed in: keystone/newton
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
Not a bug in keystone. Something must be fixed in pycadf.
** Changed in: keystone
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
Marking as invalid. Validation should not vary based upon options set in
configuration keystone-to-keystone. It makes it hard to know what to
expect when interacting with keystone.
** Changed in: keystone
Status: In Progress => Opinion
--
You received this bug notification because you
I'm going to mark this as invalid. It is recommended to add a rate-
limiter in-front of the openstack services if needed. Ideally Keystone
could support such a bit of software, but it is largely out-of-scope
(can be supplied by the fronting webservers e.g. apache and
mod_ratelimit)
** Changed in:
This is just something to do, update global-requirments and it is
populated down. Updating global-requirements for a past release is hard
to do, it is suggested that you simply propose the changes and it will
be synchronized to keystone once it is approved.
** Changed in: keystone/pike
Marking this as wont fix. This really is not something we can address in
a meaningful way at this time. It expands through a huge set of issues
across all of openstack and is not in line with the direction of the
project now.
** Changed in: keystone
Status: Triaged => Won't Fix
--
You
Newton is not maintained. Marked as wont fix.
** Changed in: keystone/newton
Status: In Progress => Won't Fix
** Changed in: keystone/ocata
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
Public bug reported:
AuthContextMiddleware requires a lot of modification of the code for
auth_token middleware. The code should be updated to ensure that there
are no-web-ob specific bits that need to be carried in keystone's tree.
This likely requires splitting the "tokenless auth" (x509) into
Keystone does not allow "login" for locked passwords, which includes
ones marked for "change before first use". Horizon needs to implement a
"change password form" (or a user must use the /v3/users/password API
directly).
This is not something that can/will be fixed in keystone.
** Changed in:
In line with my comment on the proposed change:
I am not a fan of wrapping basic functions in python with extra layers
for the sake of extra layers.
I also do not think the is_uuid_like is strict enough for what we do in
keystone. is_uuid_like would need to have a strict enforcement that no
*** This bug is a duplicate of bug 1793027 ***
https://bugs.launchpad.net/bugs/1793027
** This bug has been marked a duplicate of bug 1793027
Flask doesn't normalize domains sanely in some cases
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
controller/logs/screen-keystone.txt.gz?level=ERROR
** Affects: keystone
Importance: Critical
Assignee: Morgan Fainberg (mdrnstm)
Status: In Progress
** Changed in: keystone
Status: New => Triaged
** Changed in: keystone
Importance: Undecided => Critical
** Change
/294ca38554bb229f66a772e7dba35a5b08a36b20/keystone/common/authorization.py#L152
** Affects: keystone
Importance: High
Assignee: Morgan Fainberg (mdrnstm)
Status: In Progress
** Affects: keystone/rocky
Importance: High
Assignee: Morgan Fainberg (mdrnstm)
Status: In Progress
** Affects
Public bug reported:
Keystone uses translated strings both in logging an exceptions. This is
incorrect.
All strings that are passed to logging should remain un-translated. The
solution is to duplicate the string and pass the untranslated (not
wrapped with `_()`) to the logger while passing the
18-06-11 20:16:29.824 216 ERROR keystone.common.wsgi ValueError: Extra data:
line 1 column 5 - line 5 column 22 (char 4 - 52)
2018-06-11 20:16:29.824 216 ERROR keystone.common.wsgi
** Affects: keystone
Importance: High
Assignee: Morgan Fainberg (mdrnstm)
Status: In Progress
definitions
* all routable paths will be owned by the base prefix (e.g.
keystone.api.user will own everything under /user/)
* Paste Deploy removed
** Affects: keystone
Importance: Medium
Assignee: Morgan Fainberg (mdrnstm)
Status: In Progress
** Changed in: keystone
Status: New
This is something we should build into oslo.cache. I have moved the bug
to wont fix in keystone and added oslo.cache.
** Also affects: oslo.cache
Importance: Undecided
Status: New
** Changed in: keystone
Status: Triaged => Won't Fix
** Summary changed:
- keystone token cache
This is not a bug. Dogpile.cache can set an actual memcache expiration,
however, we have simply been leaning on the LRU capabilities on
memcache. For keystone this would need to be changed in oslo.cache not
in Keystone.
I am marking this as opinion, it's not really a bug, it is how we have
This also impacts ocata.
** Also affects: keystone/ocata
Importance: Undecided
Status: New
** Changed in: keystone/ocata
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
/openstack/keystone/blob/56237b709ef901fabfd9e8ba744bbcc4cebf8b9b/keystone/common/validation/__init__.py#L33-L43
** Affects: keystone
Importance: Medium
Assignee: Morgan Fainberg (mdrnstm)
Status: In Progress
** Affects: keystone/pike
Importance: Medium
Assignee: Morgan
Based upon research and discussions in IRC, turns out we do not store
the application_credential_id in the token payload. This means that if
the token is not pre-populated in the cache, the test will fail.
This also means that if the token cache expires, subsequent uses of the
token with the
This is an issue with the SQLAlchemy hybrid_property.expression use in
the user ref, where .expression is returning Password.password.
This appears to be an incorrect use of hybrid_property.expression.
The net result is that in some cases we store the un-hashed password (in
memory only) on the
** Project changed: keystoneauth => keystone
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1708005
Title:
6 out 10 keystone.tests.unit.test_cert_setup.* unit test
Keystoneclient has nothing to say about what the server accepts. If
anything this is a keystone issue.
** Project changed: python-keystoneclient => keystone
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity
** Project changed: python-keystoneclient => keystone
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1615076
Title:
Keystone server does not define "enabled"
Mitaka is EOL
** Changed in: keystone/mitaka
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1588860
Title:
Mitaka is EOL
** Changed in: keystone/mitaka
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1579604
Title:
project
Mitaka is EOL
** Changed in: keystone/mitaka
Status: New => Won't Fix
** Changed in: keystone/mitaka
Status: Won't Fix => Fix Released
** Changed in: keystone/mitaka
Status: Fix Released => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Mitaka is EOL
** Changed in: keystone/mitaka
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1629446
Title:
federated
As per lance, this is being marked as wont fix. we can re-visit when/if
microversions or v4 is implemented.
** Changed in: keystone
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
Mitaka is EOL
** Changed in: keystone/mitaka
Status: New => Won't Fix
** Changed in: keystone/mitaka
Status: Won't Fix => Fix Released
** Changed in: keystone/mitaka
Status: Fix Released => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
I am marking this bug closed as the two patches in #17 have merged (inc.
the backport).
** Changed in: keystone
Status: New => Fix Released
** Changed in: keystone
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Yahoo!
Engineering
Unfortunately, we cannot change the behavior without a microversion
uspport or something similar. ?name= will need to maintain returning an
empty list, as that is the contract. I am closing this as wont fix.
** Changed in: keystone
Status: New => Won't Fix
--
You received this bug
This isn't a bug. IF the {role_id} at the end of the call is not passed,
we use the list action of:
/v3/domains/{domain_id}/groups/{group_id}/roles/ (regardless of head or
get action)
If a role_id is passed, you're calling a different API. This is not a
great design, but this is working as
** Changed in: keystone
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1576765
Title:
Potential DOS: Keystone Extra Fields
HEAD calls should still be supported. It may not make sense for some
things, but it can be useful (someone can check content length, which
should be identical, or headers, or any number of things that aren't
what you'd expect).
Simply put, it costs us *nothing* to support it.
** Changed in:
** Changed in: keystone/ocata
Status: New => Won't Fix
** Changed in: keystone/mitaka
Status: New => Won't Fix
** Changed in: keystone/newton
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
** Changed in: keystone
Importance: Critical => High
** Also affects: keystone/mitaka
Importance: Undecided
Status: New
** Also affects: keystone/pike
Importance: High
Assignee: Morgan Fainberg (mdrnstm)
Status: In Progress
** Also affects: keystone/new
processing).
The correct mechanism is to use bcrypt, scrypt, or pdkfd_sha512 instead
of sha512_crypt.
This bug is marked as public security as bug #1543048 has already
highlighted this issue.
** Affects: keystone
Importance: Critical
Assignee: Morgan Fainberg (mdrnstm)
Status
Keystone does not call .set_latent anywhere. This is an issue with
oslo.middleware possibly.
** Changed in: keystone
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
Public bug reported:
pycadf warnings are plentiful in keystone tests: UserWarning: Invalid uuid. To
ensure interoperability, identifiersshould be a valid uuid.
warnings.warn('Invalid uuid. To ensure interoperability, identifiers'
Be sure keystone is providing uuids appropriately.
**
Public bug reported:
During test runs there are a lot of warnings for DeprecationWarning:
Method 'CORS.set_latent()' has moved to 'method.set_defaults()
We should ensure keystone is using set_defaults instead of latent.
** Affects: keystone
Importance: Undecided
Status: New
--
Kilo is EOL
** Changed in: keystone/kilo
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1491926
Title:
Remove padding from
Kilo is EOL
** Changed in: keystone/kilo
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1488208
Title:
Revoking a role
** Changed in: keystone/kilo
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1490804
Title:
[OSSA 2016-005] PKI Token
Kilo is EOL
** Changed in: keystone/kilo
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1484237
Title:
token revocations
** Changed in: keystone/liberty
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1541621
Title:
Invalid fernet
** Changed in: keystone/liberty
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1527759
Title:
Default domain no longer
** Changed in: keystone/liberty
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1526976
Title:
Any operation without
** Changed in: keystone/liberty
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1497461
Title:
Fernet tokens fail for
** Changed in: keystone/kilo
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1555187
Title:
keystone fails to start in
Moved to keystonemiddleware project.
** Also affects: keystonemiddleware
Importance: Undecided
Status: New
** Changed in: keystone
Status: New => Invalid
** No longer affects: keystone
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
Turns out the issue comes from the test suite not using the AuthContext
object. A new patch to ensure we are using AuthContext not a dict will
be proposed in lieu of the current fix.
** Changed in: keystone/mitaka
Status: In Progress => Invalid
** Changed in: keystone/newton
** Changed in: keystone
Status: New => Triaged
** Changed in: keystone
Importance: Undecided => Medium
** Changed in: keystone
Assignee: (unassigned) => Morgan Fainberg (mdrnstm)
** Also affects: keystone/newton
Importance: Undecided
Status: New
** Als
*** This bug is a security vulnerability ***
Public security bug reported:
The keystone server blindly overwrites the auth_context.user_id in each
auth method that is run. This means that the last auth_method that is
run for a given authentication request dictates the user_id.
While this is not
The other bug was/is public (as referenced in #4 by matt) and this was
specifically for newton. Marking this as invalid as this is a Class E /
"not a bug")
** Changed in: ossa
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
With PKI tokens being deprecated, I am going to mark this as "wont fix",
prefering Fernet and/or UUID tokens to PKI
** Changed in: keystonemiddleware
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
As an additional note this would not affect keystoneauth but affect
keystone from what I can tell. Your logs will help us significantly.
I've retargeted the bug to keystone instead of keystoneauth, pending
your log files.
** Project changed: keystoneauth => keystone
--
You received this bug
The fernet keys should not be writable by the keystone user, typically
by root (same as a certificate), therefore the log should likewise be
separate to avoid breaking normal logging.
The use of syslog would easily solve this issue.
** Tags added: fernet logging low-hanging-fruit
** Changed in:
1 - 100 of 377 matches
Mail list logo
