refactor: use 128 bits for nonce generation #14717
Conversation
Package Changes Through bee0175There are 7 changes which include tauri-utils with patch, tauri-build with patch, tauri-cli with patch, @tauri-apps/cli with patch, tauri-runtime-wry with patch, tauri-runtime with patch, tauri with patch Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
This reverts commit e172f2f.
base64 crate is small, but I guess we don't benefit from it much either
sftse
left a comment
sftse
left a comment
There was a problem hiding this comment.
Is it fine to reuse the nonce here? I'm not familiar with what this does, but "reusing nonce" usually indicates something is seriously wrong.
| hashes: Vec<String>, | ||
| ) { | ||
| let mut nonces = Vec::new(); | ||
| let nonce = OnceCell::new(); |
There was a problem hiding this comment.
If we generate the nonce outside the callback we can replace OnceCell with a regular local, remove fn replace_with_callback entirely and use str::replace.
There was a problem hiding this comment.
I'm not entirely sure about this but random number generation is usually slow, so in cases where we don't have inline scripts/styles, we don't pay the price for that
There was a problem hiding this comment.
Right, the semantics need to reflect it is only initialized if used, so OnceCell is a good fit. We could simplify the generic closure though and replace_with_cache(&OnceCell<String>)
I believe this is the desired way to do this, the re-use only happens in a single request. We insert nonce to inline script and style tags in the HTML and add them to the CSP header. If we don't reuse a single nonce here, we will end up with more nonce that could be attacked and waste time generating them For example, YouTube does this |
2 participants
Also, re-use the nonce through out a single HTML file to save compute and limit collisions
Reference: #14708 (comment)