Update page 'FAQs'

Russtopia 2023-10-16 23:46:52 -07:00
parent f3a6c277f7
commit 857554d014
1 changed files with 7 additions and 5 deletions

12
FAQs.md

@ -26,12 +26,14 @@ That said, I think it can be objectively said that using Go *greatly diminishes
### But forks of `openssh` exist with PQ (Post-Quantum) KEx/KEM support.
Sure, but again this was a learning project, and those are also written in C, within the greater complexity of the `openssh` codebase. I see Go as being more inherently secure, and the source code easier to maintain, which also aids in security when making future changes. Diversity in solutions for network shell access is also good.. we've all relied exclusively on `openssh` for a long time, and a monoculture is dangerous.
Sure, but again this was a learning project, openssh only added PQ algos after I had this project up and running, and again openssh is written in C, within the greater complexity of the `openssh` codebase. I see Go as being more inherently secure, and the source code easier to maintain, which also aids in security when making future changes.
A diversity in solutions for network shell access is also good.. we've all relied exclusively on `openssh` for a long time, and a monoculture is dangerous. (Recall the 'heartbleed' fiasco and the scramble to fix and/or find other SSL/TLS libraries to avoid a security monoculture).
### But openssh has keystroke timing obfuscation.
Yeah, I did that early on with this project, about two years prior; it could probably be improved, but I can say with confidence that xs did keystroke timing obfuscation *before it was cool*. :P See the discussion on 'chaffing' in general elsewhere in these docs.
Yeah, I did that early on with this project, almost three years before openssh announced; it could probably be improved, but I can say with some confidence that xs did keystroke timing obfuscation *before it was cool*. :P See the discussion on 'chaffing' in general elsewhere in these docs.
### You should have written it in Rust!
@ -39,10 +41,10 @@ Go away. Just kidding. Well, half-kidding. I plan to learn Rust someday, but not
### Why won't the server `xsd` build in Windows?
Windows has a completely different console and file handle model from UNIX/POSIX OSes. I jumped through some hoops to get the client `xs` building and running under MSYS2, but the server side needs a lot more platform-dependent voodoo. I don't have the expertise nor desire to go off into the weeds on this; contributors are welcome.
Windows has a completely different console and file handle model from UNIX/POSIX OSes. I jumped through some hoops to get the client `xs` building and running under MSYS2, but the server side needs a lot more platform-dependent voodoo. I don't have the expertise nor desire to go off into the weeds on this; contributors are welcome. If you can make `xs` a first-class terminal app for Windows, please send patches!
If you can, contribute such cross-platform console and exec/file-handle code to the Go core standard libraries. They are still grappling, AFAIK, with how best to support an OS-neutral terminal/console model.
Even better, if you can, contribute such cross-platform console and exec/file-handle code to the Go core standard libraries. They are still grappling, AFAIK, with how best to support an OS-neutral terminal/console model.
### Why is there a separate `xspasswd` util and config file?
Out of caution in early development. One still use it, but `xsd` can now use the main system passwd/shadow infrastructure via the `-L` switch.
Out of caution in early development. One may still use it, but `xsd` can now use the main system passwd/shadow infrastructure via the `-L` switch and it should be used by default.