Index out of range while trying to run with envvar

[JaikrishnaTS]

When I tried to set the environment variable NAME to foo and ran httpu, I noticed a index out of range panic.

It seems to me that whenever the length of NAME is lesser than the length of $env{[NAME]}, this issue happens.

Here's the stack trace

$ NAME=foo ./main new httpbin
panic: runtime error: index out of range

goroutine 1 [running]:
panic
        ../../../libgo/go/runtime/panic.go:557
runtime_panicstring
        ../../../libgo/runtime/panic.c:38
github_com_hazbo_httpu_vendor_github_com_hazbo_httpu_utils_varparser.VarParser.Parse
        go/src/github.com/hazbo/httpu/vendor/github.com/hazbo/httpu/utils/varparser/varparser.go:43
github_com_hazbo_httpu_vendor_github_com_hazbo_httpu_env.Parse
        go/src/github.com/hazbo/httpu/vendor/github.com/hazbo/httpu/env/env.go:24
github_com_hazbo_httpu_vendor_github_com_hazbo_httpu_resource_request.RequestSpec.parseEnvVars
        go/src/github.com/hazbo/httpu/vendor/github.com/hazbo/httpu/resource/request/modifier.go:40
github_com_hazbo_httpu_vendor_github_com_hazbo_httpu_resource_request.RequestSpec.Update
        go/src/github.com/hazbo/httpu/vendor/github.com/hazbo/httpu/resource/request/modifier.go:15
github_com_hazbo_httpu_vendor_github_com_hazbo_httpu_resource.FilePath.Load
        go/src/github.com/hazbo/httpu/vendor/github.com/hazbo/httpu/resource/resource.go:122
github_com_hazbo_httpu_vendor_github_com_hazbo_httpu.ConfigureFromFile
        go/src/github.com/hazbo/httpu/vendor/github.com/hazbo/httpu/configure.go:76
commands.newValue
        go/src/github.com/hazbo/httpu/vendor/github.com/hazbo/httpu/cmd/httpu/commands/new.go:41
commands.func2
        go/src/github.com/hazbo/httpu/vendor/github.com/hazbo/httpu/cmd/httpu/commands/new.go:58
github_com_hazbo_httpu_vendor_github_com_hazbo_httpu_cmd_httpu_commands.Command.Run
        go/src/github.com/hazbo/httpu/vendor/github.com/hazbo/httpu/cmd/httpu/commands/commands.go:12
main.main
        go/src/github.com/hazbo/httpu/cmd/httpu/main.go:60

[hazbo]

Thanks for reporting, will look into this today. Looks like it may be an issue with my variable parser.

[hazbo]

@JaikrishnaTS So far I have been unable to reproduce. Did you first run httpu pull? And is there any chance you could send me some specific build / running steps as to how you produce this?
Thanks again!

[JaikrishnaTS]

Hello @hazbo I wanted to make sure I followed the installation instructions exactly from the repo and so I deleted my sources, builds, ~.httpu and rebuilt on commit f063213

I ran make, then httpu pull, can confirm that the same issue is present.
My go version go version go1.10 gccgo (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1) linux/amd64

[hazbo]

@JaikrishnaTS thank you for providing me with these details! Will look into this and get back to you.

[AdvancedHacker101]

Hey, @JaikrishnaTS
You could try the latest version where the vendor/ folder is removed, because the stack trace says that the error comes from there.
Also could you post your code at line 43 from the utils/varparser/varparser.go file?
The error is wierd because at line 43, there's a for loop, and the error would normally raise at the nearest line which tries to access s[k] which is the switch statement.

[JaikrishnaTS]

@AdvancedHacker101 I checked and it looks like the issue is still present.
I poked around a bit more and I believe this is the simple case
https://play.golang.org/p/_3PDTmHwuYX

While this program doesn't produce error on the online interpreter nor on yours, the go compiler on my machine is probably causing it. (same result on the s = s[:k] + s[k+1:] variant)
I believe there's some some sort of optimization that happened in the compiler causing the len(s) check to be cached/ignored

[AdvancedHacker101]

But then it would still panic at the switch statement, but it panics at the for loop.
This could be related to optimisation, because your for loop may try to load the value of s[k] even, if it's discarded after by the _.
Anyways I think the simplest solution here is to write a normal for loop, and then we don't have to deal with this, because there's no uncontrolled access to s[k] then.