Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Для новичков как вообще в Linux, так и в конкретной теме, к которой относится вопрос.

Модератор: Bizdelnick

Ответить
Аватара пользователя
жучара
Сообщения: 937
ОС: астралинукс

Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение жучара »

Друзья! То есть ситуация такая я бы сказал, что это как бы сборочная зависимость "Conflicts". Хотя я таких не знаю, но оно так и выглядит.

Пакет dump, собираю по науке. Отсюда качаю исходники, распаковываю, патчи накладываю.
deb [trusted=yes] http://ftp.ru.debian.org/debian stretch main contrib non-free
deb-src [trusted=yes] http://ftp.ru.debian.org/debian stretch main contrib non-free
Качаю сборочные зависимости ТОЛЬКО с родных репозиториев:
В папке dump-0.4b46 командую: dpkg-buildpackage -us -uc

Всё собирается без ошибок. На выходе, в частности, файл dump_0.4b46-3_amd64.deb

Но если в системе будет установлен пакет libssl-dev, dump не соберётся.

Пакет libssl-dev не знаю, откуда взялся, но я ничего левого не устанавливал, он в родном репозитории, видать, какая-то программа его установила. Под спойлером подробности
подробности ошибки
Вот ошибка при сборке.

Shell

gcc -DHAVE_CONFIG_H -I. -I.. -I../dump -I../compat/include -Wdate-time -D_FORTIFY_SOURCE=2 -D_USE_BSD_SIGNAL -D_PATH_DUMPDATES=\"/var/lib/dumpdates\" -D_DUMP_VERSION=\"0.4b46\" -D_PATH_RMT=\"/etc/rmt\" -g -O2 -fdebug-prefix-map=/home/user/dump/dump-0.4b46=. -fstack-protector-strong -Wformat -Werror=format-security -c transformation_ssl.c -fPIC -DPIC -o .libs/transformation_ssl.o
transformation_ssl.c: In function ‘generateIV’:
transformation_ssl.c:218:3: warning: ‘RAND_pseudo_bytes’ is deprecated [-Wdeprecated-declarations]
RAND_pseudo_bytes(salt, *saltlen);
^~~~~~~~~~~~~~~~~
In file included from /usr/include/openssl/e_os2.h:13:0,
from /usr/include/openssl/err.h:13,
from transformation_ssl.c:6:
/usr/include/openssl/rand.h:44:1: note: declared here
DEPRECATEDIN_1_1_0(int RAND_pseudo_bytes(unsigned char *buf, int num))
^
transformation_ssl.c: In function ‘transformation_ssl_factory’:
transformation_ssl.c:518:51: error: dereferencing pointer to incomplete type ‘EVP_CIPHER {aka const struct evp_cipher_st}’
RAND_bytes(t->state.ssl.key, t->state.ssl.cipher->key_len);
^~
Makefile:445: ошибка выполнения рецепта для цели «transformation_ssl.lo»
В чём суть. Файл ./configure при сборке палит пакет libssl-dev
pkg-config --exists --print-errors openssl

(см Почему pkg-config находит пакет openssl, хотя находить его не должна?). Обращаю внимание, хоть и написано openssl. но pkg-config палит файл /usr/lib/x86_64-linux-gnu/pkgconfig/openssl.pc, принадлежащий пакету libssl-dev , но не пакету openssl

Следствие: создаются инклуд config.h, где прописывается макрос #define HAVE_OPENSSL 1
Следствие: компилятор обрабатывает соответствующий участок кода файла transformation_ssl.c:

Shell

//тут код всякий.

Transformation *t;

//тут код всякий.

#ifdef HAVE_OPENSSL
// we could use this to generate a key from a passphrase.
// using this as the actual encryption key has the problems
// discussed elsewhere.
//EVP_BytesToKey(cipher, EVP_md5(), NULL, buf, strlen(buf), 1, key, iv);

if (enc) {
/* generate random session key */
//EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
//EVP_CIPHER_CTX_init(ctx);
//EVP_CIPHER_CTX_rand_key(ctx, t->state.ssl.key);
//EVP_CIPHER_CTX_cleanup(ctx);
//EVP_CIPHER_CTX_free(ctx);
RAND_bytes(t->state.ssl.key, t->state.ssl.cipher->key_len);
} else {
// how do we get keys?
}
#endif

//тут код всякий.
Вот тут ошибка:
t->state.ssl.cipher->key_len

Ковыряемся, приходим к тому выводу, что нужно смотреть
const EVP_CIPHER *cipher

