Replies: 0 comments 3 replies
-
perhaps identifying minimal protections that may be put in place to protect users in a new deploy in regards to this specifically, so thoughts IP Range CheckConfirm the nics in the device are only up on private ip ranges before retronas will launch, this is an extremely minimal protection mechanism, the user could then ack or define an accepted range if they want to operate outside of this scope. It would fall under a 'best project practice' approach IPV6IPv6 should potentially be an opt-in/opt-out for fresh deploys, as in my experience a lot of people forget to firewall ipv6 appropriately |
Beta Was this translation helpful? Give feedback.
-
Terms of Use / License I think its important that the user agrees to the security warning from the README.md (at a minimum) with additional comms on the license for this project at the cli on first launch I have drafted a disclaimer screen the user must agree to on launch, fleshed out the README.md a bit and added a subsequent cli option to re-display the Terms that the user can pass at startup for now |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Figured I'd do the deed and open a discussion on this, as noted by @danmons this project is considered incredibly insecure due to the required older protocols to support older hardware etc, as documented here https://github.com/danmons/retronas#WARNING-Security
I am opening this discussion to the group as a central point to discuss
This was prompted by a coding question from @FlotterCodername here and my own considerations in my tcpser branch, this may prove a good point for people to drop ideas etc.
e.g "We appreciate there is a limit to what can be done due to the target hardware and we have no control over deployments outside of the default recommendations."
Beta Was this translation helpful? Give feedback.
All reactions