Re: [PATCH] Revert "debian: Allow empty passwords"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 19, 2016 at 6:41 PM, Zeeshan Ali (Khattak)
<zeeshanak@xxxxxxxxx> wrote:
> Hi,
>
> On Thu, May 19, 2016 at 2:32 PM, Fabiano Fidêncio <fidencio@xxxxxxxxxx> wrote:
>> On Thu, May 19, 2016 at 2:40 PM, Zeeshan Ali (Khattak)
>> <zeeshanak@xxxxxxxxx> wrote:
>>> On Thu, May 19, 2016 at 7:24 AM, Fabiano Fidêncio <fidencio@xxxxxxxxxx> wrote:
>>>> The workaround that has been used so for doesn't work.
>>>>
>>>> For the user account, the password is indeed removed in the end of the
>>>> installation, but then login in from GDM is impossible. Although it
>>>> works from a VT,
>>>
>>> You mean after you logout and then get dropped to GDM? Which would
>>> explain why it's hard to notice. If that's the case, are you sure we
>>> don't have the same issue with Fedora?
>>
>> The issue is, the system is installed, reboots and then you're at GDM
>> screen. There you simply can _not_ login.
>
> Ah ok but then it affects all users and I'm a bit confused what you
> meant by the following sentence to this: "this is not something
> obvious that every user would try."

If you switch to VT you can log in without a password. And switching
to VT is not something obvious that every user would try.

>
>> I don't know if it affects Fedora, I didn't test Fedora and not sure
>> when I'll have time for that. maybe it's broken there as well.
>
> I doubt it, if it's so badly broken.
>
>>>>this is not something obvious that every user would
>>>> try. So, requiring the user password seems the best to do for now and
>>>> when another workaround is found the user password can be set to
>>>> optional again.
>>>
>>> Hmm.. Boxes might not be taking into account scripts requiring password.
>>
>> Well, that's something to be fixed on Boxes, not on libosinfo.
>
> Of course, I was just reminding. :)
>
>>>> For the root account, the password is not removed in the of the
>>>> installation and ends up being set as "dummyPa55w0rd", something that
>>>> the user would never guess, unless they have access to the libosinfo
>>>> code. So, requiring the admin password seems the best to do for now and
>>>> when another workaround is found the admin password can be set to
>>>> optional again.
>>>
>>> I think the most important thing is to find out why the workaround is
>>> not working. Could it be that it used to work but broken in recently
>>> debian versions?
>>
>> I also don't know if it used to work before.
>
> Well it's pretty unlikely that Lasse would have marked a workaround as
> "working" without testing it. I'm not sure if I tested this exactly
> but I did some testing of Debian then.

Well, it doesn't work at all with Debian 7, which is the first Debian
with desktop installer profile.
So, yes, I doubt it was ever tested before.

Now that we know it never worked, can I get your ACK and revert the patch?
That's the safest option we have.

>
>> You acked this patch, can
>> you tell me in which version of Debian you have tested it?
>
> That was 2 years ago so no, I can't. I'll bet on the latest stable
> debian release at the time.
>
> --
> Regards,
>
> Zeeshan Ali (Khattak)

_______________________________________________
Libosinfo mailing list
Libosinfo@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libosinfo




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Fedora Users]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux