3 ms·

Will there be a support for `{jndi:ldap://xyz}`? I jest :)

• nine_k 5y ago
  It's a fair question. The Rust's implementation apparently only looks up variables from the enclosing scope. By contrast, Python's f-strings allow arbitrary expressions, and could potentially fall for the LDAP trick, or something similar. Same with ES6's backtick-strings. I hope Rust will keep it simple and reliable, and won't allow calling functions in format strings.
  • AlphaSite 5y ago
    Pythons f strings are a “compile time” thing, I don’t think you can get that effect unless you eval the string.
  • kibwen 5y ago
    Furthermore, format strings in Rust can't just be any `String` or `&str`, they must specifically be string literals, which means they must necessarily be fully determined at compile-time and there's no chance that user input can influence the format string. > I hope Rust will keep it simple and reliable, and won't allow calling functions in format strings. Yes, I think people are wary of allowing full expressions in format strings as in Python. That said, I might like to see a small extension to the current rules, so that in addition to identifiers you could also access struct members. I agree that format string captures shouldn't present the chance to run arbitrary code, so I wouldn't even extend this to array indexing (which is overloadable via the Index trait).
  • dathinab 5y ago
    Pythons f-strings are still static formation, you just can move party of the code into the fstring. (Ignoring eval and similar.) The scary part about the vulnerability was that string >inputs< could dynamically delegate it's content to some magic information fetching system which by default allows accessing remote content in a way which by design can lead to remote code execution. I have no idea who though non static format strings are a good idea. Or an information fetching system which can trigger remote code execution. Or that this system doesn't require stric whitelisting.
    • nine_k 5y ago
      I see. Imagine that a LdapAddress class helpfully overrides __str__() in the way it happened in Log4j. Then a completely innocuous f-string that just prints the value of such an object in a log line could trigger execution of that code. No need to even have an expression that calls anything explicitly.
      • ratorx 5y ago
        If I saw __str__ making network requests, I’d consider it a strong anti-pattern too. Sure, if a library was doing it then I might not find out, but that still puts the issue squarely on the library doing questionable things, rather than the entire logging framework itself.
  • bluejekyll 5y ago
    Technically Rust calls functions on the variable being printed. Those are defined as "{}" uses the fmt::Display trait and "{:?}" uses the fmt::Debug trait.
    • nine_k 5y ago
      Oh. I wonder if the Display trait implementation can be enforced to have no side effects (beside allocation).
      • sidit77 5y ago
        When implementing Display you only get access to an immutable reference to self, so the only possibly side effects are writes to global variables.
        • bluejekyll 5y ago
          That depends on what Self contains. Using the Cell types and some of the other inner mutating types, it is possible to change the interior state of self even behind a shared reference. Additionally, with unsafe it’s also possible. This is in response to “the only possible” statement. Of course, doing so is not advisable.