Ситуация прояснилась: хостинг-провайдер по какой-то причине отключил экспорт переменных Apache. Код защищённых страниц (например, страницы авторизации) полагается на значение глобальных переменных $_SERVER[...] для определения протокола доступа клиента к странице: если это не HTTPS, происходит принудительный редирект. Соответственно, при отсутствии переменной (в PHP это пустое значение) происходит бесконечное число редиректов, и любой вразумительный браузер блокирует открытие такой страницы. С CGI-враппером функций OpenPGP та же история — скрипт просто не получает необходимых переменных окружения от сервера.

Хостеру отправлен запрос с просьбой прокомментировать ситуацию или, если это ошибка, исправить её.

Ну и что говорит slavehost? Кстати, я когда обновляюсь, у меня тоже часто многое что перестаёт работать.

Проблема с логином и прочими HTTPS-страницами устранена.

А какой такой slavehost? :-)

System booting... primary masterhost .... [OK] secondary masterhost... [OK] primary masterserver... [OK] secondary masterserver. [OK] primary slavehost...... [OK] secondary slavehost.... [OK] primary slaveserver.... [OK] secondary slaverserver. [OK] Logins and https errors fixed System loaded and working

:-)

Правда, если открыть мой, unknown'а или чей-нибудь ещё профиль с ключом, эта благостная картина немного подпортится. Что там за беда с CGI, пока не разбирался.

Проблема с логином и прочими HTTPS-страницами устранена.

Хостер пофиксил свои настройки?

Отчасти. Всё равно пришлось немного переписать код.

Проблемы всё ещё здесь. http://www.pgpru.com/forum/off.....hupodpisatjpgpkljuch, например.
И некоторые другие страницы.

Почти весь сегодняшний день потратил на поиск корня зла причин ошибки. И наконец установил причину. Проблема решена, функциональность сайта восстановлена в полном объёме. С чем всех поздравляю.

И какая была причина?

Ну, если это интересно... Поскольку виртуальный хостинг накладывает ограничения на прямое исполнение программ из PHP функциями exec(), popen() и т.п. (видимо, в целях безопасности), используется скрипт-обёртка на Perl, вызываемый из основной PHP-программы как простая веб-страница через обёртку fopen(). При вызове скрипта ему передаются все необходимые параметры (в HTTP-запросе), с которыми он должен выполнить gpg. А результат работы gpg в стандартном выводе загружается в вызвавшую PHP-программу, где происходит вся дальнейшая обработка.

В какой-то момент вызов Perl-скрипта через fopen() перестал создавать поток, что стало приводить к ошибкам "openSpace-GPG: unable to open CGI wrapper" везде, где требовался вызов gpg. После длительной диагностики удалось установить причину: при формировании контекста для потока fopen() функцией stream_context_create() параметр method передавался в нижнем регистре (т.е. post или get). Серверу в какой-то момент это почему-то перестало нравится, и такие соединения он начал отвергать. Перевод значения в верхний регистр снял проблему.

Но тут выявилась другая: одни вызовы gpg выполнялись корректно, а другие из-за чего-то перестали производить вывод. То есть поток открывался корректно, корректно происходило исполнение gpg, но стандартный вывод оставался пуст. При этом прямой вызов Perl-скрипта в браузере отрабатывал корректно, весь вывод gpg успешно выводился. Как выяснилось, и здесь проблема заключалась в обёртке fopen(). В тех случаях, где метод запроса был POST с установленным хидером "Content-type: application/x-www-form-urlencoded", программа получала вывод от gpg и успешно выполнялась. Там же, где использовался метод GET, вывод был пуст (что особенно удивляет). Теперь все вызовы скрипта производятся POST-запросом.

Очередное доказательство тому, что взаимодействие множества разноплановых компонентов не добавляет системе надёжности.

[offtopic]

Поскольку виртуальный хостинг накладывает ограничения на прямое исполнение программ из PHP функциями exec(), popen() и т.п. (видимо, в целях безопасности), используется скрипт-обёртка на Perl, вызываемый из основной PHP-программы как простая веб-страница через обёртку fopen().

Знакомый приём. :) Скорее проблема в том, что нестрого следуют стандартам. Это просто обязательно при соединении компонентов от разных производителей. А ещё проблема, что защита от хакеров делается самым простым способом, а не самым правильным. Сам safe-mode в PHP является отличным примером, как не надо делать. :) Да таких анекдотов у каждого наберётся: например, интернет-провайдер не отправляет письма, содержащие последовательность ".js". Видать, защищали глупых пользователей от JavaScript-вирусов. Или при публикации в блоге делаются неактивными ссылки, содержащие "cgi-bin". Тоже "защита" от чего-то. :)
[/offtopic]

Поскольку виртуальный хостинг накладывает ограничения на прямое исполнение программ из PHP функциями exec(), popen() и т.п. (видимо, в целях безопасности), используется скрипт-обёртка на Perl, вызываемый из основной PHP-программы как простая веб-страница через обёртку fopen().

Ага, а разрешать через fopen() получать веб-страницы – безопасно :)

А какой именно тариф у masterhost'а? Советую обратить внимание на американские хостинги. Там обычно за небольшие деньги дают гораздо больше возможностей. К примеру, доступ к php.ini или сырым логам веб-сервера.

Ага, а разрешать через fopen() получать веб-страницы – безопасно :)

Наверное, запрет на прямое исполнение программного кода — просто защита от быдлокодеров, которые найдут любую возможность отстрелить себе ногу. Делать то же самое через промежуточный cgi-скрипт они не догадаются. :-)

Наверное, запрет на прямое исполнение программного кода — просто защита от быдлокодеров, которые найдут любую возможность отстрелить себе ногу. Делать то же самое через промежуточный cgi-скрипт они не догадаются. :-)

Хостеру-то какое до них дело? Пусть ломают в пределах своего аккаунта что угодно :)
А речь о том, что allow_url_fopen – сама по себе опасная опция, наверное, даже более опасная, чем запрещённые exec() и компания. Ведь для того, чтобы использовать exec(), требуется найти уязвимость в движке и, в общем-то, взломщик мало что с этого поимеет (кроме удобства), ведь практически всё, что можно сделать через unix-консоль, можно делать и через PHP. А вот allow_url_fopen как раз создаёт уязвимости.