Skip to content
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

fix: don't broadcast public keys if the user is licensed #5190

Merged
merged 3 commits into from
Oct 30, 2024

Conversation

andrekir
Copy link
Member

prevents NodeInfo broadcasts with public keys when the user is licensed.

@jp-bennett
Copy link
Collaborator

Do we need this, with the is_licensed change I pushed earlier?

@JohnathonMohr
Copy link
Contributor

Please excuse my ignorance, but I'm curious to learn why this is necessary. I understand ham has to operate unencrypted, so the licensed node can't send anything encrypted, but why prevent another non-licensed node from sending something encrypted. Must a licensed node also not receive anything encrypted?

@thebentern
Copy link
Contributor

Do we need this, with the is_licensed change I pushed earlier?

Not sure your change will have an effect if they already have keys generated.

@andrekir
Copy link
Member Author

Do we need this, with the is_licensed change I pushed earlier?

yes. public keys are still being sent in the NodeInfo broadcasts when is_licensed is true.

@jp-bennett
Copy link
Collaborator

Please excuse my ignorance, but I'm curious to learn why this is necessary. I understand ham has to operate unencrypted, so the licensed node can't send anything encrypted, but why prevent another non-licensed node from sending something encrypted. Must a licensed node also not receive anything encrypted?

Last time I checked, I came to the conclusion that it was a problem, yes. Of course I can't currently find that source.

@jp-bennett
Copy link
Collaborator

Do we need this, with the is_licensed change I pushed earlier?

yes. public keys are still being sent in the NodeInfo broadcasts when is_licensed is true.

Got it. Yeah, looks good then.

@thebentern thebentern merged commit 28b469d into master Oct 30, 2024
45 of 46 checks passed
@thebentern thebentern deleted the ham_mode_key_bcast branch October 30, 2024 17:05
@fromthebeanbag
Copy link

I tried to find the legislative answer to amateur radio and encryption and only went down a rabbit hole. In Australia atleast from https://www.acma.gov.au/amateur-radio-operating-procedures I found the following.

But receiving signals as an amateur would mean the other party could only be another amateur and thus only unencrypted anyway. This not allowing reception of unencrypted would just be additional checks and balances.

Except

Encryption/scrambling
Transmissions from an amateur station must not be encrypted or scrambled, except for signals used to control a satellite, signals used to control a remote amateur station or by stations participating in emergency services operations or exercises.

Re-transmission
If you re-transmit another station’s transmission, you must have the other station’s permission and indicate it is a retransmission.

caveman99 pushed a commit that referenced this pull request Nov 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants