Security: Disable automatic updates of devbox for security reasons

[alehuo]

In my opinion, updating devbox automatically adds an additional attack surface. In theory, this could allow arbitrary code execution, if the repository or its author accounts are compromised. I am not sure if devbox currently allows disabling automatic updates.

Instead of automatically updating devbox, the user would be notified of a new devbox update along with an --update flag or a devbox update -command which would update devbox to the latest version.

[loreto]

@alehuo Thanks for the feedback.

I hear your concerns – at the same time some people do find the automatic updating valuable – so I'm thinking we should give users the option.

Imagine:

• We implement devbox update as you suggest, that lets you do an update manually.
• We add support for an environment variable, that when set to false, lets you disable automatic updating (something like DEVBOX_AUTOUPDATE=false.

What do you think about a solution like that?

BTW, just in case it makes you feel a bit better:

• Our company takes security seriously and we are SOC 2 certified. External auditors audit our security every year.
• Everyone that can trigger a release on github must have 2-factor authentication enabled in order to interact with Github. Releases can only be triggered base on the main branch.
• We use checksums to verify that the downloaded binary matches what we expect. If the checksum doesn't match, we won't move forward with the update.

[loreto]

BTW, I'll add that we already support an environment variable that let's you "pin" the version of devbox you want to use. For example, if you set DEVBOX_USE_VERSION=0.0.5, that will pin your binary to 0.0.5 and you won't receive any updated until you change that variable.

[alehuo]

@alehuo Thanks for the feedback.

I hear your concerns – at the same time some people do find the automatic updating valuable – so I'm thinking we should give users the option.

Imagine:

• We implement devbox update as you suggest, that lets you do an update manually.
• We add support for an environment variable, that when set to false, lets you disable automatic updating (something like DEVBOX_AUTOUPDATE=false.

What do you think about a solution like that?

BTW, just in case it makes you feel a bit better:

• Our company takes security seriously and we are SOC 2 certified. External auditors audit our security every year.
• Everyone that can trigger a release on github must have 2-factor authentication enabled in order to interact with Github. Releases can only be triggered base on the main branch.
• We use checksums to verify that the downloaded binary matches what we expect. If the checksum doesn't match, we won't move forward with the update.

Thank you for your response @loreto,

I understand the value of automatic tooling updates, and the scenario you suggested would work. It allows updating manually, and disabling automatic updates. I still personally prefer opt-in automatic updates, and I would definitely update Devbox, if it asked my consent to update (technically working as a half-automated update process).

The environment variable DEVBOX_USE_VERSION seems to be undocumented, but I believe the documentation will get better in the future as Devbox matures.

Thank you again for you response. You gave good insight on how your company develops Devbox in a secure and audited manner.

[jason-riddle]

Some points to add in favor of disabling automatic updates.

1. There is a regression in 0.0.6 (https://github.com/jetpack-io/devbox/issues/196) that had not affected me until I was automatically upgraded from 0.0.5. I would have been okay (albeit a bit behind in versioning) if this had not occurred.

2. Also, from a compliance perspective, just automatically updating to the latest version is not ideal. Certain companies and organizations require security reviews and/or license reviews regardless of how trustworthy a company or release process seems.

[jason-riddle]

Another idea is to add a version key in devbox.json. So maybe something like this

{
  "version": "latest",
  ...
}

where version can be "latest" or "0.X.Y".

If the version key is not defined, then just assume "latest". Otherwise, use the specified version.

This would unlock 2 things:

1. You now have strict reproducibility. Running devbox shell today or from a year from now will use the exact same version of devbox.

2. This would allow CI tools to scan to check the versioning. Then additional workflows are possible such as creating a ticket in the team's backlog to bump the version or automatically bumping up the version, via something like dependabot.

[loreto]

@jason-riddle I like the idea of having a version field inside the devbox.json, let me look into that approach!

[Lagoja]

Updates are no longer automatic, and require the user to manually run devbox version update.