Смотрим структуру EVP_CIPHER

Shell

$ sudo find / -name "*.h" -exec grep -l 'struct.*EVP_CIPHER' {} \;
/usr/include/openssl/ossl_typ.h
$

Shell

$ cat /usr/include/openssl/ossl_typ.h | grep EVP_CIPHER
typedef struct evp_cipher_st EVP_CIPHER;
typedef struct evp_cipher_ctx_st EVP_CIPHER_CTX;
$
То есть EVP_CIPHER суть evp_cipher_st. Смотрим evp_cipher_st

Shell

$ sudo find / -name "*.h" -exec grep evp_cipher_st {} \;
typedef struct evp_cipher_st EVP_CIPHER;
$
Конгениально, Конрад Карлович, конгениально. Никакого определения evp_cipher_st нет и в помине.

Тут можно много чё наделать, а чё правильно- непонятно. У нормальных людей evp_cipher_st определена в файле evp.h. Давайте тут что ли посмотрим определение структуры evp_cipher_st
https://docs.huihoo.com/doxygen/openssl/1.0.1c/crypto_2ossl__typ_8h_source.html
struct evp_cipher_st
{
int nid;
int block_size;
int key_len; /* Default value for variable length ciphers */
int iv_len;
unsigned long flags; /* Various flags */
int (*init)(EVP_CIPHER_CTX *ctx, const unsigned char *key,
const unsigned char *iv, int enc); /* init key */
int (*do_cipher)(EVP_CIPHER_CTX *ctx, unsigned char *out,
const unsigned char *in, size_t inl);/* encrypt/decrypt data */
int (*cleanup)(EVP_CIPHER_CTX *); /* cleanup ctx */
int ctx_size; /* how big ctx->cipher_data needs to be */
int (*set_asn1_parameters)(EVP_CIPHER_CTX *, ASN1_TYPE *); /* Populate a ASN1_TYPE with parameters */
int (*get_asn1_parameters)(EVP_CIPHER_CTX *, ASN1_TYPE *); /* Get parameters from a ASN1_TYPE */
int (*ctrl)(EVP_CIPHER_CTX *, int type, int arg, void *ptr); /* Miscellaneous operations */
void *app_data; /* Application data */
} /* EVP_CIPHER */;
Нас будет интересовать один членик key_len. Файл /usr/include/openssl/ossl_typ.h вот так перепишем:
...
struct evp_cipher_st
{
int key_len;
}
typedef struct evp_cipher_st EVP_CIPHER;
...
Сейчас всё собирается. Грязь, конечно, ну так и я не программист.
В общем, как нам всё это дело исправить правильно? Ось не покоцанная, всё с родных репов ставленное. Астралинукс Орёл 2.12.29. Спасибо, кто откликнется.
Я просто читаю маны.
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение Hephaestus »

жучара писал(а):
09.06.2020 16:47
Но если в системе будет установлен пакет libssl-dev, dump не соберётся.
Не далее, как две недели назад я разруливал у себя похожую проблему.
Я там в итоге пришел к выводу, что совпали имена заголовочных файлов от разных платформ,
и в результате в процессе сборки срабатывал блок кода для другой платформы, из-за чего оно не хотело собираться. Но это мои домыслы. Касалось это одного-единственного исходного файла. Решил проблему патчем, переставив местами директивы препроцессора в этом файле.

А по-хорошему, надо писать баг-репорт и задавать вопросы разработчикам или мейнтейнерам.
Добавлено (18:24):
жучара писал(а):
09.06.2020 16:47
Обращаю внимание, хоть и написано openssl. но pkg-config палит файл /usr/lib/x86_64-linux-gnu/pkgconfig/openssl.pc, принадлежащий пакету libssl-dev , но не пакету openssl
Это как раз нормально, они от одного источника происходят.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение Bizdelnick »

жучара писал(а):
09.06.2020 16:47
В общем, как нам всё это дело исправить правильно?
Взять версию dump, совместимую с системной версией openssl. Смотрите в доке (README, INSTALL, ещё где-то), какие версии поддерживаются. И, конечно, прописать libssl-dev в сборочные зависимости.
Или отключить поиск openssl. Что-нибудь вроде опции --disable-ssl для configure. См. ./configure --help.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение Hephaestus »

