There are configuration keys under ooO.ExtensionManager/ExtensionSecurity/ that can be used to disable the Add/Remove buttons in the Extension Manager dialog. However if these are enabled, the unopkg still can install/remove extensions, as it does not respect these keys. 1. Download any extension from https://extensions.libreoffice.org/ 2. Go to Tools - Options - Advanced - Expert configuration 3. Search for extensionsecurity name 4. Set the DisableExtensionRemoval and DisableExtensionInstallation keys to true 5. Close the dialogs, go to Tools - Extension Manager -> The Add and Remove buttons are disabled: this is good 6. Go to the command line, try running from the installation directory the instdir/program/unopkg add foo.oxt command (or unopkg.com on Windows), where the foo.oxt is what you downloaded in the first point. -> the extension is installed. This is inconsistent with the intention of setting these config keys set in step 4. 7. Use instdir/program/unopkg list to determine the internal identifier of the installed extension 8. Use instdir/program/unopkg remove $identifier to remove the just installed extension -> this also succeeds, which is also inconsistent with step 4. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d7577174b541e68158d228aa41192227c10a252f CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded
(In reply to Gabor Kelemen (allotropia) from comment #0) > There are configuration keys under ooO.ExtensionManager/ExtensionSecurity/ > that can be used to disable the Add/Remove buttons in the Extension Manager > dialog. ...which had been added with a fix for issue 36019 "Security: Add some way to dynamically enable/disable extension installation"... > However if these are enabled, the unopkg still can install/remove > extensions, as it does not respect these keys. ...and note that issue 36019 had deliberately left unopkg functionality unchanged (for better or worse; just saying)
(In reply to Gabor Kelemen (allotropia) from comment #0) > 6. Go to the command line, try running from the installation directory the > instdir/program/unopkg add foo.oxt > command (or unopkg.com on Windows), where the foo.oxt is what you downloaded > in the first point. > -> the extension is installed. This is inconsistent with the intention of > setting these config keys set in step 4. Reproduced. > 8. Use > instdir/program/unopkg remove $identifier > to remove the just installed extension > -> this also succeeds, which is also inconsistent with step 4. Reproduced. (In reply to Stephan Bergmann from comment #1) > ...and note that issue 36019 had deliberately left unopkg functionality > unchanged (for better or worse; just saying) Thanks for pointing that out, Muhammet bug 36019 comment 16 says it was by design: (In reply to Muhammet Kara from bug 36019 comment #16) > (In reply to Heiko Tietze from bug 36019 comment #14) > > Sounds good. But don't forget the unopkg command-line option to add, > > validate, remove, reinstall, and list extensions. > > As this feature is for use of advanced users (or admins), disabling the > unopkg commands seems unnecessary since it can be enabled/disabled via the > expert configurations. Moreover, advanced users (or admins) might want to be > able to add/remove extensions while preventing the regular users from > installing/removing extensions. Gabor and Heiko, what do you think?
(Muhammet Kara from comment #16) > As this feature is for use of advanced users (or admins), disabling the > unopkg commands seems unnecessary since it can be enabled/disabled via the > expert configurations. Moreover, advanced users (or admins) might want to be > able to add/remove extensions while preventing the regular users from > installing/removing extensions. -> NAB/WF (last word for Gabor)
There was a change recently in the Expert dialog and now the finalized state of settings is now respected there. Therefore the notion from bug #36019 comment 16 that these settings can be enabled/disabled by the user if they want - is now obsolete. So if an admin really wants to harden the installation (and our current customer is into that), can do so and be sure that the user does not disable the settings there. About unopkg: it can work on different contexts, as the --help text says: --shared expert feature: operate on shared installation deployment context; run only when no concurrent Office process(es) are running! --bundled expert feature: operate on bundled extensions. Only works with list, validate, reinstall; It makes sense that the admins should be able to deploy new extensions to all machines, even if this is not desired for end users. The --shared mode is exactly for that. Therefore, the config keys should be respected if this mode is not used, but ignored if it is. This would forbid the end users from installing extensions for good (no more backdoors via turning off keys in Expert config or using CLI), but keep the option open for admins, who would not be locking themselves out from updating their custom extensions.