Skip to content

Releases: strugee/lxdui

LXDUI 2.1.3 with @strugee's security patches applied

05 Feb 06:26
@strugee strugee
v2.1.3-strugeesecpatches
This tag was signed with the committer’s verified signature.
strugee AJ Jordan
GPG key ID: 26794034633DBBC0
Learn about vigilant mode.
056597e
This commit was signed with the committer’s verified signature.
strugee AJ Jordan
GPG key ID: 26794034633DBBC0
Learn about vigilant mode.
Compare
Choose a tag to compare
LXDUI 2.1.3 with @strugee's security patches applied Latest
Latest

Due to upstream LXDUI not addressing security issues in a timely manner (over a week with no response, even with a reminder ping), this release represents the upstream LXDUI 2.1.3 release with patches from the following security-related Pull Requests backported:

The first and last of these fix security bugs. The second one does not fix security bugs per se, but it does include a patch that applies enables many security-related protections that systemd provides. It also includes two minor bugfixes to the systemd unit. All of these patches have been shown to work correctly in at least one production environment.

IMPORTANT: this release is NOT backwards- OR forwards-compatible. This is because of three changes:

  1. A C/C++ compiler toolchain is now required for installation
  2. CLI commands like lxdui user update no longer take a -p option to set the password - if you need to set passwords programmatically, put them in the LXDUI_PASSWORD environment variable instead
  3. Your users' passwords will automatically be migrated to be stored using bcrypt when they log in

The bcrypt migration in particular means that you will not be able to easily migrate back to an upstream LXDUI release that does not also include these patches, or that includes a modified version of them, because that LXDUI release will not be able to read your users database. You have two options to address this:

  • Plan on resetting all of your users' passwords when you perform this migration
  • Make a backup copy of the conf/auth.conf file before you upgrade and keep it somewhere safe so you can restore it if/when you migrate back

If you opt to use the "make a backup method", do not not leave the backup file sitting around in production - that would defeat the point of moving to bcrypt in the first place. Also remember that any changes to your users since you made the backup will be lost when you restore.

Assets 2
Loading