-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ensure that user and group IDs in LDAP's tables are also max 64chars #28876
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CS checker goes mimimi
54c96a8
to
2d13764
Compare
2d13764
to
fdbaef6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good
fdbaef6
to
e0e41af
Compare
Psalm should also be happy now |
e0e41af
to
7073513
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🐘
- limitation by core tables (e.g. sharing), IDs are always 64chars - when longer group IDs were requested they are hashed (does not affect displaynames) Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
7073513
to
6ab30a6
Compare
/backport to stable22 |
/backport to stable21 |
/backport to stable20 |
The backport to stable20 failed. Please do this backport manually. |
stable20: #28971 |
fixes #28653
While the LDAP tables were always this long, these never seemed to have happened after a first report. So it's an edge case, the migration steps should run fairly quickly in any cases. On my test instance with >34k entries in the user mappings table (but only few long ones to check – pretty much as in reality) it finished almost immediately (pgsql).