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

Stabilize std::error::Error::type_id #58048

Merged
merged 1 commit into from
Feb 2, 2019
Merged

Conversation

SimonSapin
Copy link
Contributor

This should have been part of #57834

FCP: #27745 (comment)

@Centril Centril added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. relnotes Marks issues that should be documented in the release notes of the next release. labels Feb 1, 2019
@Centril
Copy link
Contributor

Centril commented Feb 1, 2019

r? @Centril

@bors r+ rollup

@Centril
Copy link
Contributor

Centril commented Feb 1, 2019

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Feb 1, 2019

📌 Commit cc1e05f has been approved by Centril

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Feb 1, 2019
@bors
Copy link
Contributor

bors commented Feb 2, 2019

⌛ Testing commit cc1e05f with merge 3d35a9b...

bors added a commit that referenced this pull request Feb 2, 2019
Stabilize std::error::Error::type_id

This should have been part of #57834

FCP: #27745 (comment)
@bors
Copy link
Contributor

bors commented Feb 2, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: Centril
Pushing 3d35a9b to master...

@bors bors merged commit cc1e05f into rust-lang:master Feb 2, 2019
@@ -197,9 +197,7 @@ pub trait Error: Debug + Display {

/// Get the `TypeId` of `self`
#[doc(hidden)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should remove the doc(hidden), right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm that’s a good point. Why was this hidden in the first place? It has been since the method was first added in #24793. @aturon, do you remember?

@SimonSapin SimonSapin deleted the error_type_id branch February 10, 2019 20:10
@Centril Centril added this to the 1.34 milestone Apr 27, 2019
alexcrichton added a commit to alexcrichton/rust that referenced this pull request May 13, 2019
This commit destabilizes the `Error::type_id` function in the standard library.
This does so by effectively reverting rust-lang#58048, restoring the `#[unstable]`
attribute. The security mailing list has recently been notified of a
vulnerability relating to the stabilization of this function. First stabilized
in Rust 1.34.0, a stable function here allows users to implement a custom
return value for this function:

    struct MyType;

    impl Error for MyType {
	fn type_id(&self) -> TypeId {
	    // Enable safe casting to `String` by accident.
	    TypeId::of::<String>()
	}
    }

This, when combined with the `Error::downcast` family of functions, allows
safely casting a type to any other type, clearly a memory safety issue! A
security announcement will be shortly posted to the security mailing list as
well as the Rust Blog, and when those links are available they'll be filled in
for this PR as well.

This commit simply destabilizes the `Error::type_id` which, although breaking
for users since Rust 1.34.0, is hoped to have little impact and has been deemed
sufficient to mitigate this issue for the stable channel. The long-term fate of
the `Error::type_id` API will be discussed at rust-lang#60784.
alexcrichton added a commit to alexcrichton/rust that referenced this pull request May 13, 2019
This commit destabilizes the `Error::type_id` function in the standard library.
This does so by effectively reverting rust-lang#58048, restoring the `#[unstable]`
attribute. The security mailing list has recently been notified of a
vulnerability relating to the stabilization of this function. First stabilized
in Rust 1.34.0, a stable function here allows users to implement a custom
return value for this function:

    struct MyType;

    impl Error for MyType {
	fn type_id(&self) -> TypeId {
	    // Enable safe casting to `String` by accident.
	    TypeId::of::<String>()
	}
    }

This, when combined with the `Error::downcast` family of functions, allows
safely casting a type to any other type, clearly a memory safety issue! A
security announcement will be shortly posted to the security mailing list as
well as the Rust Blog, and when those links are available they'll be filled in
for this PR as well.

This commit simply destabilizes the `Error::type_id` which, although breaking
for users since Rust 1.34.0, is hoped to have little impact and has been deemed
sufficient to mitigate this issue for the stable channel. The long-term fate of
the `Error::type_id` API will be discussed at rust-lang#60784.
alexcrichton added a commit to alexcrichton/rust that referenced this pull request May 13, 2019
This commit destabilizes the `Error::type_id` function in the standard library.
This does so by effectively reverting rust-lang#58048, restoring the `#[unstable]`
attribute. The security mailing list has recently been notified of a
vulnerability relating to the stabilization of this function. First stabilized
in Rust 1.34.0, a stable function here allows users to implement a custom
return value for this function:

    struct MyType;

    impl Error for MyType {
	fn type_id(&self) -> TypeId {
	    // Enable safe casting to `String` by accident.
	    TypeId::of::<String>()
	}
    }

This, when combined with the `Error::downcast` family of functions, allows
safely casting a type to any other type, clearly a memory safety issue! A
security announcement will be shortly posted to the security mailing list as
well as the Rust Blog, and when those links are available they'll be filled in
for this PR as well.

This commit simply destabilizes the `Error::type_id` which, although breaking
for users since Rust 1.34.0, is hoped to have little impact and has been deemed
sufficient to mitigate this issue for the stable channel. The long-term fate of
the `Error::type_id` API will be discussed at rust-lang#60784.
bors added a commit that referenced this pull request May 13, 2019
…=pietroalbini

[beta] Destabilize the `Error::type_id` function

This commit destabilizes the `Error::type_id` function in the standard library.
This does so by effectively reverting #58048, restoring the `#[unstable]`
attribute. The security mailing list has recently been notified of a
vulnerability relating to the stabilization of this function. First stabilized
in Rust 1.34.0, a stable function here allows users to implement a custom
return value for this function:

    struct MyType;

    impl Error for MyType {
	fn type_id(&self) -> TypeId {
	    // Enable safe casting to `String` by accident.
	    TypeId::of::<String>()
	}
    }

This, when combined with the `Error::downcast` family of functions, allows
safely casting a type to any other type, clearly a memory safety issue! A
formal announcement has been made to the [security mailing list](https://groups.google.com/forum/#!topic/rustlang-security-announcements/aZabeCMUv70) as well as [the blog](https://blog.rust-lang.org/2019/05/13/Security-advisory.html)

This commit simply destabilizes the `Error::type_id` which, although breaking
for users since Rust 1.34.0, is hoped to have little impact and has been deemed
sufficient to mitigate this issue for the stable channel. The long-term fate of
the `Error::type_id` API will be discussed at #60784.
bors added a commit that referenced this pull request May 13, 2019
… r=pietroalbini

[stable] Destabilize the `Error::type_id` function

This commit destabilizes the `Error::type_id` function in the standard library.
This does so by effectively reverting #58048, restoring the `#[unstable]`
attribute. The security mailing list has recently been notified of a
vulnerability relating to the stabilization of this function. First stabilized
in Rust 1.34.0, a stable function here allows users to implement a custom
return value for this function:

    struct MyType;

    impl Error for MyType {
	fn type_id(&self) -> TypeId {
	    // Enable safe casting to `String` by accident.
	    TypeId::of::<String>()
	}
    }

This, when combined with the `Error::downcast` family of functions, allows
safely casting a type to any other type, clearly a memory safety issue! A
formal announcement has been made to the [security mailing list](https://groups.google.com/forum/#!topic/rustlang-security-announcements/aZabeCMUv70) as well as [the blog](https://blog.rust-lang.org/2019/05/13/Security-advisory.html)

This commit simply destabilizes the `Error::type_id` which, although breaking
for users since Rust 1.34.0, is hoped to have little impact and has been deemed
sufficient to mitigate this issue for the stable channel. The long-term fate of
the `Error::type_id` API will be discussed at #60784.
bors added a commit that referenced this pull request May 14, 2019
… r=pietroalbini

Destabilize the `Error::type_id` function

This commit destabilizes the `Error::type_id` function in the standard library.
This does so by effectively reverting #58048, restoring the `#[unstable]`
attribute. The security mailing list has recently been notified of a
vulnerability relating to the stabilization of this function. First stabilized
in Rust 1.34.0, a stable function here allows users to implement a custom
return value for this function:

    struct MyType;

    impl Error for MyType {
	fn type_id(&self) -> TypeId {
	    // Enable safe casting to `String` by accident.
	    TypeId::of::<String>()
	}
    }

This, when combined with the `Error::downcast` family of functions, allows
safely casting a type to any other type, clearly a memory safety issue! A
formal announcement has been made to the [security mailing list](https://groups.google.com/forum/#!topic/rustlang-security-announcements/aZabeCMUv70) as well as [the blog](https://blog.rust-lang.org/2019/05/13/Security-advisory.html)

This commit simply destabilizes the `Error::type_id` which, although breaking
for users since Rust 1.34.0, is hoped to have little impact and has been deemed
sufficient to mitigate this issue for the stable channel. The long-term fate of
the `Error::type_id` API will be discussed at #60784.
bors added a commit that referenced this pull request May 14, 2019
… r=pietroalbini

Destabilize the `Error::type_id` function

This commit destabilizes the `Error::type_id` function in the standard library.
This does so by effectively reverting #58048, restoring the `#[unstable]`
attribute. The security mailing list has recently been notified of a
vulnerability relating to the stabilization of this function. First stabilized
in Rust 1.34.0, a stable function here allows users to implement a custom
return value for this function:

    struct MyType;

    impl Error for MyType {
	fn type_id(&self) -> TypeId {
	    // Enable safe casting to `String` by accident.
	    TypeId::of::<String>()
	}
    }

This, when combined with the `Error::downcast` family of functions, allows
safely casting a type to any other type, clearly a memory safety issue! A
formal announcement has been made to the [security mailing list](https://groups.google.com/forum/#!topic/rustlang-security-announcements/aZabeCMUv70) as well as [the blog](https://blog.rust-lang.org/2019/05/13/Security-advisory.html)

This commit simply destabilizes the `Error::type_id` which, although breaking
for users since Rust 1.34.0, is hoped to have little impact and has been deemed
sufficient to mitigate this issue for the stable channel. The long-term fate of
the `Error::type_id` API will be discussed at #60784.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants