[HN Gopher] totally_safe_transmute, Line-by-Line
       ___________________________________________________________________
        
       totally_safe_transmute, Line-by-Line
        
       Author : iafisher
       Score  : 19 points
       Date   : 2024-01-08 21:38 UTC (1 hours ago)
        
 (HTM) web link (blog.yossarian.net)
 (TXT) w3m dump (blog.yossarian.net)
        
       | jiggawatts wrote:
       | This is cute, but I hope it never turns up in any real codebase!
       | 
       | There's an updated version with Windows support and better
       | performance: https://github.com/John2143/totally-speedy-
       | transmute/
       | 
       | What worries me is this macro, which "smuggles" the unsafe
       | keyword past the forbid(unsafe_code) flag:
       | https://github.com/John2143/totally-speedy-transmute/blob/ma...
       | 
       | In my mind, this kind of capability makes Rust crate safety
       | scanning and associated metadata worthless as currently
       | implemented.
       | 
       | Package management tools ought to store code instead of binaries,
       | and perform safety checks to via _instrumented compilers_.
        
         | kibwen wrote:
         | _> In my mind, this kind of capability makes Rust crate safety
         | scanning and associated metadata worthless as currently
         | implemented._
         | 
         | If you wanted to backdoor a Rust program, you wouldn't need the
         | `unsafe` keyword at all. And if you want to use unsafe code,
         | that's fine, plenty of crates use unsafe code without anyone
         | being up in arms about it (e.g. the regex crate). This is a
         | party trick rather than something to be concerned about; at the
         | end of the day either you're auditing your dependencies (in
         | which case this would stick out like a sore thumb) or you're
         | not (in which case there are far easier ways to pwn you).
        
       | petsfed wrote:
       | I appreciate that "totally_safe_transmute" carries some
       | connotation that this is not a "safe" transmute, but rather a
       | suspiciously specific denial.
        
       | Pesthuf wrote:
       | Why don't the safe file I/O operations panic when /proc/self/mem
       | is opened for writing? I understand why they don't want to make
       | all of File I/O unsafe just for edge cases like this, but
       | shouldn't this be handled at runtime?
        
       ___________________________________________________________________
       (page generated 2024-01-08 23:00 UTC)