Skip to content

Conversation

wltechblog
Copy link

Having ./bin in your PATH is extremely dangerous, and even moreso when it's the first entry and will override base system tools like ls . A different mechanism should be used for in-project executables.

This PR removes the security hole without addressing ways to handle in-project executables.

Having ./bin in your PATH is extremely dangerous, and even moreso when it's the first entry and will override base system tools like `ls` . A different mechanism should be used for in-project executables.

This PR removes the security hole without addressing ways to handle in-project executables.
@DavidHoenisch
Copy link
Contributor

my hunch is this is relative path that is assumed to be pointing to ~/.local/share/omarchy/bin

@wltechblog
Copy link
Author

wltechblog commented Sep 10, 2025

my hunch is this is relative path that is assumed to be pointing to ~/.local/share/omarchy/bin

Per a previous thread, the intended goal was to make it easy to run in-project executables.... I hope I don't actually have to lay out the trivial exploit to get attention on this.

@gerardroche
Copy link

It's a duplicate of #481

@wltechblog
Copy link
Author

It's a duplicate of #481

Partially. #481 is trying to address providing the in-project bin and has completely stalled. The last comment from a developer is over a month ago.

This much simpler PR is only addressing the security issue, which is trivial and obvious and if I'm being honest it's frustrating that it isn't being taken seriously.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants