← Back to team overview

sts-sponsors team mailing list archive

[Bug 1862226] Re: /usr/sbin/sss_obfuscate fails to run: ImportError: No module named pysss

 

** Description changed:

  [Impact]
  
  Current bionic d/control doesn't include "python3-sss" or "python-sss"
  as runtime dependency:
  
  Package: sssd-tools
  Architecture: any
  Depends:
   python,
   sssd-common (= ${binary:Version}),
   ${misc:Depends},
   ${shlibs:Depends}
  Description: System Security Services Daemon -- tools
   Provides a set of daemons to manage access to remote directories and
   authentication mechanisms. It provides an NSS and PAM interface toward
   the system and a pluggable backend system to connect to multiple different
   account sources. It is also the basis to provide client auditing and policy
   services for projects like FreeIPA.
  
  Current workaround:
  One can install the dependency by hand.
  
  [Test Case]
  
  # lsb_release -cs
  bionic
  
  # Install sssd-tools
  
  # sss_obfuscate
  Traceback (most recent call last):
    File "/usr/sbin/sss_obfuscate", line 8, in <module>
      import pysss
  ImportError: No module named pysss
  
  [Potential Regression]
  
- After adding the dependency, if one run let's say 'apt-get upgrade':
+ * After adding the dependency, if one run let's say 'apt-get upgrade':
  
  APT-GET(8) - upgrade:
  under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed.
  
  Meaning that one who would go that route, may not be able to get the
  update and will continue to experience the problem (No module named
  pysss)
  
  APT-GET(8) - dist-upgrade:
  dist-upgrade in addition to performing the function of upgrade, also intelligently handles changing dependencies with new versions of packages
+ 
+ * Since sss_obfuscate never work out of the box (without one installing
+ the missing dependency manually) ... first I don't expect a significant
+ adoption/use of this binary ... but since we are 'enabling'
+ sss_obfuscate to finally work out of the box ... who knows what bugs can
+ be found in sss_obfuscate that we didn't know before because it was
+ simply not used.
+ 
+ Clearly autopkgtest doesn't test that functionnality, otherwsie it would
+ have caught this before. Some dogfooding testing of sss_obfuscate in
+ -proposed may be useful to catch potential bugs related to its
+ "enablement".
+ 
+ Worst worst case, sss_obfuscate won't work as it currently does anyway,
+ and so far it didn't seems to be a major problem in the sssd ubuntu
+ community.
+ 
+ SSS_OBFUSCATE(8):
+ sss_obfuscate converts a given password into human-unreadable format and places it into appropriate domain section of the SSSD config file.
  
  [Other Infos]
  
  * Debian upstream:
  https://salsa.debian.org/sssd-team/sssd/commit/b41c0f81c6dcc672636220c46ed3d52f3b69ba7c
  
  * Debian Bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905220
  
  Rmadison:
  => sssd-tools | 1.16.1-1ubuntu1.4  | bionic-updates
     sssd-tools | 2.2.0-4ubuntu1     | eoan
     sssd-tools | 2.2.2-1            | focal
     sssd-tools | 2.2.2-1ubuntu1     | focal-proposed

** Description changed:

  [Impact]
  
  Current bionic d/control doesn't include "python3-sss" or "python-sss"
  as runtime dependency:
  
  Package: sssd-tools
  Architecture: any
  Depends:
   python,
   sssd-common (= ${binary:Version}),
   ${misc:Depends},
   ${shlibs:Depends}
  Description: System Security Services Daemon -- tools
   Provides a set of daemons to manage access to remote directories and
   authentication mechanisms. It provides an NSS and PAM interface toward
   the system and a pluggable backend system to connect to multiple different
   account sources. It is also the basis to provide client auditing and policy
   services for projects like FreeIPA.
  
  Current workaround:
  One can install the dependency by hand.
  
  [Test Case]
  
  # lsb_release -cs
  bionic
  
  # Install sssd-tools
  
  # sss_obfuscate
  Traceback (most recent call last):
    File "/usr/sbin/sss_obfuscate", line 8, in <module>
      import pysss
  ImportError: No module named pysss
  
  [Potential Regression]
  
  * After adding the dependency, if one run let's say 'apt-get upgrade':
  
  APT-GET(8) - upgrade:
  under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed.
  
  Meaning that one who would go that route, may not be able to get the
  update and will continue to experience the problem (No module named
  pysss)
  
  APT-GET(8) - dist-upgrade:
  dist-upgrade in addition to performing the function of upgrade, also intelligently handles changing dependencies with new versions of packages
  
  * Since sss_obfuscate never work out of the box (without one installing
  the missing dependency manually) ... first I don't expect a significant
  adoption/use of this binary ... but since we are 'enabling'
  sss_obfuscate to finally work out of the box ... who knows what bugs can
  be found in sss_obfuscate that we didn't know before because it was
  simply not used.
  
  Clearly autopkgtest doesn't test that functionnality, otherwsie it would
  have caught this before. Some dogfooding testing of sss_obfuscate in
  -proposed may be useful to catch potential bugs related to its
