Developer's path and username is persisted in the error stack

I noticed in my error stack traces paths like:

[2] top-level scope at /Users/sabae/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.2/Test/src/Test.jl:1113

First, this path is not correct: it’s not a path on my system, so the information has 0 value.

Second, I’m concerned with the potential privacy implications of this. It’s easy to guess that sabae is Elliot Saba, for example.

As Julia is adopted into enterprise this can lead to possible security breaches (revealing paths and usernames on computers which can be available on the network) or privacy issues (maybe somebody can not / is not allowed / does not want to be associated with a codebase).

3 Likes

The first issue is well known, and there is at least one issue open on the issue tracker for it.

I can’t see how the second issue is a problem, unless you’re dumping error stacktraces to your users (which for a webservice, one should never do in prod). Admittedly, Mux does this, however I have a PR open to make it easy to change.

1 Like

Great to hear it!

I saw this same very strange issue today on Julia 1.7… where is the bug tracker for this? Has it not yet been fixed?

signal (11): Segmentation fault: 11
in expression starting at none:0
uv__io_start at /Users/mcranmer/venvs/main/lib/python3.8/site-packages/torch/lib/libtorch_cpu.dylib (unknown line)
uv__read_start at /Users/mcranmer/venvs/main/lib/python3.8/site-packages/torch/lib/libtorch_cpu.dylib (unknown line)
start_reading at ./stream.jl:793
wait_readnb at ./stream.jl:411
eof at ./stream.jl:106
jfptr_eof_42389 at /Applications/Julia-1.7.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
jl_apply_generic at /Applications/Julia-1.7.app/Contents/Resources/julia/lib/julia/libjulia-internal.1.7.dylib (unknown line)
eof at ./io.jl:416
#read_tarball#47 at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Tar/src/extract.jl:344
read_tarball##kw at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Tar/src/extract.jl:340 [inlined]
#11 at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Pkg/src/Registry/registry_instance.jl:199 [inlined]
#open#700 at ./process.jl:395
open at ./process.jl:393 [inlined]
uncompress_registry at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Pkg/src/Registry/registry_instance.jl:198
RegistryInstance at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Pkg/src/Registry/registry_instance.jl:266
#reachable_registries#17 at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Pkg/src/Registry/registry_instance.jl:373
reachable_registries at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Pkg/src/Registry/registry_instance.jl:345 [inlined]
#download_default_registries#28 at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Pkg/src/Registry/Registry.jl:101

signal (11): Segmentation fault: 11
in expression starting at none:0

(The segfault is a different bug. The weird thing is the occurrence of /Users/sabae/…)