Newest at the top
2025-02-12 21:56:53 +0100 | <tomsmeding> | the first call containing "notify-send" is a call to ghc that gets passed "$(notify-send" and "kaas)" as two separate arguments |
2025-02-12 21:56:53 +0100 | <merijn> | tomsmeding: Might be just getting reparsed at the Setup step and using execve then |
2025-02-12 21:56:30 +0100 | <merijn> | (similar to the two line one cabal init generates) |
2025-02-12 21:56:27 +0100 | <tomsmeding> | I just ran `cabal build --ghc-options='$(notify-send kaas)'` in a simple cabal project under a tracer that shows all execve calls |
2025-02-12 21:56:15 +0100 | <merijn> | They (implicitly) usethe default Setup.hs |
2025-02-12 21:55:57 +0100 | <tomsmeding> | s/projects/packages/ |
2025-02-12 21:55:56 +0100 | <merijn> | yes |
2025-02-12 21:55:52 +0100 | <tomsmeding> | is this also true in build-type: Simple projects? |
2025-02-12 21:54:57 +0100 | <merijn> | in that Setup step |
2025-02-12 21:54:49 +0100 | <merijn> | all arguments definitely get turned into one string and then reparsed, though |
2025-02-12 21:54:00 +0100 | <euouae> | I'm not trying to criticize eitehr |
2025-02-12 21:53:57 +0100 | <merijn> | the problem is that cabal-install just calls Cabal's Setup.hs |
2025-02-12 21:53:22 +0100 | <tomsmeding> | but as I said, at least there appears to be some escaping going on if so |
2025-02-12 21:53:20 +0100 | <merijn> | oh, no that's not new |
2025-02-12 21:53:09 +0100 | <tomsmeding> | if cabal does indeed pass these things to the shell, I blame the reviewers who accepted that PR |
2025-02-12 21:52:53 +0100 | <merijn> | And I'm half guessing |
2025-02-12 21:52:53 +0100 | <tomsmeding> | I'm not blaming you for not remembering :p |
2025-02-12 21:52:46 +0100 | <merijn> | tomsmeding: In my defense, it's been 7 years :p |
2025-02-12 21:52:35 +0100 | <tomsmeding> | (and it's System.Process.shell, I think) |
2025-02-12 21:52:20 +0100 | <tomsmeding> | merijn: but you said "proc" |
2025-02-12 21:52:11 +0100 | <merijn> | tomsmeding: I was thinking System.Process.sh style |
2025-02-12 21:52:11 +0100 | <tomsmeding> | euouae: you could also -i an unexpected file then |
2025-02-12 21:51:53 +0100 | <merijn> | honestly, just don't look at the cabal inversion of control |
2025-02-12 21:51:35 +0100 | <euouae> | merijn: you could just be in control of that --ghc-options thing somehow -- think of someone contributing a patch to CI where they set the options sneakily |
2025-02-12 21:51:10 +0100 | <tomsmeding> | if you're thinking of System.Process.proc |
2025-02-12 21:51:05 +0100 | <merijn> | euouae: You already have a shell if you can call cabal with --ghc-options |
2025-02-12 21:51:04 +0100 | <tomsmeding> | that's not the shell |
2025-02-12 21:50:48 +0100 | <merijn> | tomsmeding: I'm not 100% it goes via the shell, I was thinking it goes via proc |
2025-02-12 21:50:43 +0100 | <tomsmeding> | okay --ghc-options seems to escape $ and ` in any case |
2025-02-12 21:50:27 +0100 | <euouae> | merijn: it doesn't super-matter, but I'm just telling you that it's definitely an error from a security perspective |
2025-02-12 21:50:20 +0100 | sprotte24 | (~sprotte24@p200300d16f0a8e003d8337fe7ef7e64f.dip0.t-ipconnect.de) |
2025-02-12 21:50:10 +0100 | <tomsmeding> | why is there a shell in the first place? |
2025-02-12 21:49:51 +0100 | <euouae> | the expected behavior of --ghc-options= should not be "you get a shell and do w/e you want" |
2025-02-12 21:49:49 +0100 | <tomsmeding> | well it's clearly a violation of expectations if something passed to --ghc-options, or god forbid --ghc-option, gets interpreted by a shell |
2025-02-12 21:49:49 +0100 | <merijn> | euouae: Why does it matter? |
2025-02-12 21:49:40 +0100 | yegorc | (~yegorc@user/yegorc) yegorc |
2025-02-12 21:49:27 +0100 | <euouae> | it's definitely an issue, it shouldn't happen like that |
2025-02-12 21:49:01 +0100 | <merijn> | tomsmeding: I don't see how that's an issue, tbh |
2025-02-12 21:48:28 +0100 | <euouae> | tomsmeding: or just ; rm -rf |
2025-02-12 21:48:27 +0100 | <merijn> | tomsmeding: who knows |
2025-02-12 21:48:12 +0100 | <tomsmeding> | what if I put $() in --ghc-options |
2025-02-12 21:48:07 +0100 | <merijn> | tomsmeding: I'm 80% sure of that |
2025-02-12 21:48:04 +0100 | <tomsmeding> | does it do proper quoting when I pass --ghc-option with an OPT containing weird stuff |
2025-02-12 21:47:50 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
2025-02-12 21:47:49 +0100 | <euouae> | merijn: okay, then it should say OPTS passed as-is |
2025-02-12 21:47:47 +0100 | <tomsmeding> | merijn: O.o |
2025-02-12 21:47:42 +0100 | <merijn> | euouae: it's a shell process call |
2025-02-12 21:47:32 +0100 | <tomsmeding> | euouae: break them |
2025-02-12 21:47:30 +0100 | <merijn> | euouae: There is not space splitting |
2025-02-12 21:47:25 +0100 | <merijn> | euouae: I meant that if you write --ghc-options="foo bar baz" it literally just appends foo bar baz to the ghc call |