Unsecure RUNPATHS in parrot 0.90

[lu_zero]

Gentoo Portage Q/A checks found this issue:

• QA Notice: The following files contain insecure RUNPATH's
• /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/bin/perl6
• /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/bin/parrot_config
• /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/bin/pbc_disassemble
• /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/bin/pbc_to_exe
• /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/lib64/parrot/dynext/gdbmhash.so
• /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/lib64/parrot/dynext/digest_group.so
• /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/lib64/parrot/dynext/perl6_group.so
• /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/lib64/parrot/dynext/subproxy.so
• /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/lib64/parrot/dynext/dynlexpad.so
• /var/tmp/portage/dev-lang/parrot-0.9.0/work/parrot-0.9.0/blib/lib usr/lib64/parrot/dynext/rational.so

Maybe the could be addressed sooner or later

[doughera]

For the paths in parrot_config and pbc_to_exe, see ticket TT #208. For a patch to fix the path in pbc_disassemble, see TT #209.

[wayland]

For the dynext ones, see TT #540

[jkeenan]

Is there any way someone other than a Gentoo user would be able to either (a) evaluate the items listed in the OP; or (b) identify which items have been resolved?

Thank you very much.

kid51

[doughera]

Replying to jkeenan:

Is there any way someone other than a Gentoo user would be able to either (a) evaluate the items listed in the OP; or (b) identify which items have been resolved?

On Linux, you can use chrpath -l to check. I think they are all ok now, and you can close the ticket.

[jkeenan]

Replying to doughera:

items listed in the OP; or (b) identify which items have been resolved? On Linux, you can use chrpath -l to check. I think they are all ok now, and you can close the ticket.

Never having used chrpath before, I had to install its Debian package to do this. I checked on all the executables and all the .so files. In the case of the executables, the output always looked like this:

$ chrpath -l parrot
parrot: RPATH=/home/jimk/gitwork/parrot/blib/lib

In the case of the .so files, the output always looked like this:

$ chrpath -l ./blib/lib/libparrot.so.3.0.0
./blib/lib/libparrot.so.3.0.0: no rpath or runpath tag found.
$ $ chrpath -l runtime/parrot/dynext/bit_ops.so
runtime/parrot/dynext/bit_ops.so: no rpath or runpath tag found.

Is that the expected output? Does it suffice to close the ticket?

Thank you very much.

kid51

[doughera]

Replying to jkeenan:

Never having used chrpath before, I had to install its Debian package to do this. I checked on all the executables and all the .so files. In the case of the executables, the output always looked like this:

> $ chrpath -l parrot
> parrot: RPATH=/home/jimk/gitwork/parrot/blib/lib

In the case of the .so files, the output always looked like this:

> $ chrpath -l ./blib/lib/libparrot.so.3.0.0
> ./blib/lib/libparrot.so.3.0.0: no rpath or runpath tag found.
> $ $ chrpath -l runtime/parrot/dynext/bit_ops.so
> runtime/parrot/dynext/bit_ops.so: no rpath or runpath tag found.

Is that the expected output? Does it suffice to close the ticket?

To be absolutely thoroughly paranoid, you would have to run 'make install' and run that command on the installed versions, not on the versions in the build directory. However, parrot doesn't actually build 'installable' versions of dynext/*.so anyway, so it wouldn't matter.

I've closed the ticket.