new plugin: safe_autoenv #2354

oz123 · 2025-10-08T15:01:06Z

Exports variables from .env when starting a shell or cd'ing to a directory.
When leaving the directory the variables from .env will be unset.

Given:

$ mkdir -pv /tmp/foo/bar/baz
mkdir: created directory '/tmp/foo'
mkdir: created directory '/tmp/foo/bar'
mkdir: created directory '/tmp/foo/bar/baz'
$ echo CLOWN=sideshowbob > /tmp/foo/bar/baz/.env
$ echo MASTER_CLOWN="Krusty the Clown" > /tmp/foo/bar/.env

$ cd /tmp/foo/bar/baz/
Processing /tmp/foo/bar/.env
Processing /tmp/foo/bar/baz/.env
$ cd ../
Unsetting CLOWN (from /tmp/foo/bar/baz)
$ cd baz/
Processing /tmp/foo/bar/baz/.env
cd ../../
Unsetting MASTER_CLOWN (from /tmp/foo/bar)
Unsetting CLOWN (from /tmp/foo/bar/baz)

Description

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

My code follows the code style of this project.
If my change requires a change to the documentation, I have updated the documentation accordingly.
I have read the CONTRIBUTING document.
If I have added a new file, I also added it to clean_files.txt and formatted it using lint_clean_files.sh.
I have added tests to cover my changes, and all the new and existing tests pass.

Exports variables from .env when starting a shell or cd'ing to a directory. When leaving the directory the variables from .env will be unset. Given: $ mkdir -pv /tmp/foo/bar/baz mkdir: created directory '/tmp/foo' mkdir: created directory '/tmp/foo/bar' mkdir: created directory '/tmp/foo/bar/baz' $ echo CLOWN=sideshowbob > /tmp/foo/bar/baz/.env $ echo MASTER_CLOWN="Krusty the Clown" > /tmp/foo/bar/.env $ cd /tmp/foo/bar/baz/ Processing /tmp/foo/bar/.env Processing /tmp/foo/bar/baz/.env $ cd ../ Unsetting CLOWN (from /tmp/foo/bar/baz) $ cd baz/ Processing /tmp/foo/bar/baz/.env cd ../../ Unsetting MASTER_CLOWN (from /tmp/foo/bar) Unsetting CLOWN (from /tmp/foo/bar/baz) Signed-off-by: Oz Tiram <[email protected]>

plugins/available/safe_autoenv.plugin.bash

seefood · 2025-10-11T16:08:55Z

@oz123 ?

**safe_autoenv.plugin.bash:** - SC2207: Added shellcheck disable for array assignment from command substitution - SC2155: Separated declaration and assignment for env_dir variable **artisan.completion.bash:** - SC2034: Removed unused disable comment for 'commands' variable - SC2016: Changed single quotes to double quotes for proper variable expansion All shellcheck warnings resolved. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>

seefood · 2025-10-11T19:13:46Z

Fixed shellcheck warnings (SC2207, SC2155) and artisan completion issues (SC2034, SC2016). All pre-commit hooks now pass. ✅

oz123 · 2025-10-12T10:25:57Z

Hi! Thanks for fixing the stuff for me. I already did some of it but have not pushed it.
Does that mean you are going to merge it? anything else needed?

akinomyoga

I just quickly checked. I haven't checked the logics.

completion/available/artisan.completion.bash

akinomyoga · 2025-10-12T10:40:16Z

plugins/available/safe_autoenv.plugin.bash

