Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
maketempf() assumes /tmp is writable #1273
Although this is probably a minority of cases, running testssl.sh on a system that does not permit writing to /tmp (e.g. Termux on Android) causes the entire script to fail because the path /tmp is hardcoded and assumed to be writable:
A simple fallback to trying to write to the current directory seems like an easy and workable solution? I can write it up and do a PR if you'd like.
@drwetter Sounds good! I'll work on it!
Actually, no, the script does not run fully ... there are a few other issues on Termux that I'm going to look at ... the next one is quoted below. The error is that one can't write to /dev/stdout on Termux (not rooted)... I'm not sure if there are other things that are breaking it.
The script does start running on Termux -- it detects OpenSSL, it starts some of the scans, and does output some results. (I'm not 100% sure but I don't believe the deb package of openssl-1.1.1b-3 from termux-packages enables all of the "old" ciphers for testing -- it seems it might not enable SSLv2/3 by default -- see: https://github.com/termux/termux-packages/blob/master/packages/openssl/build.sh for the build options... but that's not too terribly difficult to fix -- I've compiled openssl before directly inside Termux with additional options.)
That said, I'm not too sure if there are additional things that could break. I'll dig in and find out. I see a few ways to possibly address these issues:
You know the code far better than I -- I'm not sure what the best approach is here.
I hope my message doesn't sound too critical ... I do really appreciate the work you've done
That's a matter of fine tuning. For the most part, also an openssl 1.1.1 is fine as the critical things are done with network sockets. Actually David and myself were discussing whether we're should use openssl 1.1.1 in the future.
Platform detection is not good and I try to avoid it. Think about e.g. BSD's sed: I can't tell whether the user also has GNU's sed installed throw ports, similar to Mac OSX. So what testssl.sh does is testing whther a feature / capability exists and populate global vars for this.
Actually if there are more cases like with stdout it would be better to think about a global approach (see previous comment) instead of hundreds (exaggerating) of small PRs. Because at the moment I don't have a picture what breaks on termux and what's to come. I appreciate if testssl.sh works on more platforms but I would like also to have a good code quality.
If you think it's more to come, you can also just get ~everything to work in your fork and when you think that a part of it is ready, then submit a PR. This part can be a "resolving the tmpfile issue" or "resolving the stdout issue".
Ja. But we should continue in English here as it's the common denominator.
Depends on where you are in the US or other English speaking countries. E.g. New York, especially the city, is not known for polite and indirect waffle. ;-)