fix(cli): unusable empty password private keys#15022
Conversation
Ohhhhhhhhhhhhhhh, maybe that's why i didn't notice? I think i only used my existing keys to test jedisct1/rust-minisign#26 |
Package Changes Through afc4c13There are 4 changes which include tauri-cli with patch, @tauri-apps/cli with patch, tauri-utils with patch, tauri-bundler 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 |
|
Seems like the solution jedisct1/rust-minisign@8e18ed4 from the author is to go back to the behavior in v0.7.3, encrypt when empty string when no password is provided |
ffs |
|
And of course with an MSRV bump because of getrandom 0.4 😫 |
Yeah, added some comments in the tests
|
|
can't wait to have a reasonable msrv policy |
|
we're struggling in cargo-packager as well cause there we used 0.7.4+ for a long while as we never locked it to 0.7.3 as we did here. We're trying to keep compat with both key variants: crabnebula-dev/cargo-packager@main...fix/update-minisign Edit: don't have the brain capacity for it right now, so can't tell how much sense that makes |
|
We can't really pull that off here without locking people in one of those bad versions though It would be nice for minisign to change the |
* fix(cli): unusable empty password private keys * Bump minisign to 0.9 and revert other changes * Lock to `=0.7.3`
* fix(cli): unusable empty password private keys * Bump minisign to 0.9 and revert other changes * Lock to `=0.7.3`
2 participants
Fix updater signing private keys generated using
tauri signer generatewith empty password can't be used (The keys generated during tauri were broken between v2.9.3 and v2.10.0, you'll need to regenerate them)Waiting on jedisct1/rust-minisign#31 (or we can use the forked branch for now)
Fixes #14829
Closes #14957
Closes #14941