Bizdelnick писал:
09.06.2020 19:06
И, конечно, прописать libssl-dev в сборочные зависимости.
Или отключить поиск openssl.
Вот это, кстати, интересный вопрос.
Когда готовили пакет исходного кода для dump, предполагалось, что в момент сборки libssl-dev в системе не будет? Так надо понимать?
Иначе бы ошибка сборки обнаружилась ещё при подготовке этого пакета.
По идее-то, команда dpkg-buildpackage -us -uc должна отработать нормально без дополнительных исправлений (ну, apt-get build-dep там ещё может понадобиться).
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение Bizdelnick »

Hephaestus писал:
09.06.2020 19:25
Когда готовили пакет исходного кода для dump, предполагалось, что в момент сборки libssl-dev в системе не будет? Так надо понимать?
Если он не прописан в сборочных зависимостях, видимо, так.
К. О.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
жучара
Сообщения: 937
ОС: астралинукс

Re: Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение жучара »

Hephaestus писал:
09.06.2020 19:25
Вот это, кстати, интересный вопрос.
Когда готовили пакет исходного кода для dump, предполагалось, что в момент сборки libssl-dev в системе не будет? Так надо понимать?
Иначе бы ошибка сборки обнаружилась ещё при подготовке этого пакета.
По идее-то, команда dpkg-buildpackage -us -uc должна отработать нормально без дополнительных исправлений (ну, apt-get build-dep там ещё может понадобиться).
Гм. В момент сборки (конкретно команды dpkg-buildpackage -us -uc) пакет libssl-dev был установлен:
В папке dump-0.4b46 командую: dpkg-buildpackage -us -uc

Всё собирается без ошибок. На выходе, в частности, файл dump_0.4b46-3_amd64.deb

Но если в системе будет установлен пакет libssl-dev, dump не соберётся.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hephaestus писал:
09.06.2020 19:25
(ну, apt-get build-dep там ещё может понадобиться).
естессно
Качаю сборочные зависимости ТОЛЬКО с родных репозиториев:
в смысле качаю и устанавливаю.
Я просто читаю маны.
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение Hephaestus »

Bizdelnick писал:
09.06.2020 19:50
Если он не прописан в сборочных зависимостях, видимо, так.
Не просто не прописан в зависимостях, а вообще не должен присутствовать в системе, ибо мешает,
вот в чём штука-то. Если бы сопровождающий пакета (или кто он там) в момент подготовки src-пакета имел в своей системе установленный libssl-dev (для каких-то других целей), он бы заметил проблему.
И в таком случае пакеты должны быть помечены как конфликтующие (или как это правильно называется).
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
жучара
Сообщения: 937
ОС: астралинукс

Re: Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение жучара »

Hephaestus писал:
09.06.2020 21:56
Если бы сопровождающий пакета (или кто он там) в момент подготовки src-пакета имел в своей системе установленный libssl-dev (для каких-то других целей), он бы заметил проблему.
И в таком случае пакеты должны быть помечены как конфликтующие (или как это правильно называется).
всё правильно, но этого не произошло.
Я просто читаю маны.
Спасибо сказали:
Аватара пользователя
Bizdelnick
Модератор
Сообщения: 20752
Статус: nulla salus bello
ОС: Debian GNU/Linux

Re: Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение Bizdelnick »

Hephaestus писал:
09.06.2020 21:56
Не просто не прописан в зависимостях, а вообще не должен присутствовать в системе, ибо мешает,
вот в чём штука-то. Если бы сопровождающий пакета (или кто он там) в момент подготовки src-пакета имел в своей системе установленный libssl-dev (для каких-то других целей), он бы заметил проблему.
Полагаю, сопровождающий использует pbuilder, поэтому не имеет подобных проблем.
Hephaestus писал:
09.06.2020 21:56
И в таком случае пакеты должны быть помечены как конфликтующие (или как это правильно называется).
Нет такого понятия как конфликт сборки. Можно сделать так, чтобы пакет не мешал, как именно — я написал выше. Надо ли это с учётом того, что в сборочной инфраструктуре всё равно используется pbuilder, и ничего лишнего в chroot не устанавливается, — решать сопровождающему исходя из его личных предпочтений.
Пишите правильно:
в консоли
вку́пе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:
Аватара пользователя
жучара
Сообщения: 937
ОС: астралинукс

Re: Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение жучара »

Bizdelnick писал:
09.06.2020 19:06
Или отключить поиск openssl. Что-нибудь вроде опции --disable-ssl для configure. См. ./configure --help.
Решило (содержание debian/rules):
$ cat debian/rules
#!/usr/bin/make -f
#export DH_VERBOSE = 1

