-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Windows busybox install #1077
base: master
Are you sure you want to change the base?
Windows busybox install #1077
Conversation
Signed-off-by: Richard T Bonhomme <[email protected]>
Signed-off-by: Richard T Bonhomme <[email protected]>
Signed-off-by: Richard T Bonhomme <[email protected]>
Signed-off-by: Richard T Bonhomme <[email protected]>
Signed-off-by: Richard T Bonhomme <[email protected]>
Signed-off-by: Richard T Bonhomme <[email protected]>
Using |
To test on Windows 11: Copy From your git repo To:
Start Easy-RSA in a standard command prompt by using: Once the
Please post the full output. Errors concerning missing OpenSSL are acceptable. |
0b17d8d
to
483c828
Compare
Signed-off-by: Richard T Bonhomme <[email protected]>
483c828
to
d4743a9
Compare
Successfully tested on Windows 10, using Easy-RSA No-admin mode. Use this
|
I would suggest NOT shipping easy-rsa with busybox on Windows. Using native tools would be preferred, just as native tools are used on the *nix side of this project. OpenSSL is the only external dependency which really makes sense. If there are issues related to shell compatibilities and related challenges, in my view, it would make more sense to dive into WSL2 and such like environments. |
Here you go. Since WSL is not part of Windows, I don't think it worth to maintain Windows port, which uses crutches like sh/busybox. With WSL you could just |
The discussion regarding WSL is moot:
The resistance to
I will complete this PR but will refrain from merging to allow further discussion. |
PROS: This is my argument to support Windows as a non-admin user:
CONS: Personally, I am fundamentally against relying on WSL. |
For each external dependency you pull in, you need to ensure the project has capacity to pay attention to security vulnerabilities and provide duly updates whenever something critical arrives. Since this project provides a zip file with Windows binaries, the project is responsible to ensure these are up-to-date with the latest security fixes. That is why it is generally better to use what is already provided by the platform itself and have as few external dependencies as possible. You reduce the amount of code you need to pay attention to. I don't know where the previous set of Windows binaries comes from or how it is being packaged into this project. This project should regardless have as a goal to build binaries it ships and verify that the code it ships is not carrying any possible supply chain attacks. If the CA private key leaks, then the whole CA is busted. In regards to busybox, I do know that is a very attractive target for attacks - and new issues are discovered regularly. That does not mean that the previous So if swapping to busybox, do ensure there is a security process in place and the ability to quickly do new releases. When it comes to WSL (I presume @lstipakov meant "now" and not "not"), that is an infrastructure provided by Microsoft and gives you a native Linux environment to work in - where all the dependencies Easy-RSA need are already under maintenance by others. In fact, this project could even drop shipping OpenSSL binaries too. This would ensure this project can fully focus on Easy-RSA and not needing to be that concerned about shipping and maintaining external dependencies. |
@dsommers Thank you. I respect your opinion regarding the industry standards of security for external dependencies. However, from an Easy-RSA specific point of view, I disagree with you as follows. You say:
This is the very origin of the current problems facing Easy-RSA:
You say:
Easy-RSA use of busybox is extremely limited:
You say:
As an Easy-RSA user, if I must use Windows then I prefer not to have to rely on WSL. WSL is NOT open source. And, food for thought: What if MKSH were still actively maintained, would this discussion even take place ? |
The last problem is that of Easy-RSA integrated building of This is a huge commitment, for which, I do understand the resistance toward. If I were a gambler, I would bet my bottom dollar that OpenSSL (built by Easy-RSA) is a far more signifificant security risk than Busybox. However, given Full Admin access, Choose: Rock or Sea. |
Note that with WSL we do not need to ship anything at all - not easyrsa scripts nor openssl binary. EasyRSA is already in Ubuntu 22.04, which WSL uses by default.
I suggest we just ship only |
That is why the "Windows binary distribution" is quite pointless. Easy-RSA does not provide an installer by itself, it requires users to unzip a file and use the command line to use it from there. You need to have some technical experience just to come this far. If the user is instead instructed (as @lstipakov suggests) to setup WSL, which then gives you an Ubuntu environment out-of-the-box ... you still have a proper POSIX compliant environment and all external third-party dependencies included as part of the The argument that WSL is not open source, is also only partly true. WSL is more or less a virtual machine running a complete Linux distribution, but made far more user friendly that users don't have to setup and install the Linux distro themselves - it comes pre-setup. So when you are inside the WSL "container", you are in an open source environment. The only "non-open source" part here is the glue layers between the virtual machine instance and the Windows environment it runs under. Also consider that you don't need to care explicitly about Windows behaviours when going the WSL approach. You only need to ensure it works well under a recent enough and updated Ubuntu distribution. That is less maintenance burden for this project. |
For the record:
Closing this PR as unsuitable - #1078 |
Reopening temporarily. |
Fully integrate
busybox.exe
as an alternative to MKSH:sh.exe