Сборка автономного htpasswd

Возможно, не хватает SSL или ещё чего-то, не могу разобраться сам.

1) От кого автономную и зачем?

2) Какой именно функционал нужен? Возможно проще переписать его заново безо всех этих apr и прочей чуши, там алгоритм весьма простой, по крайней мере если речь про дефолтное md5, будет всего несколько страниц кода в одном .c файле без зависимостей.

Генери с помощью openssl. Ну можно ещё на перл\питон\пхп.

То, что вы показываете, это не куча зависимостей, а самые базовые, фактически libc + pthread + libcrypt, последний разве что можно попробовать собрать статически, если уж совсем для педантов.

Избавится от libc + pthread можно только статической сборкой.

Какой именно функционал нужен?

По сути необходимо только это: htpasswd -cbBC 12 файл пользователь пароль

Знаю, как можно сделать это через python или php, но для проекта нужен минималистичный бинари без зависимостей от любых внешних библиотек (требуется полная самодостаточность).

То, что вы показываете, это не куча зависимостей

Это то, что осталось от списка, полученного изначально.

Избавится от libc + pthread можно только статической сборкой.

В роде, так и делал, просматривал протокол сборки, компиляторы получают «-static», однако, зависимости остаются.

Если компилятор получил -static то зависимостей остаться не может.

Какие ещё базовые, зачем хеш-калькулятору треды?

Если компилятор получил -static то зависимостей остаться не может.

Вот и я об том. Не понятно, как такое получается.

Единственное, что приходит на ум: на хабре когда-то мелькала статья в которой автор писал о статичной сборке и том, как некоторые компиляторы обходят возможные проблемы игнорируя флаг «static». Однако, попытки найти её пока безуспешны (возможно, стать убрали).

https://ru.wikipedia.org/wiki/Bcrypt https://en.wikipedia.org/wiki/Blowfish_(cipher)

По-моему там всё просто.

Кстати если ты засунешь libc статически то файл получится совсем не минималистичным (кажется больше мегабайта). Поэтому лучше всё-таки libc оставить снаружи, но линковаться с какой-то старой версией. А вот pthread и libcrypt не нужны, шифр реализуешь сам на Си.

шифр реализуешь сам на Си.

Я, скорее, админ прикладного уровня, чем разработчик, в язык С не знаю, вот и тыкаюсь как слепой (хотя, почему «как»?).

далее configure с параметрами static и сборка

Там ещё нужно и CFLAGS=-static прокидывать скорее всего.

libcrypt.so.1

Это часть OpenSSL линковать которую не рекомендуется статически, хотя, можно конечно.

Нет это не часть openssl, это часть libc.

Часть openssl - это libcrypto.

Просто найди эти алгоритмы и скопируй себе в программу. Там кода будет на сотню-другую строк может, и то копипаста. Чем мудохаться с этими сборками и вызовами внешней программы. Ты по сути пытаешься карьерным экскаватором одну яму для картошки выкопать. Это можно, но проще лопату себе сделать.

Там ещё нужно и CFLAGS=-static прокидывать скорее всего. Помимо опций в configure экспортированы переменные:

  LDFLAGS=-static  ; export LDFLAGS
  CFLAGS=-static   ; export CFLAGS
  CPPFLAGS=-static ; export CPPFLAGS
  CXXFLAGS=-static ; export CXXFLAGS

Просто найди эти алгоритмы и скопируй себе в программу. Там кода будет на сотню-другую строк может, и то копипаста.

Это просто, когда язык знаешь. Я плох в Си, поэтому решил пойти «традиционным» путём: wget-tar-configure-make, тем более что в параметрах configure заявлена поддержка static для support-утилит (коей является htpasswd).

Да, видимо перепутал.

Шоб хешировать быстрее, очевидно же.

Посмотрел, просто так её похоже хрен соберёшь.

Вот такой рецепт лови:

sudo apt install git gcc build-essential libtool libtool-bin

git clone https://github.com/apache/httpd --depth=1 -b trunk

cd httpd/srclib/

git clone https://github.com/apache/apr --depth=1 -b trunk

cd ../

./buildconf
CFLAGS=-static ./configure  --enable-static --disable-shared --enable-static-support --enable-static-htpasswd

cd srclib/apr
make -j65 # Число ядер у твоего CPU + 1

cd ../../support/

gcc    -static    -DLINUX -D_REENTRANT -D_GNU_SOURCE     -I. -I`pwd`/../os/unix -I`pwd`/../include -I`pwd`/../srclib/apr/include -I`pwd`/../modules/aaa -I`pwd`/../modules/cache -I`pwd`/../modules/core -I`pwd`/../modules/database -I`pwd`/../modules/filters -I`pwd`/../modules/ldap -I`pwd`/../modules/loggers -I`pwd`/../modules/lua -I`pwd`/../modules/proxy -I`pwd`/../modules/http2 -I`pwd`/../modules/session -I`pwd`/../modules/ssl -I`pwd`/../modules/test -I`pwd`/../server -I`pwd`/../modules/md -I`pwd`/../modules/arch/unix -I`pwd`/../modules/dav/main -I`pwd`/../modules/generators -I`pwd`/../server -I`pwd`/../modules/mappers -c passwd_common.c -o 1.o

