base64.exe при активированном AppLocker
Open/Libre Office extension for converting eBooks in fb2 format
Brought to you by:
ikonta_521
Menu
▾
▴
Если в системе включена политика блокирования приложений (служба Application Identity) и настроен AppLocker по дефолту, то он будет блокировать ВСЕ скрипты и исполняемые файлы, которые пытаются запуститься не из папки Program Files и не из папки Windows.
В связи с чем вопрос: можно ли сделать так, чтобы рабочие файлы и скрипты для FBTools располагались в папке LibreOffice / OpenOffice?
Почему только base64?
OOoFBTools использует (а на платформе самой распространённой ОС вынужден и таскать за собой) ещё и uuidgen…
Я давно, как бы не с самого начала говорил, что таскание с собой win32-бинарников — порочный подход. Неизбежно ведущий к ошибкам и необходимости сочинения новых исключений.
По мне правильным решением было бы, для начала обратиться в службу поддержки фирмы майкрософт с вопросом о windows-style подходе к решению задач кодирования в base64 и получению уникального идентификатора ☺
Использование каталога программы более чем одной программой-установщиком — тоже путь к приключениям.
При наличии заинтересованных и достаточно грамотных пользователей Windows я полагаю правильным убрать эти два бинарника из состава расширения и устанавливать их отдельно (заодно исчезнет необходимость дублирования в составе дистрибутива фактически внешней зависимости).
ЗЫ: Касаемо установки «скриптов»… во-первых, нужно оповестить апстрим (в том числе LO/OO, но начиная конечно же с майкрософта…) о том, что простая, понятная и доступная эталонному простопользователю установка [расширений LO/OO] работает далеко не всегда.
Но документированность альтернатив… да апстримом… мягко говоря оставляет желать лучшего (в доке LO посвящённой расширениям я не встретил не то, что описания, но даже упоминания об альтернативах).
У меня оно так и сделано (правда исходя из совсем других соображений):
Как это же воспроизвести на Windows (ну кроме тупого копирования файлов из профиля пользователя), не говоря уже о том, как сделать правильно — не знаю.
Не желаете проработать вопрос создания дистрибутива системного установщика для Windows? ;)
В Windows есть встроенные классы для работы с base64:
https://msdn.microsoft.com/ru-ru/library/windows/apps/xaml/hh802422.aspx?f=255&MSPPError=-2147217396
и
https://msdn.microsoft.com/en-us/library/windows.security.cryptography.cryptographicbuffer.encodetobase64string.aspx
а LO и OO используют костыли...
Извините, но желания создавать дистрибутив нет. Точнее нет знаний и времени.
Дык то класс, а интересна утилита…
Далее: согласно описаниям, данное революционнейшее новшество появилось ажно в Windows 8.
Мы конечно знаем политику партии и мечты производителя (о немедленном обновлении пользователей устаревших версий Ос, с соответствующими выплатами дани), но OO/LO внезапно работают далеко не только на платформе Windows 8+, как о том мечтается производителю, но как бы не на Windows2000 (и уж с гарантией — на «лучшей ОС майкрософта»©™).
Соответственно рисование исключений для 8+, даже наиправильнейших и совершенно оправданных, — даёт лишь усложнение матрицы основной задачи.
Революционных нововведений в лице утилиты для кодирования в base64, вместе с поддержкой uuidgen ждать ещё лет пятнадцать? ;)
И да: я правильно понимаю, что при стандартной-умолчательной установке OOoFBTools (в профиль пользователя) AppLocker внезапно блокирует не всё расширение (ибо скрипты), а только base64?
AppLocker блокирует ВСЕ скрипты и исполняемые файлы, которые запускаются НЕ из папки Windows или НЕ из папки Program Files.
Т.е. далеко не только base64, и даже не только uuidgen, но расширение в принципе?
Тогда тема названа того… немного неправильно.
Что также указывает на неполноту документации проекта:
https://wiki.documentfoundation.org/Documentation/HowTo/install_extension
Если твоих знаний матчасти и наглийского языка недостаточно для надлежащей корректировки, об этом необходимо как минимум сообщить разработчику.
Согласно хорошо спрятанной странице, инфраструктурные баги просят не сообщать в основной трекер собственно офиса, но по отдельному адресу:
Т.е. это нужно обращаться к девам OO и LO? Поскольку у меня нет инфраструктуры, то я могу и вручную выставить для себя разрешения. Хотя, если пакетом FBTools пользуются в офисе, будут большие напряги с включенным AppLocker.
Скорее — они крайние с точки зрения OOoFBTools.
Но переваливать на них проблему полностью — верный путь к CANTFIX.
Что нам не нужно.
Здесь нужно давать дэвам кусочки проблемы, в красиво нарезанном и практически полностью вписывающемся в их область компетенции виде.
Я полагаю правильной последовательность примерно следующего вида:
1. Для симметрии добавить OOoFBTools в каталог расширений LO (для AOO в принципе можно начинать с пункта 2). Работаю над этим, но пока до конца квест не прошёл.
2. Вопрос по твою душу: я правильно понимаю, что AppLocker блокирует расширение полностью, а не только внешние бинарники (base64 и uuidgen)?
В таком случае надо смотреть офф. доки, описывающие установку расширений. У LO я видел описание только одного сценария — установки пользователем в его (пользовательский) профиль. Что в данном случае очевидно не работает (или в лучшем случае работает не вполне).
С популярным изложением причины и условий надо ставить вопрос о расширении описания как минимум описанием общесистемной установки. В идеале — с приложением шаблонов спеков хотя бы для rpm и deb.
3. Следующая линия — решение проблемы непотребщины (включения в состав дистрибутива win32-бинарников). Линия — FR с просьбой сделать интерфейс к вызову этих функций в языке расширения. С приложением приведённых тобой ссылок на классы для base64 (появившиеся в 8, но с учётом как бы не свершившейся смерти 7 упираться в совместимость с древностями чревато), а я покопаю документацию фрюниксов.
Ну и наверное здесь же стоит реинкарнировать мой FR к OOoFBTools про виртуалы для внешних утилит base64/uuidgen. В качестве альтернативы к встроенным функциям (которые мы пока только собираемся просить у апстрима), но которых может не быть на некоторых платформах.
Вот тот баг про виртуала для base64 и K°.
Изначальный вопрос был к тому, что функция реализуется несколькими утилитами, а потому жёсткая фиксация в коде конкретной реализации неправильна.
По мотивам предварительно решённого бага (?) про окно с выводом результатов по этапам экспорта, там же можно было бы выводить и сообщения о пропуске этапа по причине недоступности функции (например тот же ванильный Демьян, base64 и экспорт графики).
А это не подойдет?
http://web.archive.org/web/20060527094535/http://www.nonhostile.com/howto-encode-decode-base64-vb6.asp
Ты пожалуйста не скачи с вопроса на вопрос, а сначала обозначь масштаб проблемы: если AppLocker блокирует работу устанавливаемого пользователем (основной и единственный описанный как минимум сейчас в прикладной документации LO сценарий) расширения, то упираться в представление внешних модулей расширения… несколько преждевременно.
По сути конкретного предложения:
Во-первых, не забывай о том, что base64 является не единственными исполняемым файлом win32, прилагаемым к OOoFBTools. Есть ещё uuidgen.
Во-вторых, начинать надо с вопроса почему автору расширения пришлось включить в дистрибутив эти файлы?
Ответ: это оказался даже не простейший, но как бы не единственный возможный способ прозрачно для пользователя платформы windows гарантировать доступность данных функций (формирования строки уникального идентификатора и кодирования в base64).
Ведь предлагаемый вариант решения, не вдаваясь в детали совместимости, необходимо устанавливать отдельно (т.е. не факт, что он сразу доступен)?
Мой вопрос большей частью сводился лишь к одному - можно ли в LO устанавливать расширения ДЛЯ ВСЕХ пользователей не в профиль к каждому из них, а в ОБЩУЮ папку, туда же, где и файлы LO. Например в папку СО СКРИПТАМИ "C:\Program Files (x86)\LibreOffice 4\share\Scripts\"
Ответ на этот вопрос в моём первом комментарии.
Можно.
Только не в каталог со скриптами, а в каталог расширений.
В данной структуре — «C:\Program Files (x86)\LibreOffice 4\share\extensions\»
Но cd туда и unzip /path/to/dist-unpack/OOoFBTools-2.36/OOoFBTools.oxt — извращение, сильно отдающее известной ересью.
А вопрос о документировании сборки пакета должно адресовать апстриму.