# Nushell core team meeting 2024-04-10
## Attendees
- Jack (the polars hero)
- Darren
- Devyn
- Filip
- Michael
- Ed
- Ian
- Andy
- Antoine
- Stefan
- Jakub

## Agenda
- [x] [Rust CVE allowing remote code execution on Windows](https://nvd.nist.gov/vuln/detail/CVE-2024-24576): 0.92.2 point release?
- [ ] procedure for future security issues
- [x] 30k stars on the nushell repo will happen soon. Apr 10th we had 29,739. What should we do? (We created the 20k club on 7/30/2022)
- [x] Sophia - Maybe create a thank you blog post together
- [x] `do -i` functionality recently changed due to [#11934](https://github.com/nushell/nushell/pull/11934). Disucssion of changes [#12451](https://github.com/nushell/nushell/issues/12451). Should we stick with these changes or revert `do -i` to eat all errors like it used to.
---
*Option 1* - Change to the way it was
`do -i { blah }` This eats all errors including stderr output.

*Option 2* - Adopt this new way of eating errors
ignore all stderr
`do -i { diff nonexistentfile1 nonexistentfile2 } e> (null-device)`
or just for one command
`do -i { diff nonexistentfile1 nonexistentfile2 e> (null-device) }`

With option 2, we'd want to make `null-device` a prelude command so it's automatically available.

---
- [ ] `nu` supporting `--` as indicator for arbitrary argments [#12344](https://github.com/nushell/nushell/pull/12344). Below is taken from the issue.
- We already have a proposal for `--` in custom commands
---
in the following example, it is hard to tell who the `foo` and `bar` are meant for, the `commands` or the `nu` binary?
`nu -c 'echo $args' foo bar`

many shells would use `--` as an indicator to distinguish who is the rest of the args meant for.

`nu -c 'echo $args' foo bar` => `foo` and `bar` are meant for the `nu`
`nu -c 'echo $args' -- foo bar` => `foo` and `bar` are meant for the `commands` script
`nu -c 'echo $args' foo -- bar` => `foo` is meant for the `nu` while `bar` is meant for the `commands` script

---
- [ ] Benchmarking

## Discussed Topics

## Windows cmd process CVE
- https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html
- https://flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/
- Only affected windows
- invoking command can misbehave with string input that gets quoted incorrectly
- Patched: only in Rust 1.77.2 (as far as we know for now)
- For us we would update rust version (`rust-toolchain.toml`, MSRV)
- may break distro build as they lag rust in some cases
- should patch all potentially vulnerable command invokations
- rebuilds with stable should also fix (so trigger with new tag)
- Devyn and Stefan will take care of the patch after the meeting, Sophia is verifying clippy

## heading for the 30k stars
- Brainstorming for the celebratory post
- "Thank you" post
- Historical retrospective
- HackMD collaborative work for

## redirection discussion
- We'd like `do -i` to really just be `do` only allowing closures and perhaps removing the flags.
- How can we unite all redirection?
- We need a `help redirection` to list all ways we allow to redirect.
- Can we have something like `cat foo.txt | out+err | print $in.err` and also include exit code? (sophia)
- `cat foo.txt | capture --out --err | print $in.err` (kubouch)
- o+e, ignore, complete, do - let's just have one way that does this and handle it all the same way globally
- maybe go back to `do -i` behavior

## -- double dash

- not sure we like the pr as it sits.
- pr for other double dash pr 11435