easyrsa: 319: set: Illegal option -o echo

[HarmtH]

I'm running easy-rsa without a terminal and therefore the stty calls in the script fail.

As fallback set +o echo and set -e echo are used, but these settings don't seem to exist, at least not in zsh, bash or dash.

[TinCanTech]

How do you run easyrsa3 without a terminal ?

[HarmtH]

ssh -T or cronjobs for example.

[ecrist]

This is a pretty easy fix. I'll work on getting it in over the next couple days.

Just need to wrap hide_read_pass with test -t I think. Need to do some testing.

[merlin-tc]

I think I am hitting the same bug. I am using easyrsa in combination with an ansible playbook.
I just commented the offending part of line 320 for now.

(stty echo 2>/dev/null) # || set -o echo

[ecrist]

Can @HarmtH or @merlin-tc try this in your use cases?

Replace/modify the hide_read_pass() function to look like the following:

hide_read_pass()
{
        # if we're not a tty, these will fail
        if [ -t 1 ];
        then
                (stty -echo 2>/dev/null) || set +o echo
                read -r "$@"
                (stty echo 2>/dev/null) || set -o echo
        else
                read -r "$@"
        fi
} # => hide_read_pass()

[HarmtH]

I've actually hit this https://github.com/OpenVPN/easy-rsa/blob/master/easyrsa3/easyrsa#L320 instance of set -o echo. Can you update it there as well?

I think this fix will work, but this will only fix the problem when stty fails due to no terminal, set -o echo will still be executed when stty fails for other reasons.

[ecrist]

The other command is for an attempt to work with the sh we ship for windows. Nothing to do for now until we move away from writing cross platform shell scripts. I’ll try to update on L320 today. Eric Crist

…

On May 17, 2019, at 10:01 AM, Harm te Hennepe ***@***.***> wrote: I've actually hit this https://github.com/OpenVPN/easy-rsa/blob/master/easyrsa3/easyrsa#L320 instance of set -o echo. Can you update it there as well? I think this fix will work, but this will only fix the problem when stty fails due to no terminal, set -o echo will still be executed when stty fails for other reasons. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[HarmtH]

Yes I know. The annoying thing is that an illegal set option is treated as a syntax error and thus aborts the script in every shell I've tried (dash, zsh, ksh..) except bash. And there is no satisfactory way to get the available set options. set -o gives you the available options and their current settings, but in an unspecified layout, according to the POSIX docs.

[HarmtH]

Come to think of it, perhaps we can try setting the option in a subshell, and then set it for real if that succeeds:

(stty -echo 2>/dev/null) || { (set +o echo 2>/dev/null) && set +o echo; }

No unexpected aborts possible this way.

[merlin-tc]

@HarmtH your command works when called via ansible or a non interactive shell.

[luizluca]

(OpenWrt) ash does not have "set -o echo".

root@OpenWrt:~# set -o echo
-ash: set: illegal option -o echo

But it does not have stty as well.

The only viable option here is "read -s". I'll PR something...

[TinCanTech]

It seems that set -o option will be supported in future.
See entry 0000537 (and the related 0000052) in the Austin Group Issue Tracker.
https://www.in-ulm.de/~mascheck/various/set-e/

[HarmtH]

The only viable option here is "read -s". I'll PR something...

$ read -s foo
dash: 1: read: Illegal option -s

read -s is a (bash?) extension. And probably just does the equivalent of stty -echo

[luizluca]

read -s is a (bash?) extension. And probably just does the equivalent of stty -echo

It is.. when available. There is no stty by default in OpenWrt. 'read -s' also works in ash while it does not accept 'set -o echo'.

[TinCanTech]

Can we please keep separate issues in separate tickets.

[luizluca]

Can we please keep separate issues in separate tickets.

@TinCanTech , my fault. I got here because the same "set -o echo" abort issue got me. However, it was not because it's not a terminal but because there is no 'set -o echo' in ash.

Part of my PR #315 is just like @HarmtH suggested: using a subshell in order to silently test for 'set -o echo' support and avoid shell to abort when it got the illegal option. This discussion might be more "on topic" there.

[devZer0]

i'm getting this error during pivpn installation

An updated CRL has been created.
CRL file: /etc/openvpn/easy-rsa/pki/crl.pem

./easyrsa: 341: set: Illegal option -o echo
Adding system user `openvpn' (UID 106) ...
Adding new group `openvpn' (GID 112) ...

[TinCanTech]

@devZer0 This would probably be something to report to pivpn

[MichaIng]

This would probably be something to report to pivpn

No, this is called within the easyrsa script, and it is illegal on all shells tested and reported above. I'm not sure what this aims to do, but if it is valid on any shell, then probably easyrsa should check whether it's sh invocation is actually that shell before trying to set this otherwise illegal option.

EDIT: Ah I see now the actual fix: #315
It looks like this is part of v3.0.7 already which is used by PiVPN as well. The subshell redirects for the test look actually fine and work well here when testing isolated, so not sure how this error can still show up.