On Sun, Aug 11, 2019 at 07:58:15PM -0400, Giles Orr via talk wrote:

William: 'How does it compare with "testssl.sh" ?'

I have no idea, I haven't used that. If you point me to it I'll take a look.

We use it at work. http://testssl.sh/ I don't know how they give out different responses, but if you use browser, you get frontpage. If you use curl or wget, you get the script. -- William Park <opengeometry@yahoo.ca>

Well damn. That's a lot of very good suggestions. I will dispute one of them: you said (more than once I think) that I don't need to quote variables. You are technically correct ... right up until a variable value has a space in it. Then everything goes to hell in a handbasket. I use 'shellcheck' ( https://github.com/koalaman/shellcheck ) through NeoVim's Syntastic ( https://github.com/vim-syntastic/syntastic ) plugin, and it's a real nag about quoting variables. And I agree with it, having had unquoted variables explode in my face. I hope to implement and test most of the rest of your suggestions (along with the previous ones) shortly. Thanks. On Sun, 11 Aug 2019 at 23:49, William Park via talk <talk@gtalug.org> wrote:

On Sat, Aug 10, 2019 at 11:46:40AM -0400, Giles Orr via talk wrote:

...

If you're interested, you can find the details here:

https://www.gilesorr.com/blog/tls-https-details.html

Any suggestions to improve the script would be most welcome.

OK, here it goes...

...

# Put most desirable/least-likely last: for opensslbinary in /usr/local/opt/openssl@1.1/bin/openssl /usr/local/opt/opens sl/bin/openssl /usr/bin/openssl do # Every version of OpenSSL I've checked (several across multiple # OpenSSL versions and Apple's LibreSSL) respond to 'openssl version' # with '<brand> <version-no> ...' - there may or may not be stuff after # those two items (usually a build date, but not with Libre). # if [ -f "${opensslbinary}" ]

'-f' tests if it's a file. Maybe you should use '-x' which tests if it's executable.

...

then output="$("${opensslbinary}" version)" brand="$( echo "${output}" | awk '{ print $1 }')" version="$(echo "${output}" | awk '{ print $2 }')" if [[ "OpenSSL" == "${brand}" ]] then if [[ "${version}" == "1.1"* ]] then OPENSSL="${opensslbinary}" fi fi

You got 7 subshells here. You can reduce it to 1 subshell:

read a b rest <<< $($opensslbinary version) case $a:$b in OpenSSL:1.1*) OPENSSL=$opensslbinary ;; esac

...

fi done

Maybe you should break out of the for-loop as soon as you find something correct. As is, OPENSSL will be the last correct one.

...

function help() { echo "Usage:" echo " $(basename "${0}") [-h]|<domain-name>" echo "" echo "Show HTTP(s) and certificate details." echo "Do not include the 'http(s)://' leader on the domain name." echo "" echo "-h show this help and exit"

Instead of echo'ing each and every line, you can do

cat << EOF Usage: $(basename "${0}") [-h]|<domain-name>

Show HTTP(s) and certificate details. Do not include the 'http(s)://' leader on the domain name.

-h show this help and exit EOF

...

function expiry_date() { echo "${1}" | ${OPENSSL} x509 -noout -dates | grep notAfter | awk 'BEGIN { F S="=" } { print $2 }' }

You can get rid of grep, since you're already using awk.

echo "$1" | ${OPENSSL} x509 -noout -dates | awk -F= '/notAfter/ {print $2}'

...

function days_to_expiry() { expiry_date="$(echo "${1}" | ${OPENSSL} x509 -noout -dates | grep

notAfter |

...

awk 'BEGIN { FS="=" } { print $2 }')"

You already defined expiry_date(), so why not use it here.

expiry_date=$(expiry_date "$1")

...

if [[ "$(date --version 2>/dev/null)" == *"GNU"* ]] then # Linux (or at least GNU) expiry_epoch_seconds=$(date --date="${expiry_date}" "+%s") else # Assuming the Mac version: expiry_epoch_seconds=$(date -jf '%b %e %H:%M:%S %Y %Z'

"${expiry_date}"

...

"+%s") fi

Testing for "GNU" string can be done more simply using grep.

if date --version 2>/dev/null | grep -q GNU; then ... else ... fi

...

function tlsversions() { successful="" failed="" for tlsversion in ssl2 ssl3 tls1 tls1_1 tls1_2 tls1_3 do success=$(echo | ${OPENSSL} s_client -connect "${1}":443 -${tlsversion}

...

/dev/null 2> /dev/null ; echo $?) if [ ${success} -eq 0 ] then successful="${tlsversion} ${successful}" else failed="${tlsversion} ${failed}" fi

Testing if a command succeeded or failed can be done in-line.

if echo | ${OPENSSL} s_client -connect "${1}":443 -${tlsversion} &>/dev/null; then successful=... else failed=... fi

Also, do you really need to send empty line to openssl? Maybe you can redirect stdin from /dev/null as well, like

openssl ... </dev/null ...

That will reduce 3 subshells to 0.

General observation:

1. You don't need quotes in variable assignments like var="$(...)" var="$var1"

2. The following tests are the same. They both tests if var is empty. [ "$var"x = x ] [ -z "$var" ]

3. Testing if command succeeded or failed can be done in-line. if command1 | command2 | command2; then ... else ... fi

4. Case statement is usually better than if statement. eg. if [[ "$var" == glob ]]; then ... fi vs case $var in glob) ... ;; esac Note the missing quotes in case, too. You don't need it. -- William Park <opengeometry@yahoo.ca> --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

