6 ms·

Security advisory for the Rust programming language (with a nice explanation): https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html https://blog.rust-lang.

Security advisory for the Rust programming language (with a nice explanation): https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html https://blog.rust-lang.org/2021/11/01/cve-2021-42574.html Rust 1.56.1 will be released later today. > To assess the security of the ecosystem we analyzed all crate versions ever published on crates.io (as of 2021-10-17), and only 5 crates have the affected codepoints in their source code, with none of the occurrences being malicious. Preview of the new helpful error: https://i.imgur.com/pGpZOnr.png https://i.imgur.com/pGpZOnr.png

robin_reala 5y ago
That’s a really impressively written error message.
- sodality2 5y ago
  That's one of Rust's selling points. For all I've used the rust compiler, not once have I ever not known what error it was pointing out: its error messages are incredibly helpful. Occasionally I am unsure why it's an error, but I always know what it's referring to and what I could do to fix it.
  - Timwi 5y ago
    I've had the same experience with C#. The error messages always state exactly what's wrong and where in the code it's wrong. Many of them (especially compiler _warnings_ intended to point out syntax that is almost certainly a bug) also tell you how to fix it (e.g. “consider using ‘new’ keyword if hiding was intended”).
    - hermitdev 5y ago
      Personally, I don't know why the last one (“consider using ‘new’ keyword if hiding was intended”) isn't an error by default in C# . Not overriding the base method is almost always a mistake, and if it's not a mistake, better to be explicit about it, anyways. My $.02...
joosters 5y ago
Their advisory is well-written and explains the problem well. The example code they use: if access_level != "user" { // Check if admin opens up a whole can of worms though. You don't need cunning invisible control codes to break that line, you could just replace any of the letters in 'user' with a different, but almost-identical looking unicode symbol and you'd still have an exploit. Even better, this would be a completely deniable attack ("oops, I must have accidentally pressed alt-R while typing that letter" excuse) - whereas explaining away why you checked in some magical RTL/LTR encodings and hacked up a comment is impossible. Plus, it would render well in far more apps, terminals, command line programs, etc etc
- _3u10 5y ago
  This stuff has always been there consider this code: if (uid = NULL) { // Check if root And if you’re using clang: if ((uid = NULL)) { // Check if root I'd venture that this is far more dangerous than unicode in strings... or how about: strcpy() or #include anything with a #DEFINE
  - deleted 5y ago
    [deleted]
  - fstrthnscnd 5y ago
    > if (uid = NULL) { // Check if root That's not the same class of error, since here a programmer can see the issue by simple inspection. > or #include anything with a #DEFINE This one perhaps is closer to the mark, although not based on unicode.
    - _3u10 5y ago
      To me it's the same class of error which is convincing humans and other automated tests that your code is OK when it isn't. I dealt with a bug that only appeared in release builds, and never in debug. The offending code looked roughly like this: if (blah) #ifdef DEBUG baz(); #endif bar(); The systemic problem was it was a project created by interns, and they'd review each others code. By the time the bug got to me the interns had left and a Sr Dev had spent a day looking for the bug. It took me an hour to find it. In isolation its easy to see but in the mess of all the other code, you really have to look for these things.

robin_reala 5y ago

That’s a really impressively written error message.

sodality2 5y ago
That's one of Rust's selling points. For all I've used the rust compiler, not once have I ever not known what error it was pointing out: its error messages are incredibly helpful. Occasionally I am unsure why it's an error, but I always know what it's referring to and what I could do to fix it.
- Timwi 5y ago
  I've had the same experience with C#. The error messages always state exactly what's wrong and where in the code it's wrong. Many of them (especially compiler _warnings_ intended to point out syntax that is almost certainly a bug) also tell you how to fix it (e.g. “consider using ‘new’ keyword if hiding was intended”).
  - hermitdev 5y ago
    Personally, I don't know why the last one (“consider using ‘new’ keyword if hiding was intended”) isn't an error by default in C# . Not overriding the base method is almost always a mistake, and if it's not a mistake, better to be explicit about it, anyways. My $.02...

joosters 5y ago

Their advisory is well-written and explains the problem well. The example code they use: if access_level != "user" { // Check if admin opens up a whole can of worms though. You don't need cunning invisible control codes to break that line, you could just replace any of the letters in 'user' with a different, but almost-identical looking unicode symbol and you'd still have an exploit. Even better, this would be a completely deniable attack ("oops, I must have accidentally pressed alt-R while typing that letter" excuse) - whereas explaining away why you checked in some magical RTL/LTR encodings and hacked up a comment is impossible. Plus, it would render well in far more apps, terminals, command line programs, etc etc

_3u10 5y ago
This stuff has always been there consider this code: if (uid = NULL) { // Check if root And if you’re using clang: if ((uid = NULL)) { // Check if root I'd venture that this is far more dangerous than unicode in strings... or how about: strcpy() or #include anything with a #DEFINE
- deleted 5y ago
  [deleted]
- fstrthnscnd 5y ago
  > if (uid = NULL) { // Check if root That's not the same class of error, since here a programmer can see the issue by simple inspection. > or #include anything with a #DEFINE This one perhaps is closer to the mark, although not based on unicode.
  - _3u10 5y ago
    To me it's the same class of error which is convincing humans and other automated tests that your code is OK when it isn't. I dealt with a bug that only appeared in release builds, and never in debug. The offending code looked roughly like this: if (blah) #ifdef DEBUG baz(); #endif bar(); The systemic problem was it was a project created by interns, and they'd review each others code. By the time the bug got to me the interns had left and a Sr Dev had spent a day looking for the bug. It took me an hour to find it. In isolation its easy to see but in the mess of all the other code, you really have to look for these things.