ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | [libpsl]print-info выдает ошибку "No builtin PSL data available" | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Белая Алёна <belayaav> | ||||
| Component: | libpsl | Assignee: | Mikhail Efremov <sem> | ||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||
| Severity: | normal | ||||||
| Priority: | P5 | CC: | rider, sem | ||||
| Version: | unstable | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Attachments: |
|
||||||
|
Description
Белая Алёна
2022-12-08 12:51:41 MSK
Так и задумано, libpsl собран без builtin data. В этом случае libpsl использует только информацию из publicsuffix-list-dafsa, которая гораздо более актуальна, чем может быть builtin data на момент сборки пакета. Вариант использования libpsl без publicsuffix-list-dafsa (для чего вообще нужно builtin data) у нас не предусмотрен. (Ответ для Mikhail Efremov на комментарий #1) > Так и задумано, libpsl собран без builtin data. В этом случае libpsl > использует только информацию из publicsuffix-list-dafsa, которая гораздо > более актуальна, чем может быть builtin data на момент сборки пакета. > Вариант использования libpsl без > publicsuffix-list-dafsa (для чего вообще нужно builtin data) у нас не > предусмотрен. Спасибо за подробное объяснение. Меня дополнительно смущает, что данные в выводе отсутствуют(при том, что publicsuffix-list-dafsa есть): "suffixes: - information not available - exceptions: - information not available - wildcards: - information not available -" Это тоже корректно? PSL(1):
--print-info
print info about library builtin data
Так что все правильно, builtin data действительно нет.
Некоторые приложения не умееют использовать psl_latest() вместо psl_builtin() Патчить их конечно можно, но лучше научить библиотеку жить сразу двумя способами. (Ответ для Anton Farygin на комментарий #4) > Некоторые приложения не умееют использовать psl_latest() вместо psl_builtin() > Патчить их конечно можно, но лучше научить библиотеку жить сразу двумя > способами. А апстримы этих приложений как-то обосновывают, почему они так делают? Я вижу 2 возможные причины: 1. Может не быть внешнего dafsa-файла. У нас аргумент не работает: libpsl зависит от publicsuffix-list-dafsa и такое может быть только на поломанной системе. 2. Скорость доступа к данным, к builtin данным она должна быть выше. Вот только насколько это критично? Я к тому, что можно запатчить и саму libpsl, чтобы psl_builtin() вызывала psl_latest(), в принципе. (Ответ для Mikhail Efremov на комментарий #5) > (Ответ для Anton Farygin на комментарий #4) > > Некоторые приложения не умееют использовать psl_latest() вместо psl_builtin() > > Патчить их конечно можно, но лучше научить библиотеку жить сразу двумя > > способами. > > А апстримы этих приложений как-то обосновывают, почему они так делают? > Я вижу 2 возможные причины: > 1. Может не быть внешнего dafsa-файла. У нас аргумент не работает: libpsl > зависит от publicsuffix-list-dafsa и такое может быть только на поломанной > системе. > 2. Скорость доступа к данным, к builtin данным она должна быть выше. Вот > только насколько это критично? Я к тому, что можно запатчить и саму libpsl, > чтобы psl_builtin() вызывала psl_latest(), в принципе. нет, я честно даже не думал у них спрашивать, там весьма странный и проблемный апстрим (это transmission). Но в целом аргумент про скорость весьма здравый. можно ещё builtin обновлять автоматически из publicsuffix-list-dafsa и пересобирать их одновременно. Ещё нашёл такое мнение, что многие системы безопасности используют libpsl для своей работы (Cookie isolation, проверки wildcard сертификатов, возможно какие-то браузеры, которые могут использовать psl для опеределения доменов). - и в этом случае внешняя база для libpsl может быть проблемой. Лучше всего собирать и внутреннюю как fallback/надёжности и подхватывать внешнюю как основную. (Ответ для Mikhail Efremov на комментарий #5) > можно запатчить и саму libpsl, > чтобы psl_builtin() вызывала psl_latest(), в принципе. Нет, так нельзя: возвращаемые psl_latest() ресурсы надо освобождать, в отличие от psl_builtin(). (Ответ для Anton Farygin на комментарий #6) > можно ещё builtin обновлять автоматически из publicsuffix-list-dafsa и > пересобирать их одновременно. На момент сборки используется текущий список из publicsuffix-list-dafsa. Но пересобирать каждый раз библиотеку при обновлении publicsuffix-list точно не надо, как раз для того, чтобы так не делать они и живут отдельно. Если же кто-то использует psl_builtin(), то он явно говорит "я хочу протухшие данные вместо актуальных". Ну ок, пусть будет так. Включение builtin, в принципе, грозит только тем, что библиотека станет чуть больше в размерах. Но кого это сейчас волнует. (Ответ для Anton Farygin на комментарий #7) > Ещё нашёл такое мнение, что многие системы безопасности используют libpsl > для своей работы (Cookie isolation, проверки wildcard сертификатов, > возможно какие-то браузеры, которые могут использовать psl для опеределения > доменов). - и в этом случае внешняя база для libpsl может быть проблемой. > Лучше всего собирать и внутреннюю как fallback/надёжности и подхватывать > внешнюю как основную. Я, собственно, потому и выключил builtin, что использовать лучше относительно свежие данные из publicsuffix-list. да, зачем выключил тоже понятно. Но аргумент про то, что libpsl должна работать всегда, даже когда файл с данными не смогла загрузить - меня убедил. libpsl-0.21.5-alt2 -> sisyphus: Wed Mar 04 2026 Mikhail Efremov <sem@altlinux> 0.21.5-alt2 - Enabled builtin PSL (closes: #44575). - Used macros from rpm-macros-meson. |
