Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stop using an absolute rpath #7132

Merged
merged 1 commit into from
Jun 16, 2013
Merged

stop using an absolute rpath #7132

merged 1 commit into from
Jun 16, 2013

Conversation

thestinger
Copy link
Contributor

This is a bad default, because the binaries will point at an absolute
path regardless of where they are moved. This opens up a security issue
for packages, because they will attempt to load libraries from a path
that's often owned by a regular user.

Every Rust binary is currently flagged by Debian, Fedora and Arch lint
checkers as having dangerous rpaths. They don't meet the requirements to
be placed in the repositories without manually stripping this from each
binary.

The relative rpath is still enough to keep the binaries working until
they are moved relative to the crates they're linked against.

http://wiki.debian.org/RpathIssue
https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath

@thestinger
Copy link
Contributor Author

The relative path is still ugly because it's non-portable (no such thing on Windows) and only hides the realities of dynamic linking up to the point where you move something. I've left it around because it is something people are relying on right now and it's usually sane.

@brson
Copy link
Contributor

brson commented Jun 14, 2013

When rpath was originally added, absolute paths were required to make the build work because the relative paths to libraries changed during the build. That doesn't appear to be the case now.

This is a bad default, because the binaries will point at an absolute
path regardless of where they are moved. This opens up a security issue
for packages, because they will attempt to load libraries from a path
that's often owned by a regular user.

Every Rust binary is currently flagged by Debian, Fedora and Arch lint
checkers as having dangerous rpaths. They don't meet the requirements to
be placed in the repositories without manually stripping this from each
binary.

The relative rpath is still enough to keep the binaries working until
they are moved relative to the crates they're linked against.

http://wiki.debian.org/RpathIssue
https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
bors added a commit that referenced this pull request Jun 15, 2013
This is a bad default, because the binaries will point at an absolute
path regardless of where they are moved. This opens up a security issue
for packages, because they will attempt to load libraries from a path
that's often owned by a regular user.

Every Rust binary is currently flagged by Debian, Fedora and Arch lint
checkers as having dangerous rpaths. They don't meet the requirements to
be placed in the repositories without manually stripping this from each
binary.

The relative rpath is still enough to keep the binaries working until
they are moved relative to the crates they're linked against.

http://wiki.debian.org/RpathIssue
https://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath
@bors bors closed this Jun 16, 2013
@bors bors merged commit 708395d into rust-lang:master Jun 16, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 27, 2021
…Manishearth

extend `single_element_loop` to match `.iter()`

This extends `single_element_loop` to also match `[..].iter()` in the loop argument. Related to rust-lang#7125, but not completely fixing it due to the lint only firing if the array expression contains a local variable.

---

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants