https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28990 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=28882 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28990 --- Comment #2 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #1)

This has been discussed already on a separate bug report (or I discussed it privately with somebody else, cannot remember).

The idea we had was to have a new section in koha-conf to list sysprefs we couldn't edit from the UI. So it's a bit stronger than what you suggest as only the sysop could modify them.

Hmm. Interesting point. My first idea would be to keep the possibility of change by superlibrarian. If we would not want any change, we should better replace the pref by a koha-config variable? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28990 Donna <bwsdonna@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bwsdonna@gmail.com --- Comment #3 from Donna <bwsdonna@gmail.com> --- I'd be hesitant to move certain sysprefs to the koha-conf. Many times a superlibrarian is not the sysop, and would not have access to make those changes directly when needed. I like Marcel's idea of having a customizable list of preferences that can only be changed by a superlibrarian. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28990 --- Comment #5 from Donna <bwsdonna@gmail.com> --- I apologize for my imprecise wording. I would strongly oppose making this change in which sys prefs could be configured from the user interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28990 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m --- Comment #7 from Fridolin Somers <fridolin.somers@biblibre.com> --- I like the idea. For example 'KohaAdminEmailAddress' change may change all emails to SPAM :( For 'MarcFlavour' : Is it even useful to have it in UI ? We could move it to 'local usage' like 'Version'. It will be defined only during install. To add water in the mill : I'd say if a preference is really system-related we should move it to koha-conf.xml. For example 'casServerUrl', it sounds system-related like LDAP authentication that is in koha-conf.xml. Idem for OPACBaseURL. Plus add a list that only superlibrarians can edit, sort of super-preferences. PS : There is a trick actually to define a preference ready-only : define it as overwritten in Apache config via 'OVERRIDE_SYSPREF_NAMES'. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28990 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- My above idea would actually flow into another idea I've had for "hardening" Koha instances. Many of Koha's defaults are quite open and flexible, which makes it easy for anyone to use Koha. But I suspect many vendors would like to apply certain rules that make the Koha instance more secure. Originally, I was thinking about installation "profiles", which could be invoked by koha-create, but maybe a post-installation script would be easier/more flexible. While I haven't used it myself, I've been thinking about the "jboss-cli" tool that comes with the Java server JBOSS AS/Wildfly. I encountered it most recently with Keycloak: https://www.keycloak.org/docs/latest/server_installation/#_start_cli It lets you set configuration with a script. I like the idea of a "secure_koha.cli" or "vendor_profile.cli" script that you could run. A sysadmin could lock down certain system preferences, set certain values for authentication servers, email addresses, etc. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28990 --- Comment #11 from David Cook <dcook@prosentient.com.au> --- (In reply to Fridolin Somers from comment #10)

In my opinion storing security settings inside database is not good.

I think it's arguable about whether an Identity Provider counts as a security setting per se. Or are you referring to different settings?

We often copy database from a production server to a test server, where security is on purpose lower.

That sounds like an internal problem? What's the risk that you're worried about here? Data breach?

For me the best place is koha-conf.xml, it already contains major security settings (authentication, path, ...)

As a vendor, I like storing things in configuration files (although I hate the bloated koha-conf.xml), since they're more secure and easier to deploy programmatically. But as a consumer, we'd be removing functionality from Koha. I think that's the point that Donna is making. Unless you have the wealth to pay for a vendor or internal staff, you might not be able to configure those settings anymore. (Of course, one could argue there are many settings in Koha that already work that way.) -- Ultimately, it doesn't matter to me, as I have power. I'm just thinking about removing options from people who don't have as much power. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.