Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Hi Diederik,

You're probably right that it deserves a separate bug, but I was trying
to avoid wasting the translators time by doing this in two steps, and
forcing them to do the work twice.

I cannot say that I have read the stuff in these dialogs (except when
editing them) for at least 20 years, so tailoring the content of them
for people like me seems like a mistake. I was therefore trying to put
myself in the position of a person that's reading them for the first
time, and perhaps a person that's installing Linux for the first time.

Having helped people to install Linux for ~30 years, I'd say that it's
the norm for people to be almost incapable of coming up with a decent
password if they were not expecting the question.

As I said, I'm happy to hear better suggestions, since I've had about 15
attempts at this so far, and every time I see the text rendered in the
D-I screenshot, I end up not liking the result very much.

If you want to make a constructive contribution, how about suggesting a
wording that reflects the advice that you think would be most useful to
the people that actually read the advice?

If nothing like a consensus is available, then just removing the old
advice seems like an OK place to end up too, which is why I went to the
effort of splitting the commits.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

Bug#1064617: Passwords should not be changed frequently

[Diederik de Haas]

On Thursday, 29 February 2024 23:13:55 CET Holger Wansing wrote:
> > in which I'm recommending setting no password for root, which then gives
> > the initial user 'sudo' membership[1].
> 
> What about the "Allow login as root?" question (only shown in expert mode),
> which is asked directly before the above mentioned dialog?

I very much support the suggestion from the (initial) bug report:
removing bad advice

But this is changing the subject in fundamental ways, which should be 
discussed in a separate bug report with an appropriate title.

1) Suddenly we assume that the user is incapable of coming up with a good 
password for root? Where is that based upon?
2) If they're incapable of coming up with a good password for root, then 
they're incapable of given their normal account, with sudo privileges, a 
decent password too, right?
3) Default behavior now becomes *not* creating a root account? If we divert 
from a years/decades long default, there needs to be good reasons for it IMO.

