curl не может скачать файл - Сети, сокеты, протоколы

Периодически качаю CureIt! с drweb.com из-под Windows 7. Firefox и Chrome скачивают всегда и без проблем. curl периодически ведет себя странно. Вот сейчас так:

7.62.0:

curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) — The revocation function was unable to check revocation because the revocation server was offline.

7.78.0 (последний):

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.

Чего ему надо, почему он не может сделать так же, как и браузеры?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Чего ему надо, почему он не может сделать так же, как и браузеры?

По ссылке есть объяснение. Если вкратце, то твоя сборка curl использует для SSL функции ОС и соответственно сертификаты в системном хранилище. И ошибка эта оттуда.

Firefox их не использует, у него все свое. Chrome вроде как использует, но хз в чем разница.

Здравствуйте, wildwind, Вы писали:

W>По ссылке есть объяснение.

Я начал там читать, но с виду оно выглядит, как обычное разъяснение чайникам о том, что такое SSL/TSL, сертификат, доверие и прочее. Забил пару слов в поиск, но неудачно, поэтому и не добрался до нужного места.

Спасибо!

Подсунул curl пакет сертификатов от Mozilla, дело пошло.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>curl: (60) SSL certificate problem: unable to get local issuer certificate
ЕМ>Чего ему надо, почему он не может сделать так же, как и браузеры?

Кстати, помимо озвученной причины с разными корневыми сертификатами, в браузерах ещё есть особая и сложная работа с Authority Information Access (AIA), которой нет в curl.

Сертификат сайта может иметь валидный путь до корневого. Но сервер может быть плохо сконфигурирован и не присылать всю длинную цепочку сертификатов. И при этом замечательно открываться в браузерах, так как информации из AIA достаточно чтобы проверить подлинность.
А браузеры либо самостоятельно запрашивают промежуточные сертификаты по ссылкам из AIA (chromium), либо используют кеш сертификатов из других цепочек и строят путь через него (firefox).

А вот curl, как отдельная утилита, не имеет кеша промежуточных сертификатов, и отказывается ходить по ссылкам из AIA за промежуточными сертификатами (так как это дополнительный и сложный запрос в сеть, который аналогично может временно зафейлится, или потребовать другого запроса сертификатов уже для своего подтверждения, и так далее).

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

Здравствуйте, watchmaker, Вы писали:

W>И получается такая же ситуация: сайт в браузерах у всех открывается, а SSL проверку в curl не проходит. Конечно, формально тут проблема у сайта (нарушают требования присылать полную цепочку), но на практике от этого не легче

Я иногда жалею, что в айти нет своего аналога Энергонадзора. Чтобы вот таким сайтам выкатывали штраф по 100 долларов в день на уровне хостера.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Периодически качаю CureIt! с drweb.com из-под Windows 7. Firefox и Chrome скачивают всегда и без проблем. curl периодически ведет себя странно. Вот сейчас так:

ЕМ>7.62.0:
ЕМ>

ЕМ>curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) — The revocation function was unable to check revocation because the revocation server was offline.

Т.е. дефолтный CRL-сервер сейчас не может ответить (занят, перезагружается и т.п.), поэтому приложение должно иметь несколько адресов куда стучаться. У курла, очевидно, этого в дефолтном поведении не предусмотрено.

ЕМ>Чего ему надо, почему он не может сделать так же, как и браузеры?

Собственно, это и отличает простой код, работающий по happy path, и код промышленный — со всеми retry policies, fallbacks etc.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Т.е. дефолтный CRL-сервер сейчас не может ответить (занят, перезагружается и т.п.)

Неделю?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Т.е. дефолтный CRL-сервер сейчас не может ответить (занят, перезагружается и т.п.)

ЕМ>Неделю?

Почему бы и нет? Либо какой-то maintenance, либо старый сервак вообще декоммисовали, запросы обламываются и пересылаются нормальными клиентами на fallback-адрес (как с DNS — если primary-сервак дал ошибку, есть secondary, ну а если и он помер — всегда можно сходить на волшебный 8.8.8.8)

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Периодически качаю CureIt! с drweb.com из-под Windows 7. Firefox и Chrome скачивают всегда и без проблем. curl периодически ведет себя странно. Вот сейчас так:

ЕМ>7.62.0:
ЕМ>

ЕМ>curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) — The revocation function was unable to check revocation because the revocation server was offline.

ЕМ>7.78.0 (последний):
ЕМ>

ЕМ>curl: (60) SSL certificate problem: unable to get local issuer certificate
ЕМ>More details here: https://curl.se/docs/sslcerts.html

ЕМ>curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.

ЕМ>Чего ему надо, почему он не может сделать так же, как и браузеры?

Что в ошибках написано понимаеш примерно?

у curl есть опция --insecure для игнора валидности серверных сертификатов.

что бы curl как браузеры работали надо ему подсовывать свежие корневые сертификаты или отключать проверку сертификатов как я выше написал.

сами сертификаты которые понимает curl лежат здесь https://curl.haxx.se/ca/cacert.pem. Переменная окружэния нахывается CURL_CA_BUNDLE. В винде не проверял, только в линуксе. В винде если работает/неработает дай знать

Здравствуйте, VladCore, Вы писали:

VC>В винде если работает/неработает дай знать

Я ж еще позавчера написал, что работает.

Здравствуйте, watchmaker, Вы писали:

W>И получается такая же ситуация: сайт в браузерах у всех открывается, а SSL проверку в curl не проходит. Конечно, формально тут проблема у сайта (нарушают требования присылать полную цепочку), но на практике от этого не легче

Несколько месяцев назад оно снова перестало работать (и 7.78.0, и свежий 8.6.0), с теми же ошибками (curl: (60) SSL certificate problem: unable to get local issuer certificate), и сертификаты Mozilla уже не помогают. Лог вот такой:

	Лог curl
	* Host free.drweb.com:443 was resolved. * IPv6: (none) * IPv4: 213.79.65.58 * Trying 213.79.65.58:443... * Connected to free.drweb.com (213.79.65.58) port 443 * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: C:\Tools\Certificates\mozilla_cacert.pem * CApath: none * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 / [blank] / UNDEF * ALPN: server accepted http/1.1 * Server certificate: * subject: CN=.drweb.com start date: Jan 10 09:51:58 2024 GMT * expire date: Feb 10 09:51:57 2025 GMT * subjectAltName: host "free.drweb.com" matched cert's ".drweb.com" issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign GCC R3 DV TLS CA 2020 * SSL certificate verify ok. * Certificate level 0: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption * Certificate level 1: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption * Certificate level 2: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption * using HTTP/1.x > GET /download+cureit/gr/?lng=en HTTP/1.1 > Host: free.drweb.com > User-Agent: curl/8.6.0 > Accept: / > < HTTP/1.1 302 okay < Server: nginx < Date: Tue, 19 Mar 2024 21:30:13 GMT < Content-Type: text/html; charset=utf-8 < Transfer-Encoding: chunked < Connection: keep-alive < Set-Cookie: lng=en; domain=.drweb.com; path=/; expires=Wed, 21-Feb-2029 21:30:13 GMT < Set-Cookie: lng=en; domain=.drweb.com; path=/; expires=Wed, 21-Feb-2029 21:26:55 GMT < Strict-Transport-Security: max-age=86400; includeSubDomains < Location: https://cdn-download.drweb.com/pub/drweb/cureit/1710881535.55/vwpo14ex.exe < Set-Cookie: drwse=8d3712c31ffcd31f42aa6f5db48c56fd; domain=.drweb.com; path=/; expires=Wed, 21-Feb-2029 21:30:13 GMT < X-BESKW: jimmy < X-XSS-Protection: 1; mode=block < X-Frame-Options: SAMEORIGIN < X-Content-Type-Options: nosniff < Referrer-Policy: no-referrer-when-downgrade < Content-Security-Policy: frame-ancestors 'self' < * Ignoring the response-body * Leftovers after chunking: 12 bytes * Connection #0 to host free.drweb.com left intact * Issue another request to this URL: 'https://cdn-download.drweb.com/pub/drweb/cureit/1710881535.55/vwpo14ex.exe' * Host cdn-download.drweb.com:443 was resolved. * IPv6: (none) * IPv4: 193.17.93.93 * Trying 193.17.93.93:443... * Connected to cdn-download.drweb.com (193.17.93.93) port 443 * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Unknown (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * SSL certificate problem: unable to get local issuer certificate * Closing connection curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.

Я правильно понимаю, что теперь cdn-download.drweb.com вообще не отдает сертификата?

Можно как-то подавить проверку сертификата именно вторичного сервера, оставив проверку первичного (free.drweb.com)? Или только скопом через -k?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Можно как-то подавить проверку сертификата именно вторичного сервера, оставив проверку первичного (free.drweb.com)? Или только скопом через -k?

С учетом той легкости, с которой сейчас любой придурок может бесплатно получить валидный сертификат на любой домен, SSL по факту перестал удостоверять подлинность сайта и потерял смысл.

Здравствуйте, Stanislaw K, Вы писали:

SK>С учетом той легкости, с которой сейчас любой придурок может бесплатно получить валидный сертификат на любой домен, SSL по факту перестал удостоверять подлинность сайта и потерял смысл.

Это понятно. Но для автоматизированного скачивания приблуды, запускаемой с правами администратора, хотелось бы хоть какого-то контроля. -k отключает его напрочь.

Здравствуйте, Евгений Музыченко, Вы писали:

SK>>С учетом той легкости, с которой сейчас любой придурок может бесплатно получить валидный сертификат на любой домен, SSL по факту перестал удостоверять подлинность сайта и потерял смысл.

ЕМ>Это понятно. Но для автоматизированного скачивания приблуды, запускаемой с правами администратора, хотелось бы хоть какого-то контроля. -k отключает его напрочь.

УМВРЧЯДНТ

использую "устаревший" curl 8.4.0

C:\temp>curl -L https://free.drweb.com/download+cureit/gr/?lng=en --output drweb-curit.tmp
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                               Dload  Upload   Total   Spent    Left  Speed
100   280    0   280    0     0    940      0 --:--:-- --:--:-- --:--:--   949
100  301M  100  301M    0     0  9831k      0  0:00:31  0:00:31 --:--:-- 5783k

C:\temp>curl -V
curl 8.4.0 (Windows) libcurl/8.4.0 Schannel WinIDN
Release-Date: 2023-10-11
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
Features: AsynchDNS HSTS HTTPS-proxy IDN IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI threadsafe Unicode UnixSockets

Обновил curl до актуального

C:\temp>curl -V
curl 8.6.0 (x86_64-w64-mingw32) libcurl/8.6.0 LibreSSL/3.8.3 zlib/1.3.1 brotli/1.1.0 zstd/1.5.5 WinIDN libpsl/0.21.5 libssh2/1.11.0 nghttp2/1.60.0 ngtcp2/1.4.0 nghttp3/1.2.0
Release-Date: 2024-01-31
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL SSPI threadsafe UnixSockets zstd                                                                                                                                                                                                                                             

C:\temp>curl --ca-native -L https://free.drweb.com/download+cureit/gr/?lng=en --output drweb-curit.tmp
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                               Dload  Upload   Total   Spent    Left  Speed
100   280    0   280    0     0    993      0 --:--:-- --:--:-- --:--:--  1007
100  301M  100  301M    0     0  10.6M      0  0:00:28  0:00:28 --:--:-- 9798k

хватило добавить опцию " --ca-native Use CA certificates from the native OS"

Здравствуйте, Stanislaw K, Вы писали:

SK>УМВРЧЯДНТ

Мистика.

SK>хватило добавить опцию --ca-native

Попробовал и с нею — никакой разницы.

Из убогого лога curl можно как-то понять конкретную причину отказа?

Здравствуйте, Евгений Музыченко, Вы писали:

SK>>хватило добавить опцию --ca-native

ЕМ>Попробовал и с нею — никакой разницы.

Есть версия что у тебя где-то из путей curl-ca-bundle.crt просроченный подхватывается.

ЕМ>Из убогого лога curl можно как-то понять конкретную причину отказа?

--trace-ascii <filename.log>

Еще вариант описан https://curl.se/docs/sslcerts.html Если возникают сложности с цепочкой сертификата сервера, вручную пройтись по цепочке, собрать все сертификаты и подсовывать их curl.

Get a CA certificate that can verify the remote server and use the proper option to point out this CA cert for verification when connecting. For libcurl hackers: curl_easy_setopt(curl, CURLOPT_CAINFO, cacert);

With the curl command line tool: --cacert [file]

Add the CA cert for your server to the existing default CA certificate store. The default CA certificate store can be changed at compile time with the following configure options:

--with-ca-bundle=FILE: use the specified file as the CA certificate store. CA certificates need to be concatenated in PEM format into this file.

--with-ca-path=PATH: use the specified path as CA certificate store. CA certificates need to be stored as individual PEM files in this directory. You may need to run c_rehash after adding files there.

