I think this is probably something we can address in a subsequent errata: what's happening here is that the plugin options code is "helpfully" noticing that the string passed in is an integer, and is automatically casting it to a Python 'int' type.

That should only be the case if the "password" is a valid base-10 integer, which hopefully will not be a common case in the field.

There's a straightforward way to hack around this for this specific cases, although it would be better to carry out a review of the automatic type conversion and decide whether it's actually useful or not.

I agree, that is why I'm suggesting 7.7.

Works fine with either alpha/mixed strings:

# ./sosreport --batch --debug -o skydive -k skydive.username="qux",skydive.password="password"

sosreport (version 3.6)

This command will collect system configuration and diagnostic
information from this Fedora system. An archive containing the collected
information will be generated in /var/tmp/sos.ppM4se.

For more information on the Fedora Project visit:

  https://fedoraproject.org/

The generated archive may contain data considered sensitive and its
content should be reviewed by the originating organization before being
passed to any third party.

No changes will be made to system configuration.


 Setting up archive ...
 Setting up plugins ...
 Running plugins. Please wait ...

  Starting 1/1   skydive         [Running: skydive]

  Finished running plugins

Creating compressed archive...

Your sosreport has been generated and saved in:
  /var/tmp/sosreport-localhost-2018-09-19-eadnxwl.tar.xz

The checksum is: 7d9a19dfa7787aa59574760b07c9ce6a

Please send this file to your support representative.

And:

# ./sosreport --batch --debug -o skydive -k skydive.username="qux",skydive.password="1passw0rd"

sosreport (version 3.6)

[...]

  Starting 1/1   skydive         [Running: skydive]

  Finished running plugins

Creating compressed archive...

Your sosreport has been generated and saved in:
  /var/tmp/sosreport-localhost-2018-09-19-wrksnus.tar.xz

The checksum is: c72ed77b0def1bc2f89afbbd494aae3b

Please send this file to your support representative.

(In reply to Bryn M. Reeves from comment #2)
> I think this is probably something we can address in a subsequent errata:
> what's happening here is that the plugin options code is "helpfully"
> noticing that the string passed in is an integer, and is automatically
> casting it to a Python 'int' type.

We have several plugin options (logs.log_days and pcp.pcplogs at least) that relies on this automatic conversion. While several other plugins (skydive, postgresql at least) are affected by this BZ.

Anyway each opt_parms has its default value in "enabled" field - should not we ensure set_option preserves this type, "only"?

Dirty patch for this:

--- a/sos/plugins/__init__.py
+++ b/sos/plugins/__init__.py
@@ -499,6 +499,9 @@ class Plugin(object):
         '''set the named option to value.'''
         for name, parms in zip(self.opt_names, self.opt_parms):
             if name == optionname:
+		defaulttype = type(parms['enabled'])
+		if defaulttype != type(value):
+		    value = (defaulttype)(value)
                 parms['enabled'] = value
                 return True
         else:

POSTed to upstream.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:2295