Defaults matter and I'm not happy that so much things get put into expert mode 
or (only) made available via preseed, just because we're worried it may 
confuse users (or we think they're idiots, which is way worse). 

"This 'users are idiots, and are confused by functionality' mentality of Gnome 
is a disease. If you think your users are idiots, only idiots will use it."

My 0.02

signature.asc
Description: This is a digitally signed message part.

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Philip Hands  wrote (Thu, 29 Feb 2024 20:53:10 +0100):
> Depending upon whether we think it's worth using translators' time on
> this subject, we can then select one or both commits, and finally close
> these bugs.

I think it would be worth it to generate some work for translators here, yes.

> You can see my latest attempt here:
> 
>   https://openqa.debian.net/tests/238094#step/passwords/1
> 
> in which I'm recommending setting no password for root, which then gives
> the initial user 'sudo' membership[1].

What about the "Allow login as root?" question (only shown in expert mode),
which is asked directly before the above mentioned dialog?
(That's in user-setup-udeb.templates - line 25 ff.)

Maybe that needs some re-wording too?

Seems somewhat inconsistent now IMO:
if you say 'Yes' to 'Allow login as root' you get the next dialog allowing
the same choice again (or at least very similar): 
'It is possible [...] to lock the root acount ... If you leave the password
here unset, then this is what happens.'

Is that understandable for users?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1065048: installation-reports: partition tool in d-i remembers choices; 'delete partition' (encrypted Part.) always stays 'yes'

[Pascal Hambourg]

On 29/02/2024 at 08:51, Frank Weißer wrote:


Comments/Problems: 2nd NIC gets eth0 on reboot, 2nd NIC gets eth1 :-(


eth* names are no persistent and may change at any boot.
But ethernet interface should get predictable names like enpXsY or enoX.
In /proc/interrupts we can see enp1s0.


randomized encrypted partitions default to 'delete partition' 'yes';
after choosing 'no' the first time it should default to 'no'


By "randomized" do you mean "plain dm-crypt with random key" ?


The only choice of extended filesystems to format the randomized
encrypted partition with is ext2, which the d-i writes to /etc/fstab.
But the d-i actually formats to ext4, so I end up in emergency mode on
reboot

the d-i also misses to write the 'tmp' parameter for the randomized
encrypted ext4 formatted partition in /etc/crypttab


These two remind me of Bug#995108 ("d-i: partman-crypto: plain dm-crypt 
device management issues").



I had submitted a patch but received no feedback so far.

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Pascal Hambourg  writes:

> On 25/02/2024 at 01:17, Matthew Wilcox wrote:
>> 
>> I just did an installation with the 2024-02-24
>> debian-testing-amd64-netinst.iso image.  I forget the exact wording
>> used, but when setting up a user, d-i printed advice that user passwords
>> should be changed frequently.  This is no longer current good advice
>> (since 2017):
>
> This topic has some history, see
> 
> 
> 
> 

It had not occured to me until Matthew's suggestion that we might simply
remove the obsolete advice, rather than trying to improve the wording.

In light of that, I've split the MR into 2 commits, the first of which
removes the old advice (which hopefully inflicts the smallest possible
load on our translators) and the second of which is an attempt to come
up with something better (criticism welcome, I've had multiple attempts
at this, so I imagine there's still room for improvement).

Depending upon whether we think it's worth using translators' time on
this subject, we can then select one or both commits, and finally close
these bugs.

You can see my latest attempt here:

  https://openqa.debian.net/tests/238094#step/passwords/1

in which I'm recommending setting no password for root, which then gives
the initial user 'sudo' membership[1].

The slightly awkward thing about this recommendation is that it
encourages people to put themselves in the situation that:

  https://salsa.debian.org/installer-team/user-setup/-/merge_requests/6

is trying to address, so if we make this recommendation, we should also
deal with that issue (which I think we should do anyway).

Cheers, Phil.

[1] This strikes me as decent advice for newbies, for whom this sort of
guidance is most necessary. The problem with asking a newbie for a
root password is that they're likely to choose a poor one. Even if
they later realise that they should have choosen better passwords,
they may well not at that point remember that they still have a
useless password for root that needs updating.

On the other hand, now that ssh defaults to not allowing password
based logins to root, perhaps the potential presence of a poor
password on a sudo enabled account should be of greater concern,
since that will still be open to remote logins, so I can see that
one could argue this either way.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Processed: Re: Bug#1065033: debootstrap: Fails for *sid* with `cannot move /lib/x86_64-linux-gnu/libpam.so.0 as its destination exists as a symlink`

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 1065033 src:pam
Bug #1065033 [debootstrap] debootstrap: Fails for *sid* with `cannot move 
/lib/x86_64-linux-gnu/libpam.so.0 as its destination exists as a symlink`
Bug reassigned from package 'debootstrap' to 'src:pam'.
No longer marked as found in versions debootstrap/1.0.134.
Ignoring request to alter fixed versions of bug #1065033 to the same values 
previously set
> forcemerge 1065011 1065033
Bug #1065011 [src:pam] libpam0t64 competes for libpam.so.0 symlink against 
libpam0g (breaks debootstrap)
Bug #1065033 [src:pam] debootstrap: Fails for *sid* with `cannot move 
/lib/x86_64-linux-gnu/libpam.so.0 as its destination exists as a symlink`
Severity set to 'serious' from 'normal'
Marked as found in versions pam/1.5.3-4.
Merged 1065011 1065033
> affects 1065033 debootstrap
Bug #1065033 [src:pam] debootstrap: Fails for *sid* with `cannot move 
/lib/x86_64-linux-gnu/libpam.so.0 as its destination exists as a symlink`
Bug #1065011 [src:pam] libpam0t64 competes for libpam.so.0 symlink against 
libpam0g (breaks debootstrap)
Added indication that 1065033 affects debootstrap
Added indication that 1065011 affects debootstrap
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1065011: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065011
1065033: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065033
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1065048: installation-reports: partition tool in d-i remembers choices; 'delete partition' (encrypted Part.) always stays 'yes'

[Frank Weißer]

Package: installation-reports
Severity: wishlist

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: 
http://get.debian.org/cdimage/release/current/amd64/iso-bd/debian-edu-12.5.0-amd64-BD-1.iso
 2024-02-10 14:48
http://get.debian.org/cdimage/release/current/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso
http://get.debian.org/cdimage/release/current/amd64/iso-cd/debian-edu-12.5.0-amd64-netinst.iso
http://get.debian.org/cdimage/archive/11.0.0/i386/iso-cd/debian-11.0.0-i386-netinst.iso
and others too
Date: <2024-02-24 15:20>

Machine: Fujitsu Esprimo C710 Intel Core i3-2100T CPU @ 2.50GHz 32GB RAM 120GB 
SSD 4TB HDD
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [0]
Detect network card:[0]
Configure network:  [E]
Detect media:   [0]
Load installer modules: [0]
Clock/timezone setup:   [0]
User/password setup:[0]
Detect hard drives: [0]
Partition hard drives:  [E]
Install base system:[0]
Install tasks:  [0]
Install boot loader:[0]
Overall install:[0]

Comments/Problems: 2nd NIC gets eth0 on reboot, 2nd NIC gets eth1 :-(

randomized encrypted partitions default to 'delete partition' 'yes';
after choosing 'no' the first time it should default to 'no'

The only choice of extended filesystems to format the randomized
encrypted partition with is ext2, which the d-i writes to /etc/fstab.
But the d-i actually formats to ext4, so I end up in emergency mode on
reboot

the d-i also misses to write the 'tmp' parameter for the randomized
encrypted ext4 formatted partition in /etc/crypttab




Please make sure that any installation logs that you think would
be useful are attached to this report. (You can find them in the
installer system in /var/log/ and later on the installed system
under /var/log/installer.) Please compress large files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==

==
Installer hardware-summary:
==
uname -a: Linux tjener.intern 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.76-1 (2024-02-01) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core 
Processor Family DRAM Controller [8086:0100] (rev 09)
lspci -knn: DeviceName:  PCH Q75
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11b9]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd 
Generation Core Processor Family PCI Express Root Port [8086:0101] (rev 09)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11b9]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd 
Generation Core Processor Family Integrated Graphics Controller [8086:0102] 
(rev 09)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11b9]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 
Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11d6]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 7 
Series/C216 Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11d6]
lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation 82579V 
Gigabit Network Connection [8086:1503] (rev 04)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11d9]
lspci -knn: Kernel driver in use: e1000e
lspci -knn: Kernel modules: e1000e
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C216 
Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11d6]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 
Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11d8]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C216 
Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
lspci -knn: Subsystem: Fujitsu Technology Solutions Device [1734:11d6]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge 
[8086:244e] (rev a4)