С некоторыми cdn будут сложности при таком способе, так как там ноды "на лету" генерят сертификаты используя при этом разные CA и сами ноды постоянно ротируются. Пока в firefox работал addon CertPatrol очень утомлял предупреждениями.

Здравствуйте, Stanislaw K, Вы писали:

SK>Есть версия что у тебя где-то из путей curl-ca-bundle.crt просроченный подхватывается.

Я вместо него пробовал и мозилловский подсовывать. Тоже никакой разницы.

SK>--trace-ascii <filename.log>

Спасибо — тут хотя бы видно, что сервер отдает сертификат. Но дальше снова непонятно — то ли просто не удается найти подходящий к нему следующий (и какой из них?), то ли не удается вообще получить доступ к локальным сертификатам для проверки.

SK>Еще вариант описан https://curl.se/docs/sslcerts.html Если возникают сложности с цепочкой сертификата сервера, вручную пройтись по цепочке, собрать все сертификаты и подсовывать их curl.

Это все разновидности методов тыка. Я в таких случаях совершенно теряюсь: вроде бы люди, делающие такой софт, должны быть умнее и дальновиднее среднего программиста, и понимать, что в логи нужно выводить всё, что может помочь идентифицировать проблему, а не только лаконичное сообщение, обрекающее пользователя на длительный поиск наугад. Но раз за разом натыкаюсь на поделия, сделанные вроде бы профессионалами, но с совершенно детскими косяками, которые не исправляются годами. А жалобам на эту ошибку уже лет пятнадцать...

SK>С некоторыми cdn будут сложности при таком способе, так как там ноды "на лету" генерят сертификаты используя при этом разные CA и сами ноды постоянно ротируются. Пока в firefox работал addon CertPatrol очень утомлял предупреждениями.

Но тот же Firefox без проблем скачивает файлы по той же ссылке. Значит, или может проверить полностью, или пропускает только отдельные проверки, не забивая на сертификаты вообще.

Кстати, сейчас обратил внимание, что Ваш "устаревший" 8.4.0 был с Schannel, а "актуальный" (который и у меня) — без. А как понять, в какой сборке оно есть, а в какой — нет?

Здравствуйте, Евгений Музыченко, Вы писали:

SK>>--trace-ascii <filename.log>

ЕМ>Спасибо — тут хотя бы видно, что сервер отдает сертификат. Но дальше снова непонятно — то ли просто не удается найти подходящий к нему следующий (и какой из них?), то ли не удается вообще получить доступ к локальным сертификатам для проверки.

== Info: TLSv1.2 (OUT), TLS alert, unknown CA (560):
=> Send SSL data, 2 bytes (0x2)
0000: .0
== Info: SSL certificate problem: unable to get local issuer certificate
== Info: Closing connection
== Info: TLSv1.2 (IN), TLS handshake, Certificate (11):

сертификат dr.web он находит, а кто его выпустил — не знает.
хотя CA "GlobalSign Root CA — R3" 2009 года, а "GlobalSign GCC R3 DV TLS CA 2020" 2020 года.

Припоминается что-то про скандал с утечкой ключей GlobalSign Root в 2011 или 2013 году. может быть это влияет. хотя утёк другой серт, а этот у параноиков за компанию в недоверенных.

SK>>Еще вариант описан https://curl.se/docs/sslcerts.html Если возникают сложности с цепочкой сертификата сервера, вручную пройтись по цепочке, собрать все сертификаты и подсовывать их curl.

ЕМ>Это все разновидности методов тыка.

Обычное шаманство.

ЕМ>Я в таких случаях совершенно теряюсь: вроде бы люди, делающие такой софт, должны быть умнее и дальновиднее среднего программиста, и понимать, что в логи нужно выводить всё, что может помочь идентифицировать проблему, а не только лаконичное сообщение, обрекающее пользователя на длительный поиск наугад. Но раз за разом натыкаюсь на поделия, сделанные вроде бы профессионалами, но с совершенно детскими косяками, которые не исправляются годами. А жалобам на эту ошибку уже лет пятнадцать...

Я склоняюсь к мысли что эта проблема на стороне drweb. И решать её должен не пользователь а квалифицированный специалист на окладе.

SK>>С некоторыми cdn будут сложности при таком способе, так как там ноды "на лету" генерят сертификаты используя при этом разные CA и сами ноды постоянно ротируются. Пока в firefox работал addon CertPatrol очень утомлял предупреждениями.

