Hello Team, I'm cc`ing the upstream of o-saft, Achim.
When I started packaging o-saft for Debian, Achim got in contact interested in helping us having a high quality package for o-saft. It happened that we changed some emails but I didn't took enough time to actually improve the package, and would like some help with it. There are a couple of things, and I will paste parts of emails Achim sent me (with their permission), but the main and tricky problem is bundling some old version of openssl with the package. You see, o-saft needs an old version of openssl to be able to check for old ssl things (ciphers etc.). I know there has been some talk about getting an "openssl-insecure" package for the testssl.sh[0] package for the same reason. I think we should rather talk with upstream and propose some bundling of this required version of openssl into o-saft. Currently, o-saft has a helper builder script that downloads and builds the required openssl, but we can't use it on Debian as we can't download things at build time. What I need help to, is figuring out something that upstream can do it in a way that allow us to ship this statically linked openssl. But I don't wanna ask upstream for something that could end up not being useful because somebody on our side blocked the approach. Here I will paste most of the emails usptream sent me, some of the changes may have been addressed already and sorry for not removing it, I removed the parts I remember I have addressed already, I know I could spend more time on the formatting of the email but I think it's better to ask for help now as I've been dragging this for too long already: I'd like to suggest following improvments: > ... > > 2. o-saft.pl (/usr/bin/o-saft) > > produces some warnings, quick&drty fix in /usr/bin/o-saft: > > /usr/share/o-saft/o-saft.pl --no-sslv2 --no-sslv3 --no-tlsv3 "$@" > > a more elegant fix would be: > a) in /usr/share/o-saft/.o-saft.pl (remove #): > > --no-sslv2 > --no-sslv3 > --no-tlsv4 > > b) in usr/bin/o-saft: > > /usr/share/o-saft/o-saft.pl --rc "$@" > > 3. o-saft.pl uses a special compiled openssl. Ist should be build on kali > and installed independent of /usr/bin/openssl, best in > /usr/local/openssl/ > Most of the warning you currenly get are because modern /usr/bin/openssl > does not support what's needed to check SSL/TLS. > > The complete build commands can be found in the Dockerfile, see lines > following > > #== Pull, build and install enhanced openssl > > If needed, I can provide a special build-script. > > > Finally, hope you have seen that there already is /usr/share/o-saft/o-saft > Pleace consider to use that in /usr/bin/o-saft in future. > It has option --cli to start as CLI o-saft.pl , or --gui to start the gui > o-saft.tcl . It will (next version) start the GUI if there is no tty. > This enables o-saft to be started from the panel menu. > > Please let me know, if you need assistance. > > I've setup contrib/install_openssl.sh to fully work on all debian-based > systems > systems. The updated version is available at > https://github.com/OWASP/O > -Saft/blob/master/contrib/install_openssl.sh > No need to look in the Dockerfile (as the script uses the same code;-) > > Just a few note on contrib/install_openssl.sh > * it downloads source of openssl-chacha > * installs Perl modules using "perl -MCPAN" > * install everything in /usr/local > > It's already part of the package and then can be used directly with/from > the next > official verion of o-saft.tgz. > > /usr/local is currently not used by Kali, so you may "pack" that after > running > contrib/install_openssl.sh and put it into the o-saft package. > > As openssl is already installled on Kali as /bin/openssl, and > /usr/local/openssl/bin > containing the newly compiled openssl-chacha is not part of the PAH > environment > variable, I don't see a conflict. > > More difficult would be the installed Perl modules, as Perl's @INC > contains /usr/local > before /usr. Currently only Net::SSLeay is effected (which was > pre-installed on Kali). > However, a "normal user" won't see the difference, as the adapted > Net::SSLeay in > /usr/local backward compatible to the pre-installed in /usr. > > Another idea is to install openssl-chacha and the Perl modules in > /usr/share/o-saft/lib > o-saft.pl is already prepared for that. > > Let me know, if this would simplify the packageing. > Finally: > you) I recommend you get used to contrib/install_openssl.sh > as a fully patched openssl enables the full power of o-saft > me) I'll further improve contrib/install_openssl.sh (installing Perl > mudule > only if missing, trying to install in /usr/share/o-saft/lib, ...) > we) you tell me where you need assistance ;-) > Does it make sence to provide two packages: o-saft and o-saft-dev ? > Then only o-saft-dev has the dependency libperl-critic-perl. > There is already INSTALL.sh which removes the files not used at runtime, > actually it's the diff of o-saft and o-saft-dev :-) > > You may use it like: > env inst=/usr/share/o-saft INSTALL.sh --install --n > > Let me know if I should improve or adapt INSTALL.sh. > So yeah, we need to think about a way of having o-saft with support for all of the openssl things, and also probably split the package into a gui and a dev one. Thanks! [0]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803259 -- Samuel Henrique <samueloph>
