Opinions about what's better about the`openssl` usage for Windows users

[qlrd]

Some questions for Windows dev/users, important to continue Window's implementation:

Description:

In windows implementation, once the Application is running, a check of openssl existence in the PATH (a set of places/folders) will occur. If an openssl implementation isnt found, It will then request that one of many be installed. As pointed by odudex, this can lead to complications and/or confusion.

Therefore, three possible options were identified:

1: Include an openssl binary internally to KruxInstaller

• PROS:
  • Facilitating the user experience
• CONS:
  • Giving up the self-verification of installed programs.

2: Asking to install only one openssl recommendation

• PROS:

  • A compromise between facilitating the user experience and allowing self-checking of installed programs.

• CONS:

  • Requires one or more steps before using KruxInstaller.

    3: Asking to install one openssl from many options:

• PROS:

  • Allows freedom of choice between options and self-verification;
  • Opens the possibility of including a user configuration, being able to modify choices.

• CONS:

  • Requires one or more steps before using KruxInstaller;
  • Giving up the user experience, which can lead to confusion.

[ghost]

It's likely that the majority of Windows users downloading the Krux Installer will not have openssl installed, unless they are developers using git.

I ran into a similar problem packaging Krux releases. My goal was for regular users to be able to download the release and flash Krux to their devices without having to set up a development environment. Unfortunately, ktool is necessary to flash the firmware, but it is a python file requiring a python installation to run it. What I ended up doing was forking the ktool repo and adding a Github Action to build executables for every platform using pyinstaller so people could simply run ./ktool-{platform} ... without having to download some external, third-party executable.

You could do something similar, packaging a known-good version of openssl with the Windows build (perhaps even downloading + building it within the Github Action, if you want) to fall back on if the user does not have openssl on their PATH. This would avoid the need to prompt the user to do anything, but would still let them have some say in which openssl version gets run. The more paranoid among us can override which version is used by simply having it installed and available on their PATH.

[qlrd]

@jreesun, thanks for your valuable observations.

You could do something similar, packaging a known-good version of openssl with the Windows build (perhaps even downloading + building it within the Github Action, if you want) to fall back on if the user does not have openssl on their PATH.

I liked this approach; this could allow users to check, in Github Action, any possible irregularities, giving more transparency.

This would avoid the need to prompt the user to do anything,

odudex commented on this and how inappropriate it could be for the end user.

but would still let them have some say in which openssl version gets run. The more paranoid among us can override which version is used by simply having it installed and available on their PATH.

This opens up the possibility of a user configuration menu where you could customize some options (openssl PATH, SDCard mounting options and others that haven't been thought of yet).

I will start my research to implement this.

[qlrd]

Made an github action to compile openssl under windows.

https://github.com/qlrd/compile-openssl-windows-action

I think, in this way, it would be easy to implement a builtin openssl under krux-installer

[qlrd]

You could do something similar, packaging a known-good version of openssl with the Windows build (perhaps even downloading + building it within the Github Action, if you want) to fall back on if the user does not have openssl on their PATH.

@jreesun, i believe the main idea (packaging a known-good version of openssl -- in this case the stable 3.0.7 -- building it within) was done.

Tested it in my machine and worked. If possible, could you test to?

Maybe I need to remove extra files (documentation generated by openssl documentation/extra executables) and optimize openssl compilation options (for example, we do not need RSA algorithms?).

• Link to the last build with openssl
• Link to the last artifact generated