Ситуация: Есть некий заказчик, у которого в закрытой сети работают сотрудники. Внутри, помимо прочего, есть веб-сайты с приложениями, для доступа к которым используется обычный Google Chrome. Внезапно уже им поставили задачу - перейти на ГОСТ. Везде. Пришлось им ставить Крипто-Про, разворачивать ГОСТовскую криптографию, и ставить известный в узких кругах софт CAdEs-plugin (или как там правильно в тамошнем капсе) для работы с ЭП. Софт состоит из двух частей - локальной программы и браузерного плагина, и с установкой последнего возникли сложности. Я думаю, что подобная ситуация может возникнуть не только с конкретно этим расширением, поэтому решил написать статью со сводкой необходимой информации в одном месте.

Механизм установки был определен давно - групповые политики, благо Хром их поддерживает довольно давно. Однако все описания установки расширений через политики оказались, мягко скажем, неполными либо устаревшими, и их применение в тестовом домене не приводило к успеху. В то же время, стоило включить доступ в Интернет, и расширения прекрасно устанавливались, но только если не указывать место, где проверять обновления.

Политики установки описаны здесь - относительно известное место в Гугле, которое легко ищется встроенным поисковиком, но не описывает достаточно деталей, чтобы настроить автоматическую установку без доступа в Интернет. Если присмотреться, абсолютно все примеры отсылают к установке через https, причем стабильно с URL магазина Google. Другие результаты в Интернете намекали на возможность использования в качестве источника файлов UNC-путей (т.е. общих файловых ресурсов).

Дальнейший поиск спустя солидное время и много подходов привел вот на этот нерешенный вопрос в поддержке Гугла, где внезапно обнаружился недостающий, как впоследствии оказалось, один из двух, элемент, необходимый для решения задачи - шаблон XML-файла с примером, который у пользователя как раз не работал. Сам файл представляет собой структуру ответа Google Update с выделенным элементом приложения, местом нахождения обновления и его версией. Выглядит шаблон так:

<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
  <app appid='ID'>
    <updatecheck codebase='file:///UNC-PATH-TO-CRX-FILE' version='VERSION' />
  </app>
</gupdate>

Что меня порадовало больше всего, так это указание, в каком формате правильно задавать UNC-путь. Быстрая проверка показала, что нет, не всё так легко, и файл с расширением, заботливо скачанный ещё в самом начале, оказался не у дел. Зато в соседних политиках с ExtensionInstallForcelist нашлись некоторые дополнительные настройки, из которых удалось собрать полный паззл.

Итак, для того, чтобы установить расширение в управляемый Хром без доступа в Интернет понадобилось настроить три политики, создать один файл и выложить само расширение в доступное место. Политики были следующими:

• ExtensionInstallForcelist - создан список из 1 элемента, с ID расширения и UNC-путем через file:/// для корректности поиска;

• ExtensionInstallSources - создан список из 1 элемента (но можно и двух), содержащий разрешенные пути для поиска источников обновлений. Описание указывает, что значениями являются регулярные выражения, однако рабочий пример содержал обычный wildcard match для проверки, его я и использовал, добавив элемент со значением \\server\share\* .

• И похоже, элемент, на котором споткнулся автор того самого вопроса в техподдержку - политика ExtensionSettings, в описании которой содержится на редкость странный пункт:

  Если для экспериментального параметра override_update_url указано значение True, расширение будет установлено и обновлено с помощью URL обновления, указанного в правиле ExtensionInstallForcelist или в поле update_url правила ExtensionSettings.

  Как оказалось при тестировании, если этот параметр не задан или отключен, то если расширение внутри своего файла CRX содержит URL расположения обновления в "Интернет-магазине Chrome", Хром не станет его устанавливать откуда-либо ещё, даже если ему об этом явно сказать. Проблема ещё и в том, что параметр экспериментальный, значит, может пропасть в любой момент, но пока он есть и пока текущая версия Google Chrome, установленная у заказчика, его понимает, задача будет выполнена. (Последняя на текущий момент версия 96.0 - понимает) По крайней мере, сама политика допускает указание URL поиска обновлений для расширения в явном виде, т.о. в случае прекращения обработки override_update_url можно её использовать для задания URL обновления вместо переадресации через XML-файл. Значение политики для Windows представляет собой JSON, сжатый в одну строку REG_SZ, и для успешной установки расширения хватило JSON вида
  { "id": { "override_update_url": true }}

После такой настройки политик Chrome успешно установил расширение из файла в общей папке.