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
Craft tools should adopt the default profile created by users when initializing LXD and then seed that profile with good defaults for the build environment to use.
Why it needs to get done
Currently, craft tools like snapcraft use LXD to create and manage a build environment. LXD creates a default profile which users can freely modify (lxc profile edit default). Whenever a craft tool creates a managed container to perform builds in, that container is created using the default profile. This means that any user-specific additions beyond what a managed container requires (root disk, networking) can infect the build environment, potentially impacting build reproducibility or even ability.
Doing this will protect managed containers from adverse (and potentially unintended) interactions, while still preserving the ability of users to impact the environment tools like snapcraft do their work in.
This could also potentially simplify the config invocations tools like snapcraft use to create the container or the behavior of certain flags (such as --bind-ssh), as that information could be kept within the profile.
The text was updated successfully, but these errors were encountered:
What needs to get done
Craft tools should adopt the default profile created by users when initializing LXD and then seed that profile with good defaults for the build environment to use.
Why it needs to get done
Currently, craft tools like snapcraft use LXD to create and manage a build environment. LXD creates a default profile which users can freely modify (
lxc profile edit default
). Whenever a craft tool creates a managed container to perform builds in, that container is created using the default profile. This means that any user-specific additions beyond what a managed container requires (root disk, networking) can infect the build environment, potentially impacting build reproducibility or even ability.Doing this will protect managed containers from adverse (and potentially unintended) interactions, while still preserving the ability of users to impact the environment tools like snapcraft do their work in.
This could also potentially simplify the config invocations tools like snapcraft use to create the container or the behavior of certain flags (such as
--bind-ssh
), as that information could be kept within the profile.The text was updated successfully, but these errors were encountered: