Conversation

Notices

1. Embed this notice
   Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Monday, 25-Aug-2025 01:14:21 JST Jarkko Sakkinen
   Software crypto would really need its own "official" systemd service as that way any application could have audited crypto. I.e. crypto operations would be executed by that service and results returned back to the caller. It could probably be just user service running inside session in order to guarantee better privacy.
   
   This is partly because Rust does not have a proper DSO support, and this would address this flaw in Rust. It is not a question how great some random crate is but more like can you make software that can be used in production as per standards that companies use.
   
   E.g., I cannot recommend to use tpm2sh to use anything else except kernel testing for this exact reason no matter how the crates are implemented or how well I might orchestrate the calls.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Monday, 25-Aug-2025 01:14:19 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @jarkko I think this relies on the assumption that cryptographic libraries vulnerabilities are from their core, like the math part of them.
     
     Which while it's true for some side-channels attacks, there's a lot more on parsing (protocol, x509, …). So a separated service probably wouldn't help much there, unless it's one like TLS where it's pretty much a layer of encapsulation and you could use something like stunnel.
   • Embed this notice
     Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Monday, 25-Aug-2025 01:14:20 JST Jarkko Sakkinen

     in reply to
     It would be comptetitive advantage for Rust to have first class DSO support. It's like 99% of things Rusts static linking model is exactly right thing to do but for 1% of use cases you should just have a DSO.
     
     Prime examples:
     
     - Core crypto libraries. These need to be hotfixe when CVE arises.
     - Core graphic libraries.
     - System GUI libraries.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Monday, 25-Aug-2025 02:12:56 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @jarkko I'm not disagreeing with the DSO bit, I think this one would be fine.
     
     The system service on the other hand seems a lot of a problem for wholistic security (which is typically ignored by certification but isn't necessarily incompatible).
   • Embed this notice
     Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Monday, 25-Aug-2025 02:12:57 JST Jarkko Sakkinen

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan you have to keep in mind that while rust is memory safe there is no programming language that is "crypto safe". thus you need to do this in order to scale.
   • Embed this notice
     Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Monday, 25-Aug-2025 02:12:58 JST Jarkko Sakkinen

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan it's a special corner case and i'm talking about deployments at scale of even hundreds or thousands nodes and fucking armed guards and shit xD usually corps have this thing called Secure Development Lifecycle (SDL) process that everything to needs to comply and it is hard to map to bunch of Rust programs with random versions of random crypto.
   • Embed this notice
     Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Monday, 25-Aug-2025 02:12:59 JST Jarkko Sakkinen

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan it does not rely on assumptions. it is more like that in production you often need to have somehow certified/audited crypto. I.e. it is irrelevant how strong or weak the crypto is in some sense as long as it has gone through that process.
     
     thus, statically linked crypto is a problem.
     
     also it is a problem even when the crypto would audited that you can only hotfix all deployed rust by updating all possible rust programs. it's much easier to hotfix a single crypto entity, which could be DSO.
   • Embed this notice
     Jarkko Sakkinen (jarkko@social.kernel.org)'s status on Monday, 25-Aug-2025 02:14:15 JST Jarkko Sakkinen

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan AH OK sorry! Yeah, well that part was just a click bait ;-) I agree that it is engineering wise worse solution!
     Haelwenn /элвэн/ :triskell: likes this.