gcc    -static    -DLINUX -D_REENTRANT -D_GNU_SOURCE     -I. -I`pwd`/../os/unix -I`pwd`/../include -I`pwd`/../srclib/apr/include -I`pwd`/../modules/aaa -I`pwd`/../modules/cache -I`pwd`/../modules/core -I`pwd`/../modules/database -I`pwd`/../modules/filters -I`pwd`/../modules/ldap -I`pwd`/../modules/loggers -I`pwd`/../modules/lua -I`pwd`/../modules/proxy -I`pwd`/../modules/http2 -I`pwd`/../modules/session -I`pwd`/../modules/ssl -I`pwd`/../modules/test -I`pwd`/../server -I`pwd`/../modules/md -I`pwd`/../modules/arch/unix -I`pwd`/../modules/dav/main -I`pwd`/../modules/generators -I`pwd`/../server -I`pwd`/../modules/mappers -c htpasswd.c -o 2.o

gcc -static 1.o 2.o ../srclib/apr/.libs/libapr-2.a /usr/lib/x86_64-linux-gnu/libcrypt.a /usr/lib/x86_64-linux-gnu/libuuid.a -o htpasswd
/usr/bin/ld: ../srclib/apr/.libs/libapr-2.a(groupinfo.o): in function `apr_gid_name_get':
groupinfo.c:(.text+0x6d): warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: ../srclib/apr/.libs/libapr-2.a(groupinfo.o): in function `apr_gid_get':
groupinfo.c:(.text+0x14c): warning: Using 'getgrnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: ../srclib/apr/.libs/libapr-2.a(userinfo.o): in function `getpwnam_safe':
userinfo.c:(.text+0x43): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: ../srclib/apr/.libs/libapr-2.a(userinfo.o): in function `apr_uid_name_get':
userinfo.c:(.text+0x25f): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: ../srclib/apr/.libs/libapr-2.a(sockaddr.o): in function `call_resolver':
sockaddr.c:(.text+0x920): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: ../srclib/apr/.libs/libapr-2.a(sockaddr.o): in function `apr_getservbyname':
sockaddr.c:(.text+0x120f): warning: Using 'getservbyname_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

ll -h htpasswd
-rwxrwxr-x 1 exl exl 1.8M Dec  1 22:28 htpasswd*

strip -s htpasswd

ll -h htpasswd
-rwxrwxr-x 1 exl exl 1.6M Dec  1 22:29 htpasswd*

ldd htpasswd
	not a dynamic executable

file htpasswd
htpasswd: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=ddf9fdfd8d00bcd93dd8911ddb7fe42bb8ee91a7, for GNU/Linux 3.2.0, stripped

./htpasswd -cbBC 12 fuck this shit
Adding password for user this

Но меня смущают Warning’и.

Короче говоря, со статическими сборками, либами, исполнительными файлами – много проблем. Если тебе нужен условный htpasswd запускаемый везде – нужно юзать не статику, а сборку этой программы в каком-нибудь древнем CentOS 7. Туда же можно накатить arm-компиляторы и получить такую же сборку для arm64, arm32, а флажок -m32 поможет тебе собрать либу под x86 вместо x86_64.

Но меня смущают Warning’и.

htpasswd не использует getaddrinfo и прочее на что там ругается.

потому что нужно еще ставить glibc-static или как оно там в твоей системе называется..

Благодарю за рецепт, но на моей рабочей станции что-то пошло не так на финальном этапе: при сборке htpasswd жалобы на мьютексы.

Пример:

proc_mutex.c:(.text+0xbfb): неопределённая ссылка на «pthread_mutex_unlock»

Пока не очень понятно зачем они хэш-калькулятору и можно ли обойтись без оных.

Полный листинг разместить не могу - «Слишком большое сообщение». Если для анализа будет нужен лог сборки htpasswd, то он опубликован здесь: https://pastebin.com/cdnyRu74

Возможно, в моей ОС чего-то нехватает для сборки?

Использую libc6-dev, так как нет пакета с именем glibc-static.

Попробуй добавить /usr/lib/x86_64-linux-gnu/libpthread.a в строку линковки:

gcc -static 1.o 2.o ../srclib/apr/.libs/libapr-2.a /usr/lib/x86_64-linux-gnu/libpthread.a /usr/lib/x86_64-linux-gnu/libcrypt.a /usr/lib/x86_64-linux-gnu/libuuid.a -o htpasswd

Слона не приметил…

Спасибо, это работает!