+declare _AUTOENV_LAST_PWD=""       # Track last working directory
+
+_autoenv_init() {
+	typeset target home _file current_dir


typeset is used here, while local is used elsewhere. This should be normalized.

akinomyoga · 2025-10-12T10:43:54Z

plugins/available/safe_autoenv.plugin.bash

+	home="${HOME%/*}"
+
+	# shellcheck disable=SC2207
+	_files=($(


This doesn't work when the directory path contains spaces or glob characters. It is better to use while [[ ... ]]; do ... _files+=("${_file}") ... done than to echo the filename and split it using _files=($(...)).

akinomyoga · 2025-10-12T10:51:48Z

plugins/available/safe_autoenv.plugin.bash

+			# Validate key name (additional safety check)
+			if [[ ! "$key" =~ ^[A-Za-z_][A-Za-z0-9_]*$ ]]; then
+				echo "Warning: Invalid variable name '$key' at line $line_number in $env_file" >&2
+				continue
+			fi


In what situation does this happen? I think key is supposed to contain a valid key name in this context.

akinomyoga · 2025-10-12T10:55:35Z

plugins/available/safe_autoenv.plugin.bash

+			# Handle quoted values (remove outer quotes if present)
+			if [[ "$value" =~ ^\"(.*)\"$ ]]; then
+				value="${BASH_REMATCH[1]}"
+			elif [[ "$value" =~ ^\'(.*)\'$ ]]; then
+				value="${BASH_REMATCH[1]}"
+			fi
+
+			# Export the variable silently
+			export "$key=$value"


This fails when value contains escape sequences such as key="\"". This fails when value contains multiple '...' pairs, such as key='abc'\''def'. This can simply be

Suggested change

# Handle quoted values (remove outer quotes if present)

if [[ "$value" =~ ^\"(.*)\"$ ]]; then

value="${BASH_REMATCH[1]}"

elif [[ "$value" =~ ^\'(.*)\'$ ]]; then

value="${BASH_REMATCH[1]}"

fi

# Export the variable silently

export "$key=$value"

# Export the variable silently

eval "export $line"

I think Oz meant that it unsets vars once you CD out of a directory, however I don't see how it restores a previous value. needs a stack and all.

I now guess that the above part of the code corresponds to the safety.

A typical vulnerability of this type of configuration (such as direnv and autoenv) is that it can load a malicious environment just by cd'ing into the directory. For example, one may download a wild tarball from the internet, extract it, and cd into the directory, assuming that just cd'ing into the directory doesn't execute any code from the tarball. However, if the environment contains key=$(some malicious code), a naive implementation of eval may execute the malicious code.

However, even if the code were not directly executed when the environment is loaded, there are many variables that may be interpreted as commands and executed by applications, such as LESSOPEN, EDITOR, VISUAL, PAGER, etc. Or, LD_PRELOAD in Linux can be used to inject code on an arbitrary exec call. Just setting an environment value in the form export key="$value" isn't actually so safe.

To solve the issue, the framework should require the user to explicitly trust each directory environment (.env) by running something like autoenv trust <dir> and manage the list of sha256 codes of the trusted .env in a safe directory. Or there might be another approach, but I don't have an idea now.

akinomyoga · 2025-10-12T11:00:02Z

plugins/available/safe_autoenv.plugin.bash

+			;;
+		"status")
+			echo "Processed directories:"
+			for dir in "${!_AUTOENV_PROCESSED_DIRS[@]}"; do


dir is not localized.

akinomyoga · 2025-10-12T11:00:13Z

plugins/available/safe_autoenv.plugin.bash

+			done
+			echo
+			echo "Variable sources:"
+			for var in "${!_AUTOENV_VAR_SOURCES[@]}"; do


var is not localized.

akinomyoga · 2025-10-12T11:08:07Z

I guess @hyperupcall (who is a contributor of Bash-it and also the maintainer of autoenv) may give good suggestions.

By the way, the plugin name contains safe, but what kind of safety does it indicate?

seefood · 2025-10-12T12:36:56Z

Does that mean you are going to merge it? anything else needed?

Yes, I am just about to publish 3.2.0 and if it's fixed by Friday (see all the remarks from @akinomyoga ) it will be in there. have a go...

seefood · 2025-10-12T12:51:56Z

but what kind of safety does it indicate?

I think Oz meant that it unsets vars once you CD out of a directory, however I don't see how it restores a previous value. needs a stack and all.

akinomyoga · 2025-10-12T13:06:28Z

plugins/available/safe_autoenv.plugin.bash

+declare -A _AUTOENV_PROCESSED_DIRS # Track processed directories
+declare -A _AUTOENV_DIR_VARS       # Map directories to their variables
+declare -A _AUTOENV_VAR_SOURCES    # Map variables to their source directories


Hmm, associative arrays are used by this plugin, but README says

bash-it/docs/README.md

Line 8 in 7c1b7b3

**Bash-it** is a collection of community Bash commands and scripts for Bash 3.2+.

and CONTRIBUTING says

bash-it/docs/contributing.rst

Line 51 in 7c1b7b3

* Bash-it supports Bash 3.2 and higher. Please don't use features only available in Bash 4, such as associative arrays.

However, based on a search, pack.plugin.bash seems to already use associative arrays locally.

ouch. maybe it's time. maybe bash-it 3.2.0 will be the last version that's was limited to bash 3.2.0 capabilities :-)

Maybe the release after that will be 5.x :-)

I posted #2357

The reason that 3.2 is covered is that the Bash shipped with macOS is stuck at Bash 3.2 for licensing reasons (cf #1007). Even if we ignore macOS, Ubuntu 16.04 LTS (which is still under the extended support) uses Bash 4.3. The requirement 5.x would be too strong.

akinomyoga · 2025-10-12T13:12:50Z

plugins/available/safe_autoenv.plugin.bash

+	# Reinitialize arrays
+	declare -A _AUTOENV_PROCESSED_DIRS
+	declare -A _AUTOENV_DIR_VARS
+	declare -A _AUTOENV_VAR_SOURCES


This doesn't do what is intended. This doesn't initialize global associative arrays. This creates local associative arrays, which are never referenced later. To achieve what is expected, one needs to specify the -g flag, but it requires Bash 4.2+, which is an even stronger requirement than 3.2+.

seefood · 2025-10-13T07:35:52Z

Summary of findings:

Runtime code requiring bash 3.3+:

plugins/available/pack.plugin.bash - ✅ Now has version check added (PR Add bash 3.3+ version check to pack plugin #2358)
- Uses associative arrays (declare -A) requiring bash 4.0+
- Already had inline checks on lines 162 and 230 for bash > 3
plugins/available/history-eternal.plugin.bash:4 - ✅ Already has version check
- Requires bash 4.3+ for unlimited history
- Returns early with warning if version < 4.3
plugins/available/percol.plugin.bash:18 - ✅ Already has version check
- Requires bash 4.0+
- Returns early with warning if version < 4
vendor/github.com/gaelicWizard/bash-progcomp/defaults.completion.bash:51 - Vendor file (excluded from linting)
- Has bash 4.0 check but only for performance optimization
- Falls back to bash 3 compatible code

All runtime plugins requiring bash 3.3+ now have appropriate version checks and early returns.

akinomyoga · 2025-10-13T10:12:57Z

Thank you for your investigations!

For pack.plugin.bash: OK, I haven't noticed there is an existing check for the version check in pack.plugin.bash. It seems intentional that declare -A flaghash 2> /dev/null in pack.plugin.bash (where the error message is suppressed by the redirection to /dev/null) causes an error in Bash < 4.0. If so, it probably works without checking the Bash version at the beginning of the file.

I checked how the associative arrays flaghash and aliashash are used in pack.plugin.bash. However, flaghash is set but not referenced anywhere. Conversely, aliashash is referenced but not set anywhere. If that is true, it seems to me that we can safely remove all codes related to flaghash and aliashash. But maybe I missed something. @seefood Do you have an idea?

akinomyoga · 2025-10-13T10:15:35Z

Anyway, we need a Bash version check also for this new plugin (as long as declare -A is used).

seefood · 2025-10-13T10:44:25Z

seems to me that we can safely remove all codes related to flaghash and aliashash

I'll read it a bit later, I have a feeling shellcheck would have caught any problems like that.

However, right now I am glued to the TV, as a long war is coming to an end here and it's a happy news day I can't easily rip myself out of and do work :)

github-advanced-security bot found potential problems Oct 8, 2025

View reviewed changes

plugins/available/safe_autoenv.plugin.bash Fixed Show fixed Hide fixed

plugins/available/safe_autoenv.plugin.bash Fixed Show fixed Hide fixed

akinomyoga reviewed Oct 12, 2025

View reviewed changes

Merge branch 'master' into safe_autoenv

0a8c314

akinomyoga reviewed Oct 12, 2025

View reviewed changes

akinomyoga mentioned this pull request Oct 13, 2025

Add bash 3.3+ version check to pack plugin #2358

Open

new plugin: safe_autoenv #2354

Are you sure you want to change the base?

new plugin: safe_autoenv #2354

Uh oh!

Conversation

oz123 commented Oct 8, 2025

Description

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

Checklist:

Uh oh!

Uh oh!

Uh oh!

seefood commented Oct 11, 2025

Uh oh!

seefood commented Oct 11, 2025

Uh oh!

oz123 commented Oct 12, 2025

Uh oh!

akinomyoga left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akinomyoga commented Oct 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seefood commented Oct 12, 2025

Uh oh!

seefood commented Oct 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akinomyoga Oct 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

seefood commented Oct 13, 2025

Uh oh!

akinomyoga commented Oct 13, 2025

Uh oh!

akinomyoga commented Oct 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seefood commented Oct 13, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

akinomyoga commented Oct 12, 2025 •

edited

Loading

akinomyoga Oct 12, 2025 •

edited

Loading

akinomyoga commented Oct 13, 2025 •

edited

Loading