- "enablement".
+ "enablement". It should be trivial to test, the program does only one
+ thing:
  
- Worst worst case, sss_obfuscate won't work as it currently does anyway,
- and so far it didn't seems to be a major problem in the sssd ubuntu
- community.
  
  SSS_OBFUSCATE(8):
  sss_obfuscate converts a given password into human-unreadable format and places it into appropriate domain section of the SSSD config file.
+ 
+ * Worst worst case, sss_obfuscate still won't work as it currently does
+ anyway, and so far it didn't seems to be a major problem in the sssd
+ ubuntu community. But with the dogfooding testing we should be good to
+ catch any irregularity.
+ 
  
  [Other Infos]
  
  * Debian upstream:
  https://salsa.debian.org/sssd-team/sssd/commit/b41c0f81c6dcc672636220c46ed3d52f3b69ba7c
  
  * Debian Bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905220
  
  Rmadison:
  => sssd-tools | 1.16.1-1ubuntu1.4  | bionic-updates
     sssd-tools | 2.2.0-4ubuntu1     | eoan
     sssd-tools | 2.2.2-1            | focal
     sssd-tools | 2.2.2-1ubuntu1     | focal-proposed

** Description changed:

  [Impact]
  
  Current bionic d/control doesn't include "python3-sss" or "python-sss"
  as runtime dependency:
  
  Package: sssd-tools
  Architecture: any
  Depends:
   python,
   sssd-common (= ${binary:Version}),
   ${misc:Depends},
   ${shlibs:Depends}
  Description: System Security Services Daemon -- tools
   Provides a set of daemons to manage access to remote directories and
   authentication mechanisms. It provides an NSS and PAM interface toward
   the system and a pluggable backend system to connect to multiple different
   account sources. It is also the basis to provide client auditing and policy
   services for projects like FreeIPA.
  
  Current workaround:
  One can install the dependency by hand.
  
  [Test Case]
  
  # lsb_release -cs
  bionic
  
  # Install sssd-tools
  
  # sss_obfuscate
  Traceback (most recent call last):
    File "/usr/sbin/sss_obfuscate", line 8, in <module>
      import pysss
  ImportError: No module named pysss
  
  [Potential Regression]
  
  * After adding the dependency, if one run let's say 'apt-get upgrade':
  
  APT-GET(8) - upgrade:
  under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed.
  
  Meaning that one who would go that route, may not be able to get the
  update and will continue to experience the problem (No module named
  pysss)
  
  APT-GET(8) - dist-upgrade:
  dist-upgrade in addition to performing the function of upgrade, also intelligently handles changing dependencies with new versions of packages
  
  * Since sss_obfuscate never work out of the box (without one installing
  the missing dependency manually) ... first I don't expect a significant
  adoption/use of this binary ... but since we are 'enabling'
  sss_obfuscate to finally work out of the box ... who knows what bugs can
  be found in sss_obfuscate that we didn't know before because it was
  simply not used.
  
  Clearly autopkgtest doesn't test that functionnality, otherwsie it would
  have caught this before. Some dogfooding testing of sss_obfuscate in
  -proposed may be useful to catch potential bugs related to its
  "enablement". It should be trivial to test, the program does only one
  thing:
  
- 
  SSS_OBFUSCATE(8):
  sss_obfuscate converts a given password into human-unreadable format and places it into appropriate domain section of the SSSD config file.
+ 
+ http://manpages.ubuntu.com/manpages/bionic/en/man8/sss_obfuscate.8.html
  
  * Worst worst case, sss_obfuscate still won't work as it currently does
  anyway, and so far it didn't seems to be a major problem in the sssd
  ubuntu community. But with the dogfooding testing we should be good to
  catch any irregularity.
