On my system the crypt module in python2 doesn't have mksalt() function.
However python3 does and the code is perfectly fine python3 code as well.  So
let's make it run in the default python version as that has the highest chance
to work.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
---
 guests/lcitool | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guests/lcitool b/guests/lcitool
index ccd0a597785a..24274d800742 100755
--- a/guests/lcitool
+++ b/guests/lcitool
@@ -18,7 +18,7 @@ die() {
 hash_file() {
     PASS_FILE="$1"
 
-    python2 -c "
+    python -c "
 import crypt
 password = open('$PASS_FILE', 'r').read().strip()
 print(crypt.crypt(password,
-- 
2.16.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, 2018-01-30 at 10:57 +0100, Martin Kletzander wrote:
> On my system the crypt module in python2 doesn't have mksalt() function.
> However python3 does and the code is perfectly fine python3 code as well.  So
> let's make it run in the default python version as that has the highest chance
> to work.
> 
> Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
> ---
>  guests/lcitool | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/guests/lcitool b/guests/lcitool
> index ccd0a597785a..24274d800742 100755
> --- a/guests/lcitool
> +++ b/guests/lcitool
> @@ -18,7 +18,7 @@ die() {
>  hash_file() {
>      PASS_FILE="$1"
>  
> -    python2 -c "
> +    python -c "
>  import crypt
>  password = open('$PASS_FILE', 'r').read().strip()
>  print(crypt.crypt(password,

Turns out the crypt.mksalt() function was introduced in Python 3
and backported to Python 2 in Fedora only, which would explain why
the script works on my machine but not yours.

I still don't like removing the Python version: as we discussed in
the past, "python" is widely considered an alias for "python2"
because attempts to switch "python" to "python3" at the OS level
have resulted in nothing but tears. You can still have that as a
local tweak on your system, of course, but I don't think it's
something we want to encourage.

A more reasonable approach would probably be to forfait Python 2
compatibility altogether and just s/2/3/ there. Several distros
already ship with only Python 3 installed by default, and if we
ever decide to rewrite lcitool to be more than a hacky shell
script, we will probably use Python 3 rather than 2 as well.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, Feb 07, 2018 at 02:32:34PM +0100, Andrea Bolognani wrote:
> On Tue, 2018-01-30 at 10:57 +0100, Martin Kletzander wrote:
> > On my system the crypt module in python2 doesn't have mksalt() function.
> > However python3 does and the code is perfectly fine python3 code as well.  So
> > let's make it run in the default python version as that has the highest chance
> > to work.
> > 
> > Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
> > ---
> >  guests/lcitool | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/guests/lcitool b/guests/lcitool
> > index ccd0a597785a..24274d800742 100755
> > --- a/guests/lcitool
> > +++ b/guests/lcitool
> > @@ -18,7 +18,7 @@ die() {
> >  hash_file() {
> >      PASS_FILE="$1"
> >  
> > -    python2 -c "
> > +    python -c "
> >  import crypt
> >  password = open('$PASS_FILE', 'r').read().strip()
> >  print(crypt.crypt(password,
> 
> Turns out the crypt.mksalt() function was introduced in Python 3
> and backported to Python 2 in Fedora only, which would explain why
> the script works on my machine but not yours.
> 
> I still don't like removing the Python version: as we discussed in
> the past, "python" is widely considered an alias for "python2"
> because attempts to switch "python" to "python3" at the OS level
> have resulted in nothing but tears. You can still have that as a
> local tweak on your system, of course, but I don't think it's
> something we want to encourage.
> 
> A more reasonable approach would probably be to forfait Python 2
> compatibility altogether and just s/2/3/ there. Several distros
> already ship with only Python 3 installed by default, and if we
> ever decide to rewrite lcitool to be more than a hacky shell
> script, we will probably use Python 3 rather than 2 as well.

Or can we just use openssl

$ openssl passwd -crypt hello
RtT4tOPU/wPnU


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Wed, 2018-02-07 at 13:37 +0000, Daniel P. Berrangé wrote:
> Or can we just use openssl
> 
> $ openssl passwd -crypt hello
> RtT4tOPU/wPnU

I'd love to avoid embedding a Python script in there[1], but it
doesn't look like openssl supports the same strong hashing
algorithm we're currently using, and I'm not sure modern guest OSs
would be happy with such a weak hash.

Another option would be to hard-code some pre-generated salt. I'm
not 100% clear of the security implications of doing something
like that though, to be honest.


[1] At least until the time we inevitably want to rewrite the tool
    itself in Python[2], that is.
[2] Unless we decide to pick Go instead, of course :)
-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list