export DEB_CFLAGS_MAINT_APPEND = -fPIE
export DEB_LDFLAGS_MAINT_APPEND = -fPIE -Wl,-z,now -Wl,--as-needed

override_dh_auto_configure:
dh_testdir
EXT2FS_LIBS="-lext2fs -lcom_err" dh_auto_configure -- \
--prefix=/usr \
--sbindir=/sbin \
--with-ccopts="-O2 -g -Wall" \
--with-dumpdatespath=/var/lib/dumpdates \
--enable-lzo --enable-bzip2 --enable-zlib \
--disable-ssl

override_dh_auto_install:
dh_auto_install -- \
SBINDIR=`pwd`/debian/dump/sbin \
MANDIR=`pwd`/debian/dump/usr/share/man/man8

mv debian/dump/usr/share/man/man8/rmt.8 \
debian/dump/usr/share/man/man8/rmt-dump.8
mv debian/dump/sbin/rmt debian/dump/usr/sbin/rmt-dump

(cd debian/dump/sbin ; rm -f rdump rrestore ; \
ln -s dump rdump ; ln -s restore rrestore )
(cd debian/dump/usr/share/man/man8 ; rm -f rdump* rrestore* ; \
ln -s dump.8.gz rdump.8.gz ; ln -s restore.8.gz rrestore.8.gz )

%:
dh $@ --with autoreconf
$
тут главное не делать патч (quilt), а то греха не оберёшься.

Непонятно:
1) если без этой фигни, которая ssl, всё собирается, почему по умолчанию нужно собирать с ней?
2) и ещё непонятно. Если у меня на целевой стоит пакет libssl-dev, мешающий сборке, так может, собрать пакет где-нибудь в другом месте, где нет libssl-dev (создать crhoot, не знаю, как эту штуку назвать, там собрать пакет безо всяких libssl-dev) и установить *.deb файл на целевую машину? То есть вопрос не стоит, получится ли. Оно уже получилось, но это же вроде как обходной путь, не знаю, правильно так делать или нет.
Я просто читаю маны.
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение Hephaestus »

жучара писал(а):
12.06.2020 13:49
если без этой фигни, которая ssl, всё собирается, почему по умолчанию нужно собирать с ней?
В частности потому, что там в числе прочего есть rmt/ermt. Удаленный доступ, безопасность и всё такое.
В списке changes первым пунктом указано
Use pkg-config to locate openssl dependencies to fix ermt linking.
Здесь как бы корень Вашей проблемы с pkg-config, поскольку это указано в числе новшеств, раньше этого не было, надо полагать.
жучара писал(а):
12.06.2020 13:49
собрать пакет где-нибудь в другом месте, где нет libssl-dev
жучара писал(а):
12.06.2020 13:49
не знаю, правильно так делать или нет
Не только правильно, но и рекомендовано. По крайней мере, раньше было. Где-то видел такую рекомендацию. Сборку пакета рекомендовалось производить на "чистой" системе. Тут только вопрос, что считать "чистой" системой. Но эта рекомендация была связана с тем, что при создании нового пакета нужно было выявлять недостающие зависимости, что бывает сложно сделать, когда "уже всё установлено".
В Вашем случае сборка (и пробная установка) пакета в контейнере может быть полезной с точки зрения "не засорять рабочую систему", но в целом сборка на системе, где нет libssl-dev и отключение libssl-dev при конфигурировании пакета - это по сути одно и то же. Просто в первом случае configure ищет ssl и не находит, а во втором даже не ищет.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Аватара пользователя
жучара
Сообщения: 937
ОС: астралинукс

Re: Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение жучара »

Hephaestus писал:
12.06.2020 17:16
В списке changes первым пунктом указано
Use pkg-config to locate openssl dependencies to fix ermt linking.
Здесь как бы корень Вашей проблемы с pkg-config, поскольку это указано в числе новшеств, раньше этого не было, надо полагать.
а где вы это прочли?
Я просто читаю маны.
Спасибо сказали:
Аватара пользователя
Hephaestus
Сообщения: 3729
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2
Контактная информация:

Re: Если пакет (libssl-dev) влияет на сборку другого пакета (dump), то что делать?

Сообщение Hephaestus »

жучара писал(а):
12.06.2020 18:06
а где вы это прочли?
Тарбол с исходниками dump_0.4b46.orig.tar.gz
Внутри есть файл NEWS.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:
Ответить