<pie_>
presumably its not really an issue because its run at nix time so whoever does anything with this has to have the ability to reconfigure the system anyway but...
<pie_>
i at least think security relevant code should be held to higher standards? am i making a big deal out of nothing?
<infinisil>
(someone = me)
<gchristensen>
couldn't hurt to make it better
<pie_>
i dont have a good way to make ti work but i feel like we should be shellchecking everything :( , cant really directly shellcheck nix code though
<pie_>
^not meant as a complaint
<gchristensen>
yeah it is hard, since it causes mass rebuilds
<pie_>
i dont follow
<pie_>
shellchecking causes mass rebuilds?
<gchristensen>
ah sure
<gchristensen>
so we can't just use shellcheck everywhere, because it depends on GHC
<gchristensen>
so we can't bootstrap with it
<pie_>
oh hm i guess we theoretically could shellcheck at runtime, didnt think of that
<gchristensen>
another idea would be to be able to inject it at dynamically and then build everything to see how it goes
<pie_>
the farthest i got was thinking we could try like...one time shellcheck on merges or something to see if the baseline is okayish :/
<gchristensen>
sort of like how checkMeta works, onl y if you turn it on
<andi->
still every system would depend on ghc.. Shouldn't do that... There mgith be some people that wouldn't mind or even like ghc being in the small set..
<gchristensen>
yeah that is out of the question
<pie_>
i think this is what i meant with the first "oh hm" <gchristensen> another idea would be to be able to inject it at dynamically and then build everything to see how it goes
<andi->
ahh on merges
<gchristensen>
but maybe there could be a shellcheck-a-drv tool
<pie_>
could be an optional system thing to enable for nixpkgs hackers
<gchristensen>
isnixpkgsshellchecked.com
<pie_>
not _YET_
<pie_>
:D
<gchristensen>
i19d.com
<gchristensen>
(lmao)
<andi->
pie_: go ahead, would like to see that :D
<pie_>
whats the number btw
<pie_>
the other thing has 18
<andi->
number of characters
<pie_>
andi-, definitely ENOTIME :(
<pie_>
oh
<gchristensen>
I was being dumb
<pie_>
though this would be more important than the WINE stuff im screwing with
<pie_>
i mean, nixos is the advanced-ass tooling-ass people right? ;)
<gchristensen>
I'd love to see a route where drv's can be shell-checke'd
<pie_>
who needs 20000 maintainers under the sea when you have automation
<pie_>
(you just need 20000 people to have enough to sample ones that can actually understand the tooling :P)
<andi->
and if that depends on a config option it might not even (always) cause rebuilds
<pie_>
something something solve bug classes not bugs, but ill stop spamming memes now
<gchristensen>
fewer memes more cool tools
<pie_>
i dont know enough about nix semantics to have a clue how strings actually end up as shell code (or shellcode? :P)
<gchristensen>
ever examined a drv?
<pie_>
ive looked at show-derivation
<infinisil>
How about compiling shellcheck statically with https://github.com/nh2/static-haskell-nix, then making a zero-deps shellcheck that could be hosted somewhere and updated separately every so often
<gchristensen>
nix show-derivation $(which bash)
<pie_>
but isnt a lot of it just magic variables passed to setup.sh
<infinisil>
(well it is zero-dep with static compiling)
<pie_>
or whichever builder=
<gchristensen>
look at `builder`
<pie_>
infinisil, hmm intriguing idea
<gchristensen>
and `args`
<pie_>
gchristensen, what i really mean to say is can we actually theoretically reasonably expect to catch everything?
<gchristensen>
everything? no
<pie_>
can we reasonably enumerate cases we cant catch?
<pie_>
i.e. are we going to be surprised
<andi->
build-time generate shell scripts
<gchristensen>
if it were me
<pie_>
known unknowns etc
<gchristensen>
I'd stop worrying about catching everything and just see what kind of tool I can make as quickly as I can
<pie_>
im bad at that
<andi->
maybe start with the generate activation script and (transparently) apply shellcheck on it
<andi->
*generated
<pie_>
but yeah i guess if configurations have a lot of common mechanisms per andi- 's above suggestion i guess a lot would be covered by just that + standard setup.sh stuff
<LnL>
the way stdenv phases currently work makes this kind of difficult, setup.sh runs eval on some random variables
<pie_>
its not important if it doesnt hit the important code though (has positive secondary effects however)
<gchristensen>
LnL: nothing a little eval() { cat "$@" > lol.sh; shellcheck lol.sh } can't solve
<andi->
I would focus (at first) on stuff that is executed outside of the sandbox.
<pie_>
where by its i mean doing this at all ^
<gchristensen>
(:|)
<pie_>
gchristensen, christ lol :D
<LnL>
hmm, yeah maybe
<pie_>
gchristensen, thanks i hate (love) it
<gchristensen>
delighted to help
<pie_>
does bash actually let you do that
<gchristensen>
oh sure
<pie_>
sweet
<MichaelRaskin>
gchristensen: it should be "echo"
<MichaelRaskin>
Or maybe something about «type» to find sources?
<pie_>
infinisil, i guess id have an excuse to figure out static builds but ughhhhhh seems like a horrible rabbithole
<pie_>
i did see theres unfinished github issues about a static nixpkgs layer or somesuch
<LnL>
that would only catch basic stuff tho, ideally shellcheck would have enough context to know what variables are available, etc.
<pie_>
tv, last person i talked to about this stuff was you (shellcheck over nixpkgs) ^