MathiasVDA commented on issue #3736: URL: https://github.com/apache/jena/issues/3736#issuecomment-3849903385
> This was removed - it's a security issue [CVE-2025-50151](https://www.cve.org/CVERecord?id=CVE-2025-50151) that the project discovered while working on the related CVE. https://jena.apache.org/security/advisories.html allowConfigFileProperty is a user-beware facility. Yes I understand, that's indeed a risk. Thanks for the reference. > There has been a prototype of reloading the configuration area and, without server restart, moving over to the new configuration while not aborting any existing user requests. That's "vision" not planned work 🏗️ . That sound like a good approach! One that could also work is if we could "disable" a dataset, change the assembler configuration on the disk of the dataset and "enable" the dataset again. Enable/disable would go over http and would introduce a small downtime. In our kubernetes we can share volumes. This is of course a less good approach as the one you suggest. > Do you use the admin/configuration area ('run/') or do you run the server with "--conf" and provide the whole configuration yourself? We mount FUSEKI_BASE from disk (including dataset configuration and data files) and point to the --conf file that lives there but that is just for general fuseki parameters such as `fuseki:contextPath "/jena-fuseki" ;`. Datasets are created and deleted from the HTTP admin. The need of us to commit a config file for the dataset is only to point to the new data files. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
