Не устанавливается mysql-libmysqlclient. Как исправить?

Какой смысл рассуждать про идеальные шарообразные проекты, когда речь об одном вполне конкретном? Это не рациональная трата времени.

Кстати, вот тебе навскидку — пакет mysql не умеет в prepared statements. Вообще. Никак. В отличии от mysql2 =).

Больше того, вместо prepared statements он использует построение запроса экранированием и конкатенацией, но внутри себя.

Причём довольно внезапным для некоторых образом:

"SELECT * FROM user WHERE user = ? AND ?", ['a', {'foo.bar.baz': 1}]

SELECT * FROM user WHERE user = 'a' AND `foo`.`bar`.`baz` = 1

"SELECT * FROM user WHERE user = ?", [{a: 1, b: 2}]

SELECT * FROM user WHERE user = `a` = 1, `b` = 2

Ну плюс ещё можно заоверрайдить toString и получить то, что с виду выглядит как SQLi (но это в реальности не встретится, так как если ты позволяешь пользователю писать код toString — у тебя гораздо большие проблемы, чем SQLi).

Но это один фиг несколько не то, что ожидаешь от того, что выглдяит как prepared statements. Зарепортил: https://github.com/mysqljs/sqlstring/issues/6

Это не для всех ключевая фича. Например мне не надо.

Ну как хочешь. Да, забыл сказать — у них там уже были уязвимости, связанные с тем, что они ручками экранируют.

Апи от этого перестало быть безопасным и удобным? Они не фиксили ошибку годами после репорта? Ты опять скатываешься в технические детали, теряя общую картину. Это чисто хакерский подход - найти одну ошибку и забить на все остальное т.к. «задача по ломанию решена». Но при разработке, когда нужно не ломать а создавать, данный подход не продуктивен.

У меня недавно в pako (порт zlib на js) нашелся эпичный баг в deflate. После репорта ушел месяц до фикса, т.к. в итоге пришлось отрывать программиста от основного проекта. Но никто не рвал фуфайки и не хлопал дверью. Потому что знали, что проблема не провиснет и будет решена.

Ты опять скатываешься в технические детали, теряя общую картину. Это чисто хакерский подход - найти одну ошибку и забить на все остальное т.к. «задача по ломанию решена»

Ты, видимо, что-то не так понимаешь. Причём многое чего. Можно занудствовать и начать с термина «хакер», но я лучше на другое укажу: нет, типичный подход — произвести анализ, найти список уязвимостей, дальше собрать все возможные инстансы каждой. Но это к сути не относится, просто «типично» — именно это, а не то, что ты сказал.

К сути тут относится только одна вещь — как я оцениваю потенциальные проблемы безопасности от использования библиотеки по сравнению с альтернативами. Не «какая из них ломается». Не «в какой были дыры 100 лет назад». А оценка потенциальных проблем в будущем, причём сравнительная. Всё остальное — детали.

И несмотря на то, что у mysql есть некоторое преимущество за счёт массовости, у него есть несколько тревожных флажков (да, беглый осмотр нашёл уже несколько), указывающих на то, что он менее аккуратно сделан и в целом менее надёжен.

IMHO то что важно для моих проектов, я понимаю правильно :) . Внутренняя имплементация mysql полностью изолирована через API от внешнего приложения. Ее изменения и улучшения ничего снаружи не заденут. А вот если драйвер будет глючить, как mysql-libmysqlclient, то от рассуждений что у него потроха красивые никому легче не станет.

Для разработки важна не оценка проблем безопасности, а оценка стоимости решения проблем с пакетом. Причем всех проблем, а не только безопасности.

Внутренняя имплементация mysql полностью изолирована через API от внешнего приложения. Ее изменения и улучшения ничего снаружи не заденут.

Причём тут это, извиняюсь? Оно не полностью изолировано, пользователи в формочки данные шлют, они попадают внутрь запросов, всё такое. Так что если оно сломается — снаружи это именно что будет очень даже заметно. Если бы оно вообще никак ни на что не влияло — его можно было бы выкинуть.

Для разработки важна не оценка проблем безопасности, а оценка стоимости решения проблем с пакетом. Причем всех проблем, а не только безопасности.

Я пока что не услышал про какие-либо другие проблемы =). Ты же сам сказал, что API совместим, пока что мы рассматриваем ситуацию «при прочих равных».

Оно не полностью изолировано

Оно изолировано на уровне архитектуры и data flow. При помощи хорошего и стабильного API. И когда идет речь о проектировании (выборе библиотек), эти критерии работают, и дают что-то конструктивное, в отличие от рассуждений про код на низком уровне.

Я пока что не услышал про какие-либо другие проблемы =)

IMHO грамотный подход к проектированию заключается в том, чтобы не создавать проблем, а не в том чтобы их героически превозмогать. Мне не понравились какие-то тикеты, уже не помню какие, возможно их закрыли. А то проблемы бывают серьезные - уже было с mysql-libmysqlclient, где доходило до потерь коннектов, и автореконнект надо было костылять с неимоверными усилиями.