- 
  
  [Other Infos]
  
  * Debian upstream:
  https://salsa.debian.org/sssd-team/sssd/commit/b41c0f81c6dcc672636220c46ed3d52f3b69ba7c
  
  * Debian Bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905220
  
  Rmadison:
  => sssd-tools | 1.16.1-1ubuntu1.4  | bionic-updates
     sssd-tools | 2.2.0-4ubuntu1     | eoan
     sssd-tools | 2.2.2-1            | focal
     sssd-tools | 2.2.2-1ubuntu1     | focal-proposed

** Description changed:

  [Impact]
  
  Current bionic d/control doesn't include "python3-sss" or "python-sss"
  as runtime dependency:
  
  Package: sssd-tools
  Architecture: any
  Depends:
   python,
   sssd-common (= ${binary:Version}),
   ${misc:Depends},
   ${shlibs:Depends}
  Description: System Security Services Daemon -- tools
   Provides a set of daemons to manage access to remote directories and
   authentication mechanisms. It provides an NSS and PAM interface toward
   the system and a pluggable backend system to connect to multiple different
   account sources. It is also the basis to provide client auditing and policy
   services for projects like FreeIPA.
  
  Current workaround:
  One can install the dependency by hand.
  
  [Test Case]
  
  # lsb_release -cs
  bionic
  
  # Install sssd-tools
  
  # sss_obfuscate
  Traceback (most recent call last):
    File "/usr/sbin/sss_obfuscate", line 8, in <module>
      import pysss
  ImportError: No module named pysss
  
  [Potential Regression]
  
  * After adding the dependency, if one run let's say 'apt-get upgrade':
  
  APT-GET(8) - upgrade:
  under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed.
  
  Meaning that one who would go that route, may not be able to get the
  update and will continue to experience the problem (No module named
  pysss)
  
  APT-GET(8) - dist-upgrade:
  dist-upgrade in addition to performing the function of upgrade, also intelligently handles changing dependencies with new versions of packages
  
  * Since sss_obfuscate never work out of the box (without one installing
  the missing dependency manually) ... first I don't expect a significant
- adoption/use of this binary ... but since we are 'enabling'
- sss_obfuscate to finally work out of the box ... who knows what bugs can
- be found in sss_obfuscate that we didn't know before because it was
- simply not used.
+ adoption/use of this binary, since it took years for one to discover it
+ ... but since we are 'enabling' sss_obfuscate to finally work out of the
+ box ... who knows what bugs can be found in sss_obfuscate that we didn't
+ know before because it was simply not used.
  
  Clearly autopkgtest doesn't test that functionnality, otherwsie it would
  have caught this before. Some dogfooding testing of sss_obfuscate in
  -proposed may be useful to catch potential bugs related to its
  "enablement". It should be trivial to test, the program does only one
  thing:
  
  SSS_OBFUSCATE(8):
  sss_obfuscate converts a given password into human-unreadable format and places it into appropriate domain section of the SSSD config file.
  
  http://manpages.ubuntu.com/manpages/bionic/en/man8/sss_obfuscate.8.html
  
  * Worst worst case, sss_obfuscate still won't work as it currently does
  anyway, and so far it didn't seems to be a major problem in the sssd
  ubuntu community. But with the dogfooding testing we should be good to
  catch any irregularity.
  
  [Other Infos]
  
  * Debian upstream:
  https://salsa.debian.org/sssd-team/sssd/commit/b41c0f81c6dcc672636220c46ed3d52f3b69ba7c
  
  * Debian Bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905220
  
  Rmadison:
  => sssd-tools | 1.16.1-1ubuntu1.4  | bionic-updates
     sssd-tools | 2.2.0-4ubuntu1     | eoan
     sssd-tools | 2.2.2-1            | focal
     sssd-tools | 2.2.2-1ubuntu1     | focal-proposed

** Description changed:

  [Impact]
  
  Current bionic d/control doesn't include "python3-sss" or "python-sss"
  as runtime dependency:
  
  Package: sssd-tools
  Architecture: any
  Depends:
   python,
   sssd-common (= ${binary:Version}),
   ${misc:Depends},
   ${shlibs:Depends}
  Description: System Security Services Daemon -- tools
   Provides a set of daemons to manage access to remote directories and
   authentication mechanisms. It provides an NSS and PAM interface toward
   the system and a pluggable backend system to connect to multiple different
   account sources. It is also the basis to provide client auditing and policy
   services for projects like FreeIPA.
  
  Current workaround:
  One can install the dependency by hand.
  
  [Test Case]
  
  # lsb_release -cs
  bionic
  
  # Install sssd-tools
  
  # sss_obfuscate
  Traceback (most recent call last):
    File "/usr/sbin/sss_obfuscate", line 8, in <module>
      import pysss
  ImportError: No module named pysss
  
  [Potential Regression]
  
  * After adding the dependency, if one run let's say 'apt-get upgrade':
  
  APT-GET(8) - upgrade:
  under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed.
  
  Meaning that one who would go that route, may not be able to get the
  update and will continue to experience the problem (No module named
  pysss)
  
  APT-GET(8) - dist-upgrade:
  dist-upgrade in addition to performing the function of upgrade, also intelligently handles changing dependencies with new versions of packages
  
  * Since sss_obfuscate never work out of the box (without one installing
  the missing dependency manually) ... first I don't expect a significant
  adoption/use of this binary, since it took years for one to discover it
  ... but since we are 'enabling' sss_obfuscate to finally work out of the
  box ... who knows what bugs can be found in sss_obfuscate that we didn't
  know before because it was simply not used.
  
  Clearly autopkgtest doesn't test that functionnality, otherwsie it would
  have caught this before. Some dogfooding testing of sss_obfuscate in
  -proposed may be useful to catch potential bugs related to its
  "enablement". It should be trivial to test, the program does only one
  thing:
  
  SSS_OBFUSCATE(8):
  sss_obfuscate converts a given password into human-unreadable format and places it into appropriate domain section of the SSSD config file.
  
  http://manpages.ubuntu.com/manpages/bionic/en/man8/sss_obfuscate.8.html
  
  * Worst worst case, sss_obfuscate still won't work as it currently does
  anyway, and so far it didn't seems to be a major problem in the sssd
  ubuntu community. But with the dogfooding testing we should be good to
- catch any irregularity.
+ catch any obvious irregularity.
  
  [Other Infos]
  
  * Debian upstream:
  https://salsa.debian.org/sssd-team/sssd/commit/b41c0f81c6dcc672636220c46ed3d52f3b69ba7c
  
  * Debian Bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905220
  
  Rmadison:
  => sssd-tools | 1.16.1-1ubuntu1.4  | bionic-updates
     sssd-tools | 2.2.0-4ubuntu1     | eoan
     sssd-tools | 2.2.2-1            | focal
     sssd-tools | 2.2.2-1ubuntu1     | focal-proposed

** Description changed:

  [Impact]
  
  Current bionic d/control doesn't include "python3-sss" or "python-sss"
  as runtime dependency:
  
  Package: sssd-tools
  Architecture: any
  Depends:
   python,
   sssd-common (= ${binary:Version}),
   ${misc:Depends},
   ${shlibs:Depends}
  Description: System Security Services Daemon -- tools
   Provides a set of daemons to manage access to remote directories and
   authentication mechanisms. It provides an NSS and PAM interface toward
   the system and a pluggable backend system to connect to multiple different
   account sources. It is also the basis to provide client auditing and policy
   services for projects like FreeIPA.
  
  Current workaround:
  One can install the dependency by hand.
  
  [Test Case]
  
  # lsb_release -cs
  bionic
  
  # Install sssd-tools
  
  # sss_obfuscate
  Traceback (most recent call last):
    File "/usr/sbin/sss_obfuscate", line 8, in <module>
      import pysss
  ImportError: No module named pysss
  
  [Potential Regression]
  
  * After adding the dependency, if one run let's say 'apt-get upgrade':
  
  APT-GET(8) - upgrade:
  under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed.
  
  Meaning that one who would go that route, may not be able to get the
  update and will continue to experience the problem (No module named
  pysss)
  
  APT-GET(8) - dist-upgrade:
  dist-upgrade in addition to performing the function of upgrade, also intelligently handles changing dependencies with new versions of packages
  
  * Since sss_obfuscate never work out of the box (without one installing
  the missing dependency manually) ... first I don't expect a significant
  adoption/use of this binary, since it took years for one to discover it
  ... but since we are 'enabling' sss_obfuscate to finally work out of the
  box ... who knows what bugs can be found in sss_obfuscate that we didn't
  know before because it was simply not used.
  
  Clearly autopkgtest doesn't test that functionnality, otherwsie it would
  have caught this before. Some dogfooding testing of sss_obfuscate in
  -proposed may be useful to catch potential bugs related to its
  "enablement". It should be trivial to test, the program does only one
  thing:
  
  SSS_OBFUSCATE(8):
  sss_obfuscate converts a given password into human-unreadable format and places it into appropriate domain section of the SSSD config file.
  
  http://manpages.ubuntu.com/manpages/bionic/en/man8/sss_obfuscate.8.html
  
  * Worst worst case, sss_obfuscate still won't work as it currently does
  anyway, and so far it didn't seems to be a major problem in the sssd
  ubuntu community. But with the dogfooding testing we should be good to
  catch any obvious irregularity.
  
