After digging in the commit logs I presume those are 554e56687c and 6c96361402, but I'm not sure if there are more.
Knowing the kind of vulnerability and how it is exploitable is extremely important for evaluating the risk and therefore whether to upgrade or not.
I suggest being a bit more rigorous with documenting the code changes related to security vulnerabilities, e.g. add description to commit message body, atomic PRs that only fix a single thing, track PR number in the changelog.
Let me know if I can be of any help.
Originally created by @acidghost on GitHub (Apr 9, 2024).
The latest update mentions "Security Patches" but these are not detailed in any way.
https://github.com/open-webui/open-webui/blob/331fe04df7dcfb2d22e2ecc39525b6cf74fae575/CHANGELOG.md?plain=1#L23
After digging in the commit logs I presume those are 554e56687ccbc6903210c0f8e1cd9a8281b61776 and 6c963614026137df92b666997d94267c98c32e24, but I'm not sure if there are more.
Knowing the kind of vulnerability and how it is exploitable is extremely important for evaluating the risk and therefore whether to upgrade or not.
I suggest being a bit more rigorous with documenting the code changes related to security vulnerabilities, e.g. add description to commit message body, atomic PRs that only fix a single thing, track PR number in the changelog.
Let me know if I can be of any help.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @acidghost on GitHub (Apr 9, 2024).
The latest update mentions "Security Patches" but these are not detailed in any way.
https://github.com/open-webui/open-webui/blob/331fe04df7dcfb2d22e2ecc39525b6cf74fae575/CHANGELOG.md?plain=1#L23
After digging in the commit logs I presume those are
554e56687cand6c96361402, but I'm not sure if there are more.Knowing the kind of vulnerability and how it is exploitable is extremely important for evaluating the risk and therefore whether to upgrade or not.
I suggest being a bit more rigorous with documenting the code changes related to security vulnerabilities, e.g. add description to commit message body, atomic PRs that only fix a single thing, track PR number in the changelog.
Let me know if I can be of any help.