ЕМ>Но тот же Firefox без проблем скачивает файлы по той же ссылке. Значит, или может проверить полностью, или пропускает только отдельные проверки, не забивая на сертификаты вообще.

Забивая. Строгую проверку нужно включать специально через about:config, но тогда половина интернета будет недоступна. и кому будет нужен такой браузер?

ЕМ>Кстати, сейчас обратил внимание, что Ваш "устаревший" 8.4.0 был с Schannel, а "актуальный" (который и у меня) — без.

Есть еще каноничный порт Cygwin https://cygwin.com/install.html

ЕМ>А как понять, в какой сборке оно есть, а в какой — нет?

Вот оно всё перечислено, библиотеки, протоколы, фичи.

C:\cygwin64\bin>curl.exe -V
curl 8.6.0 (x86_64-pc-cygwin) libcurl/8.6.0 OpenSSL/3.0.13 zlib/1.3.1 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.7 libpsl/0.21.5 libssh2/1.11.0 nghttp2/1.60.0 libgsasl/2.2.1 OpenLDAP/2.6.7
Release-Date: 2024-01-31
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli gsasl GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd


C:\cygwin64\bin>curl.exe -L https://free.drweb.com/download+cureit/gr/?lng=en --output drweb-curit.tmp
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                               Dload  Upload   Total   Spent    Left  Speed
100   280    0   280    0     0    699      0 --:--:-- --:--:-- --:--:--   705
100  301M  100  301M    0     0  11.4M      0  0:00:26  0:00:26 --:--:-- 10.9M

Здравствуйте, Stanislaw K, Вы писали:

SK>

SK>== Info: TLSv1.2 (OUT), TLS alert, unknown CA (560):

SK>сертификат dr.web он находит, а кто его выпустил — не знает.

У меня такой ошибки не было.

ЕМ>>А как понять, в какой сборке оно есть, а в какой — нет?

SK>Вот оно всё перечислено, библиотеки, протоколы, фичи.

Я о том, как понять это на этапе выбора — до скачивания, распаковки и запуска.

Ви таки будете смеяться, но я обнаружил, что скрипт, который не работал несколько месяцев, последние несколько дней снова работает нормально, даже с curl 7.78.0 и закомментаренной установкой CURL_CA_BUNDLE. Подозреваю, что и в прошлый раз оно починилось на той стороне, а не потому, что я скачал мозилловские сертификаты.

Может, кто из DrWeb нас читает?

Здравствуйте, Евгений Музыченко, Вы писали:

SK>>

SK>>== Info: TLSv1.2 (OUT), TLS alert, unknown CA (560):

SK>>сертификат dr.web он находит, а кто его выпустил — не знает.
ЕМ>У меня такой ошибки не было.

Так это не ошибка и не предупреждение, это так, "info". присутствует в выводе --trace-ascii <filename.log>

опций много,

 curl --help all

ЕМ>>>А как понять, в какой сборке оно есть, а в какой — нет?
SK>>Вот оно всё перечислено, библиотеки, протоколы, фичи.
ЕМ>Я о том, как понять это на этапе выбора — до скачивания, распаковки и запуска.

Обычно на страничке download или рядом написано.

ЕМ>Ви таки будете смеяться, но я обнаружил, что скрипт, который не работал несколько месяцев, последние несколько дней снова работает нормально,

У меня без изменений.

http://files.rsdn.org/81729/curl.trace-ascii.succes_full.log.txt
http://files.rsdn.org/81729/curl.trace-ascii.unknown_CA.log.txt

ЕМ>Может, кто из DrWeb нас читает?

Сомнительно.

От:	Евгений Музыченко	https://software.muzychenko.net/ru
Дата:	29.07.21 14:20
Оценка:

	От:	wildwind
	Дата:	29.07.21 15:28
	Оценка:	14 (1)

От:	Евгений Музыченко	https://software.muzychenko.net/ru
Дата:	29.07.21 17:38
Оценка:

	От:	watchmaker
	Дата:	29.07.21 20:22
	Оценка:	48 (4)

	От:	Слава
	Дата:	29.07.21 23:53
	Оценка:

	От:	Mr.Delphist
	Дата:	30.07.21 11:13
	Оценка:

	От:	Mr.Delphist
	Дата:	30.07.21 13:05
	Оценка:

	От:	VladCore
	Дата:	31.07.21 12:57
	Оценка: