plugins/router_basicauth/router_basicauth.c copied a glibc 2.2.5 (year 2002) related workaround from nginx which references to currently undocumented struct member.
https://www.mankier.com/3/crypt_rn
Portable code MUST NOT expect any other member than the initialized in the crypt_data struct. Portable code should not do anything else than initilzing (zero) the crypt_data.
uwsgi builds are failing on Fedora28 with libxcrypt 4.0.0.5.fc28 and glibc-2.27-6.fc28 . /usr/include/crypt.h is from the libxcrypt not from glibc.
plugins/router_basicauth/router_basicauth.c: In function ‘htpasswd_check’:
plugins/router_basicauth/router_basicauth.c:73:5: error: ‘struct crypt_data’ has no member named ‘current_salt’
cd.current_salt[0] = ~cpwd[0];
^
make: * [Makefile:4: all] Error 1
I wonder, is it possible simply deleting the offending line?
Thanks for reporting, any hint on which definition we can use to know that crypt.h is not the glibc one?
I found a similar ticket in nginx. The patch checks the glibc version:
https://trac.nginx.org/nginx/ticket/1469
I can confirm we are seeing the same failure on fedora-28:
http://logs.openstack.org/32/565632/4/check/devstack-platform-fedora-latest/a7e4979/job-output.txt.gz
Note the patch applied to fedora for this is https://src.fedoraproject.org/cgit/rpms/nginx.git/tree/0001-unix-ngx_user-Apply-fix-for-really-old-bug-in-glibc-.patch and does as @afazekas suggets, basically ignoring it for recent glibc.
This is referenced in #1768 which fixes another problem for current fedora too; might be worth merging these to avoid confusion.
https://github.com/unbit/uwsgi/commit/00dce4265784903a3bf440834ab269fceaf5a14b solved the crypt issue, but I am not sure the #include <crypt.h> really needs to be excluded.
The change also removed the crypt_r usage, which would allow to use crypt by multiple threads without a lock. Only the cd.current_salt[0] = ~cpwd[0]; was evil, crypt_r is preferred in mufti-threaded environment.
I can confirm that the above PR fixes the build for me on Fedora 28. Would be nice to get this into a release in the near future. Thanks!
It looks to have been released in 2.0.17.1 and works great for me on Fedora 28!
Closing, thanks!
Most helpful comment
I can confirm that the above PR fixes the build for me on Fedora 28. Would be nice to get this into a release in the near future. Thanks!