Synchronized FFI access to POSIX environment variable functions
I really don't think we should offer a "shadow environment"; that seems both like a trap for users (often not what they're actually looking for) and a suboptimal interface for things that are...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
RalfJung: I feel like we probably need an RFC to hash out and decide about the plan here. Just local discussions in a PR won't do, precisely because there are multiple alternatives. For clarity, if...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
josh: (often not what they're actually looking for) It is what I needed 100% of the cases where I so far used set_var/remove_var (which is mostly inside cargo-miri). Refactoring that code to remain...
View ArticleSynchronized FFI access to POSIX environment variable functions
How about: /// Sets the **shadow** environment variable `key` to the value `value` for the currently running process. /// /// ... rest of the docs #[deprecated = "Confusing, use set_shadow_var or...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
Kixunil: Or maybe even, in case of set_var write from shadow to system if we can undeniably prove that there's only one thread. That way most of the existing sound code intending to use system will...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
Kixunil: How about: I don't think we want set_var to be the one that affects the shadow environment. That is not what it currently does. A shadow environment is sufficiently surprising that it needs...
View ArticleSynchronized FFI access to POSIX environment variable functions
If there is a single thread then it did happen. If there isn't you actually don't know if "it happened" - it may have been overwritten in the other thread right after you wrote (even with "safe"...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
Kixunil: If there isn't you actually don't know if "it happened" - it may have been overwritten in the other thread right after you wrote (even with "safe" locking), so the behavior already is...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
Kixunil: I reminds me of situation with mem::uninit which some crates used as a (subjectively horrible) hack to implement unreachable_unchecked. Turning it to panic was technically breaking change...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
Indeed, that's why I suggested making it thread-local. However as @RalfJung said: its one and only purpose -- to port existing code. I didn't think of it in this way before but now realized that...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
Kixunil: The reason I suggested thread local is I came across a PR that wanted to use external command-calling library together with set_var. Ofc I immediately pointed out that this was bad in...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
RalfJung: Also even if this is a Rust command-calling library It is. RalfJung: hat's really a bug in that command-calling library and needs to be fixed there. Yeah, seems like if we want to help...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
RalfJung: In an ideal world we wouldn't have such a shadow environment. If I we could un-do having these safe methods in Rust 1.0 we should do it. I'll +1 @josh re: somewhat strong opposition to a...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
bascule: from a security perspective might give the impression that secrets (which really shouldn't be kept in environment variables , but that ship has sailed and I digress) have been removed from...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
RalfJung: I wasn't aware of this being a problem in practice, do you have a reference for that? Here's an example of the hoops people have jumped through to unset system environment variables in Java:...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
bascule: and from a security perspective might give the impression that secrets (which really shouldn't be kept in environment variables , but that ship has sailed and I digress) have been removed...
View ArticleSynchronized FFI access to POSIX environment variable functions
Could cargo-miri's use case be covered by a crate? If so a shadow-env crate could be published and the migration guide could point people at the new APIs for the common cases and to the crate for...
View ArticleSynchronized FFI access to POSIX environment variable functions
I think the important part is that they're removed before forking so the forked process can't read them after execing. Read full topic
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
bascule: Here's an example of the hoops people have jumped through to unset system environment variables in Java: Note that env::remove_var will still be available, you'll just need to make sure it is...
View ArticleClik here to view.
Synchronized FFI access to POSIX environment variable functions
mjbshaw: I think the important part is that they're removed before forking so the forked process can't read them after execing. It doesn't matter if env vars are removed before or after forking as...
View Article