-- Giles https://www.gilesorr.com/ gilesorr@gmail.com

| From: William Park via talk <talk@gtalug.org> | 1. You don't need quotes in variable assignments like | var="$(...)" | var="$var1" True. Even if var1 has whitespace. But the quotes are harmless. The rule I aspire to following: Quote all shell variable references EXCEPT when they must not be quoted (rare). It's a lot easier than knowing the very odd rules applying to assignment and other special contexts. Why is assignment odd? Because, syntactically, it is a kind of word (an ASSIGNMENT_WORD according to POSIX). | 2. The following tests are the same. They both tests if var is empty. | [ "$var"x = x ] | [ -z "$var" ] I like -z Superstitiously, I would write [ "x$var" = x ] instead of [ "$var"x = x ] I would otherwise worry that if $var started with, say, -, funny things might happen. | 3. Testing if command succeeded or failed can be done in-line. | if command1 | command2 | command2; then | ... | else | ... | fi When I learned sh (long before POSIX) I think that the Bourne Shell set the exit status of a pipeline to the exit status of the first command. So I'm (needlessly) nervous about what the exit status of a pipeline is. BASH has an option to have a pipeline fail if any component fails. Seems useful (but not portable): -o pipefail Speaking of useful bash options, I always turn on these two options in my BASH scripts -e stop dead when a command returns an error in an untested context -u consider a reference to an undefined variable to be an error These catch a lot of errors that might otherwise go unnoticed. | 4. Case statement is usually better than if statement. eg. | if [[ "$var" == glob ]]; then | ... | fi | vs | case $var in | glob) ... ;; | esac | Note the missing quotes in case, too. You don't need it. I think that [[ ]] is a BASHism. I presume that it has advantages over [ ] but I don't know them. In the old days, test (AKA [ ]) wasn't built-in and so case was faster. This isn't true of modern shells.

On Fri, Sep 13, 2019 at 09:22:54AM -0400, Giles Orr via talk wrote:

Having solicited suggestions for improvement, I got more than I bargained for (but it was all good!). It took a while, but I've incorporated most of the suggestions:

https://www.gilesorr.com/blog/tls-https-details2.html

Hmm, minor personal irritant about variable assigment: var=$(...) is enough. You don't need to do var="$(...)" Eg. $ a="11 * 22" $ b=$(echo "$a") $ c="$(echo "$a")" $ declare -p a b c declare -- a="11 * 22" declare -- b="11 * 22" declare -- c="11 * 22" -- William Park <opengeometry@yahoo.ca>

On Sat, 14 Sep 2019, D. Hugh Redelmeier via talk wrote:

| From: William Park via talk <talk@gtalug.org>

| Hmm, minor personal irritant about variable assigment: | var=$(...) | is enough. You don't need to do | var="$(...)"

I think that getting quotes right in sh is hard. I support the simplest rule that works:

Always double-quote a $ thing UNLESS it must not be quoted.

The case you point out may be quoted, so I would quote it.

The only time an assignment needs to be quoted is when it contains literal whitespace. Using quotes on an assignment is just as silly as always using braces: echo "${var}" You don't always do it just because sometimes it is needed. -- Chris F.A. Johnson <http://cfajohnson.com/> =========================== Author: =============================== Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress) Pro Bash Programming: Scripting the GNU/Linux shell (2009, Apress)

On Sun, 15 Sep 2019 at 11:01, William Park via talk <talk@gtalug.org> wrote:

On Sat, Sep 14, 2019 at 10:02:46AM -0400, D. Hugh Redelmeier via talk wrote:

...

| From: William Park via talk <talk@gtalug.org>

| Hmm, minor personal irritant about variable assigment: | var=$(...) | is enough. You don't need to do | var="$(...)"

I think that getting quotes right in sh is hard. I support the simplest rule that works:

Always double-quote a $ thing UNLESS it must not be quoted.

The case you point out may be quoted, so I would quote it.

Extra quotes distract your eyes, makes it difficult to read or spot a bug. It's like always carrying an opened umbrella (because you can), when you should do it only when it rains.

We covered this the first time I posted about the script - clearly there are some strongly held opinions on the subject. I'm going to state mine once. If you have a variable called "a" and another called "ab" and you type "$ab" the shell script, you'll get the contents of variable "ab" not the contents of variable "a" followed by the letter "b". So I _always_ put braces around my variable names - even though it's a pain to type and not particularly beautiful. It's syntactically correct and I won't ever get an unexpected error. My thinking is the same about quoting. filename="/var/log/apache.log" cat $filename (Never mind it's a contrived example.) That works just fine. I didn't brace or quote $filename. And - as I said last time - everything goes swimmingly right up until someone edits your file, or gives it some input such that the filename variable includes a space. And then - if you're lucky - you get a "file not found" error, but depending on your code the error may be much more obscure. Which is bad enough if you have to dig out the error, and far worse if the script is in the hands of someone who has no Bash knowledge. I choose to use the quotes and braces as a precaution against possible future problems. Some people don't, and that's fine. But what I'm doing isn't "wrong" (it's valid and safe syntax), so I don't think it's worth a lot of debate. -- Giles https://www.gilesorr.com/ gilesorr@gmail.com