+ It should be fine since disco uses the same upstream version and has the
+ right dependendy, so sssd-tools in Bionic and Disco are very code alike.
+ 
  [Other Infos]
  
  * Debian upstream:
  https://salsa.debian.org/sssd-team/sssd/commit/b41c0f81c6dcc672636220c46ed3d52f3b69ba7c
  
  * Debian Bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905220
  
  Rmadison:
  => sssd-tools | 1.16.1-1ubuntu1.4  | bionic-updates
     sssd-tools | 2.2.0-4ubuntu1     | eoan
     sssd-tools | 2.2.2-1            | focal
     sssd-tools | 2.2.2-1ubuntu1     | focal-proposed

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1862226

Title:
  /usr/sbin/sss_obfuscate fails to run: ImportError: No module named
  pysss

Status in sssd package in Ubuntu:
  Fix Released
Status in sssd source package in Bionic:
  In Progress
Status in sssd source package in Eoan:
  Fix Released
Status in sssd package in Debian:
  Fix Released

Bug description:
  [Impact]

  Current bionic d/control doesn't include "python3-sss" or "python-sss"
  as runtime dependency:

  Package: sssd-tools
  Architecture: any
  Depends:
   python,
   sssd-common (= ${binary:Version}),
   ${misc:Depends},
   ${shlibs:Depends}
  Description: System Security Services Daemon -- tools
   Provides a set of daemons to manage access to remote directories and
   authentication mechanisms. It provides an NSS and PAM interface toward
   the system and a pluggable backend system to connect to multiple different
   account sources. It is also the basis to provide client auditing and policy
   services for projects like FreeIPA.

  Current workaround:
  One can install the dependency by hand.

  [Test Case]

  # lsb_release -cs
  bionic

  # Install sssd-tools

  # sss_obfuscate
  Traceback (most recent call last):
    File "/usr/sbin/sss_obfuscate", line 8, in <module>
      import pysss
  ImportError: No module named pysss

  [Potential Regression]

  * After adding the dependency, if one run let's say 'apt-get upgrade':

  APT-GET(8) - upgrade:
  under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed.

  Meaning that one who would go that route, may not be able to get the
  update and will continue to experience the problem (No module named
  pysss)

  APT-GET(8) - dist-upgrade:
  dist-upgrade in addition to performing the function of upgrade, also intelligently handles changing dependencies with new versions of packages

  * Since sss_obfuscate never work out of the box (without one
  installing the missing dependency manually) ... first I don't expect a
  significant adoption/use of this binary, since it took years for one
  to discover it ... but since we are 'enabling' sss_obfuscate to
  finally work out of the box ... who knows what bugs can be found in
  sss_obfuscate that we didn't know before because it was simply not
  used.

  Clearly autopkgtest doesn't test that functionnality, otherwsie it
  would have caught this before. Some dogfooding testing of
  sss_obfuscate in -proposed may be useful to catch potential bugs
  related to its "enablement". It should be trivial to test, the program
  does only one thing:

  SSS_OBFUSCATE(8):
  sss_obfuscate converts a given password into human-unreadable format and places it into appropriate domain section of the SSSD config file.

  http://manpages.ubuntu.com/manpages/bionic/en/man8/sss_obfuscate.8.html

  * Worst worst case, sss_obfuscate still won't work as it currently
  does anyway, and so far it didn't seems to be a major problem in the
  sssd ubuntu community. But with the dogfooding testing we should be
  good to catch any obvious irregularity.

  It should be fine since disco uses the same upstream version and has
  the right dependendy, so sssd-tools in Bionic and Disco are very code
  alike.

  [Other Infos]

  * Debian upstream:
  https://salsa.debian.org/sssd-team/sssd/commit/b41c0f81c6dcc672636220c46ed3d52f3b69ba7c

  * Debian Bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905220

  Rmadison:
  => sssd-tools | 1.16.1-1ubuntu1.4  | bionic-updates
     sssd-tools | 2.2.0-4ubuntu1     | eoan
     sssd-tools | 2.2.2-1            | focal
     sssd-tools | 2.2.2-1ubuntu1     | focal-proposed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1862226/+subscriptions