Dear Roland,
> Both issues where done so by design.
I expect so, but it makes issues during use :-(
> For the password, there was a reasonable concern, that passwords may be
> read-out. Now, you could argue, that monitoring the cumpcap call gives
> you the password anyway, which is correct. The intended
> usecase originally was to use the password together with ssh, which was
> later superseded by using the identity file, which can be stored normally.
Yes, but e.g. many our Cisco devices do not support identity file use :-(
Nevertheless, is password stored in memory during runtime so big issue?
I'm thinking about multiple approaches:
a) Allow to store password in memory during runtime
b) Keep 'password' as it is for backward compatibility and create
'runtime-password' type which will store password during runtime and
editor will warn about the risk. extcaps must be updated to use this new
item type.
c) Wireshark will remember that some password item was used during last
run and reopen extcap dialog to enter it again.
I prefer a) or b) because c) is annoying.
> As for empty values, we have no possibility to detect, if the empty
> value you entered is the default one, or if it is a new set value.
> Therefore empty was implemented as "return default value". One could
> argue, that default values should only be used, if you reset the
> complete configuration, but than you could not reset an individual
> configuration.
I understand the background, but how to solve it. Modify advanced
settings API to be able to clear a setting? But it involve editor to add
'set default' button which will call the new API?
Best regards,
Jirka