We still have modules that ship with default system users with hardcoded username and a hardcoded password. In all modules the sysop can configure a different username and a different password, however, it's possible that it's forgotten or that the config has a typo. GDPR requires security by default. A module should fail at startup when username or password configuration is missing. Then the user interface is forgiving and doesn't create an unintended security hole.
Notes:
Do JIRAs exist for the modules which still have default username/passwords?
Not yet.
How many are we talking about here? is it 1? 2? 8+?
Suggestion from Jakub Skoczen last week was to drop mod-reservoir from the security board (possibly snyk too) since it isn't part of the Folio flower releases. Are there any others we should consider as well? Do we have a policy (or even an opinion) on this?
Upon additional thinking, we feel that doing this would significantly reduce our visibility into security vulnerabilities in these modules. Let's leave it as is for now, and if it becomes a problem we can revisit.
Julian Ladisch pointed out that if the project does adopt the application formalization approach currently being discussed, there's a chance that modules like this may be used as "extended" applications even if not formally part of a flower release. Therefore we need to stay on top of vulnerably, etc.
1 min
Refresh token rotation
Team
Regarding the environment variable which allows the legacy endpoints to be disabled, what is the default behavior?
The Security Team's recommendation is that the endpoints are disabled by default, but hosting providers/system-operators can enabled them if needed.
Craig McNally will raise this at the TC meeting next Monday.
The TC has agreed on a transition period where both legacy and new endpoints will co-exist. There will be more conversation about which release removes the legacy endpoints altogether at the TC meeting on .
The TC has agreed to remove the legacy endpoints in Ramsons
There's some discussion on how this will be supported in the SAML flow. See MODLOGSAML-172 and weigh in if desired.
We probably want to create JIRAs for these. The MODSER JIRA project is applicable here, and they should be assigned to the K-Int team.
NOTE: I don't think this is part of a flower release yet, and will not be part of Poppy, so not stop the world critical at this point, but will ne nice to have these filed.