You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The general thinking is that we could have versions of the compat layer and use a variable symlink to define the default version. This give sites the ability to use, or potentially ignore, the security updates.
The text was updated successfully, but these errors were encountered:
One concern was that putting things behind a symlink may cause issues on its own, since software may resolve that link and go around the security update.
To avoid that I have a proposal:
The install location of the compat layer does not change
For user consumption, we move the compat layer and add a variable symlink (thereby keeping all paths valid)
For building, we put the original compat layer back in place, and when the build completes we restore the symlink (this means all software we ship is built on the same compat layer regardless of security updates)
We provide security fixes for the compat layer (again built in the original location but moved to a new path)
The variable symlink allows people to select/ignore a security-updated compat layer with EESSI controlling the default value
There is good chance that it may not be easy for us to implement security patches in our compat layer since it may break things in the associated stack. There was a discussion on this in https://github.com/EESSI/meetings/wiki/meeting-2023-02-02#compatibility-layer
The general thinking is that we could have versions of the compat layer and use a variable symlink to define the default version. This give sites the ability to use, or potentially ignore, the security updates.
The text was updated successfully, but these errors were encountered: