-
Notifications
You must be signed in to change notification settings - Fork 851
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[core]Fixing the group option that should be taken from a socket #2912
Merged
maxsharabayko
merged 5 commits into
Haivision:master
from
ethouris:dev-fix-group-option-get
Aug 14, 2024
Merged
[core]Fixing the group option that should be taken from a socket #2912
maxsharabayko
merged 5 commits into
Haivision:master
from
ethouris:dev-fix-group-option-get
Aug 14, 2024
Conversation
This file contains 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
maxsharabayko
added
Type: Bug
Indicates an unexpected problem or unintended behavior
[core]
Area: Changes in SRT library core
labels
Mar 13, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For SRTO_KMSTATE
I suggest returning the least secure state among member sockets.
The order of security strength should be the following (from least secure to the most secure):
SRT_KM_S_BADCRYPTOMODE
– it is a connection rejection code, so maybe should be ignored or set only if no other members are there? 🤔SRT_KM_S_BADSECRET
– the password is wrong (set differently on each party); encrypted payloads won't be decrypted.SRT_KM_S_NOSECRET
– the sending party has set a passphrase, but the peer did not. In this case the sending party can receive unencrypted packets from the peer, but packets it sends to the peer will be encrypted and the peer will not be able to decrypt them.SRT_KM_S_SECURING
– pending security (HSv4 only).SRT_KM_S_UNSECURED
– no encryption/decryption.SRT_KM_S_SECURED
For |
…oup option test. Fixed build break in test for AES-GCM
Comment typo. Co-authored-by: Maxim Sharabayko <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Changed: Added a possibility to return the option value that was set on the socket, if there is at least one member.
The problem: this should rather concern only selected types of options, not all options. So far probably it should only
apply to the following options:
Without this the test will fail, and it's also not expected. We need this to work only for those options that could be altered as a result of the connection and involved parameter exchange.
Addresses #2918.