Abort sending when message authentication fails#980
Merged
schollz merged 1 commit intoschollz:mainfrom Oct 16, 2025
Merged
Conversation
This either means that the TCP connection did not use the proper key to encrypt (which should never happen when running properly) or the receiver wrote a key which starts with the same 4 characters, but does not match the sender's code. If the latter, regardless if the user attempts to read the message by correcting the key, it will always receive an error after the first failure. However, the sender will not be closed, making it difficult to detect what happened and why the transfer does not succeed. This change also forces the sender to close when the receiver uses a key that starts with the same characters, but is a different one
Contributor
Author
|
Perhaps, a better approach would be to keep the sender open, but try and fix the bug when the correct secret is used will no longer work? |
Owner
|
Looks good!! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note: I'm reopening this PR in case you missed it last time. Let me know if there was something wrong with the previous one. I also realized that maybe the problem this was solving is not clear, I attached a video now that shows the previous bug still exists on main.
This either means that the TCP connection did not use the proper key to encrypt (which should never happen when running properly) or the receiver wrote a key which starts with the same 4 characters, but does not match the sender's code. If the latter, regardless if the user attempts to read the message by correcting the key, it will always receive an error after the first failure. However, the sender will not be closed, making it difficult to detect what happened and why the transfer does not succeed. This change also closes the sender when the receiver uses a key that starts with the same characters, but is a different one.
In the video, note that a mistype will let the sender open, even though the receiver can no longer receive the message.
Screencast.From.2025-10-13.12-15-18.mp4