Bug#1064617: Passwords should not be changed frequently

[Justin B Rye]

Philip Hands wrote:
>> Maybe instead of saying "use the system's initial user account to
>> become root" it should say "allow the system's initial user account
>> to gain administrative privileges"?  I'm not sure.  Oh, and we might
>> even want to mention the word "superuser", or then again we might not.
> 
> I think Diederik's suggestion of using 'root' for the account and
> 'super-user' for the privileges might be the way to go.

Looking at what I end up with after another couple of rounds of
fiddling with it I'm not sure if it's doing quite what you asked for,
but you still might want it so here it is:

-   Some account needs to have system administrative privileges. The
-   password/passphrase for that account should be something that
-   cannot be guessed.
+   Some account needs to be available with administrative super-user
+   privileges. The password/passphrase for that account should be
+   something that cannot be guessed.
.
To allow direct password-based access via the 'root' account, you
can set the password/passphrase for that account here.
.
-   Alternatively, you can lock root's password
+   Alternatively, you can lock the root account's password
by leaving this setting empty, and
instead use the system's initial user account
(which will be set up in the next step)
-   to become root. This will be enabled for you
-   by adding that user to the 'sudo' group.
+   to gain administrative privileges. This will be enabled for you by
+   adding that initial user to the 'sudo' group.
.
Note: what you type here will be hidden (unless you select to show it).

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1065592: partman-efi: add build support for loongarch64

[zhangdandan]

Source: partman-efi
Version: 103
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

The partman-efi source package lacks LoongArch architecture support.
We need to add build support for loongarch64 in d/control.

Please consider the patch I have attached.
The partman-efi source package was compiled successfully on my local 
loong64 rootfs environment.

If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

diff -Nru partman-efi-103/debian/control partman-efi-103/debian/control
--- partman-efi-103/debian/control  2024-01-06 21:33:46.0 +
+++ partman-efi-103/debian/control  2024-01-06 21:49:11.0 +
@@ -9,6 +9,6 @@
 
 Package: partman-efi
 Package-Type: udeb
-Architecture: i386 ia64 amd64 arm64 armhf riscv64
+Architecture: i386 ia64 amd64 arm64 armhf riscv64 loong64
 Depends: partman-base, efi-modules, dosfstools-udeb, ${misc:Depends}
 Description: Add to partman support for EFI System Partitions

Bug#1065570: Interface border is replaced by ascii chars

[x11r]

Sorry, I don't mean to make you chase information. The only other difference is 
our pxelinux.cfg. We are using a minimal pxelinux in order to bypass the 
interactive menus with the following content.

default linux
label linux
  kernel debian-installer/amd64/linux
  append initrd=debian-installer/amd64/initrd.gz ip=dhcp auto=enable 
language=en country=US locale=en_US.UTF-8 keymap=ansi hostname=debian domain="" 
url=tftp://10.0.0.1/preseed.cfg

I attempted a minimal repro using a command similar to yours but using 
"qemu-system-x86_64 -enable-kvm" (because I can't seem to find the package that 
has the kvm bin) and did not get the bug. I know it's not isolated to 
VirtualBox because I have video of the bug happening on a bare metal install 
(https://youtu.be/-OiJVJp8SxQ bug occurs at about 1:05).

After some digging, I saw that the original netboot.tar.gz had pxelinux.cfg 
symlinked to debian-installer/amd64/pxelinux.cfg which has a default file 
symlinked to ../boot-screens/syslinux.cfg (realpath 
debian-installer/amd64/boot-screens/syslinux.cfg). The QEMU reproduction I 
tried I edited that file directly, whereas the other tests I've done a script 
has replaced it pxelinux.cfg/default with a new file (removing the symlink 
entirely). I modified our script-generated tftp directory (for VirtualBox) to 
fix the symlink (putting the above contents into the 
debian-installer/amd64/boot-screens/syslinux.cfg file directly) and that didn't 
fix the issue (I thought I was onto something).

I reset the TFTP dir to just the preseed.cfg (so not our pxelinux.cfg) and 
input the kernel parameters in the default menu. One thing I noticed was the 
default parameters include VGA=788 (which our menu above was missing). This 
appears to have fixed the issue. I ran the QEMU test mentioned earlier using 
the pxelinux.cfg above, but qualitatively it looked like it was running in a 
different graphical mode. With this information, I think this may be related to 
the absence of the "VGA=" parameter in our boot parameters. I see there's an 
existing bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969944 regarding 
the same parameter, but I don't see enough information there to say it's the 
same issue.

That's all the relevant information I can think of for now. Maybe see if your 
KVM is able to reproduce using the pxelinux.cfg above or removing the "VGA=788" 
parameter from the kernel command line? 

On Wednesday, March 6th, 2024 at 6:57 PM, Samuel Thibault 
 wrote:

> Hello,
> 
> x11r, le mer. 06 mars 2024 23:29:24 +, a ecrit:
> 
> > The mangling does not happen immediately. It happens after the "Installing 
> > the base system" step (not sure what the step after that is supposed to 
> > be). Here's a pastebin of the preseed.cfg: https://pastebin.com/K7vwkpMu
> 
> 
> I still cannot reproduce with:
> 
> mkdir tmp
> cd tmp
> wget 
> https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/netboot.tar.gz
> tar xf netboot.tar.gz
> wget -O preseed.cfg https://pastebin.com/raw/K7vwkpMu
> dd < /dev/zero > disk.img bs=1M count=1 seek=1
> 
> kvm -net nic -net user,tftp=$PWD,bootfile=pxelinux.0 -drive 
> file=disk.img,cache=unsafe -m 1G
> 
> and appending
> 
> ip=dhcp auto=enable language=en country=US locale=en_US.UTF-8 keymap=ansi 
> hostname=debian domain="" url=tftp://10.0.2.2/preseed.cfg
> 
> on the boot kernel command line. It does show up fine up to the reboot
> step.
> 
> Any idea what is different with your case? (except the virtualization
> software)
> 
> Samuel

Bug#1065570: Interface border is replaced by ascii chars

[Samuel Thibault]

Hello,

x11r, le mer. 06 mars 2024 23:29:24 +, a ecrit:
> The mangling does not happen immediately. It happens after the "Installing 
> the base system" step (not sure what the step after that is supposed to be). 
> Here's a pastebin of the preseed.cfg: https://pastebin.com/K7vwkpMu

I still cannot reproduce with:

mkdir tmp
cd tmp
wget  
https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/netboot.tar.gz
tar xf netboot.tar.gz
wget -O preseed.cfg https://pastebin.com/raw/K7vwkpMu
dd < /dev/zero > disk.img bs=1M count=1 seek=1
kvm -net nic -net user,tftp=$PWD,bootfile=pxelinux.0 -drive 
file=disk.img,cache=unsafe -m 1G

and appending

ip=dhcp auto=enable language=en country=US locale=en_US.UTF-8 keymap=ansi 
hostname=debian domain="" url=tftp://10.0.2.2/preseed.cfg

on the boot kernel command line. It does show up fine up to the reboot
step.

Any idea what is different with your case? (except the virtualization
software)

Samuel

Bug#1065570: Interface border is replaced by ascii chars

[x11r]

The mangling does not happen immediately. It happens after the "Installing the 
base system" step (not sure what the step after that is supposed to be). Here's 
a pastebin of the preseed.cfg: https://pastebin.com/K7vwkpMu

On Wednesday, March 6th, 2024 at 6:06 PM, Samuel Thibault 
 wrote:

> Hello,
>
> x11r, le mer. 06 mars 2024 22:39:23 +, a ecrit:
>
> > The machine is PXE booted with the kernel parameters: 
> > initrd=debian-installer/amd64/initrd.gz ip=dhcp auto=enable language=en 
> > country=US locale=en_US.UTF-8 keymap=ansi hostname=debian domain="" 
> > url=tftp://10.0.0.1/preseed.cfg
> >
> > Console is accessed over VGA. VMSVGA for the VirtualBox tests we've ran and 
> > a VGA KVM for the tests on bare metal.
>
>
> I still cannot reproduce with unpacking the tarball and running
>
> kvm -net nic -net user,tftp=$PWD,bootfile=pxelinux.0 -drive -m 1G
>
> and passing the kernel parameters.
>
> Does the mangling happen right from the first screen, or after some
> steps?
>
> It could be useful to share your preseed.cfg (take care of removing any
> hardcoded password).
>
> Samuel

Bug#1065570: Interface border is replaced by ascii chars

[Samuel Thibault]

Hello,

x11r, le mer. 06 mars 2024 22:39:23 +, a ecrit:
> The machine is PXE booted with the kernel parameters: 
> initrd=debian-installer/amd64/initrd.gz ip=dhcp auto=enable language=en 
> country=US locale=en_US.UTF-8 keymap=ansi hostname=debian domain="" 
> url=tftp://10.0.0.1/preseed.cfg
> 
> Console is accessed over VGA. VMSVGA for the VirtualBox tests we've ran and a 
> VGA KVM for the tests on bare metal.

I still cannot reproduce with unpacking the tarball and running

kvm -net nic -net user,tftp=$PWD,bootfile=pxelinux.0 -drive -m 1G

and passing the kernel parameters.

Does the mangling happen right from the first screen, or after some
steps?

It could be useful to share your preseed.cfg (take care of removing any
hardcoded password).

Samuel

Bug#1065570: ***UNCHECKED*** Re: Bug#1065570: Interface border is replaced by ascii chars

[Samuel Thibault]

Hello,

Please re-send your mail unencrypted, so everybody can read the
information.

Samuel

Bug#1065570: Interface border is replaced by ascii chars

[x11r]

The machine is PXE booted with the kernel parameters: 
initrd=debian-installer/amd64/initrd.gz ip=dhcp auto=enable language=en 
country=US locale=en_US.UTF-8 keymap=ansi hostname=debian domain="" 
url=tftp://10.0.0.1/preseed.cfg

Console is accessed over VGA. VMSVGA for the VirtualBox tests we've ran and a 
VGA KVM for the tests on bare metal.

On Wednesday, March 6th, 2024 at 5:28 PM, Samuel Thibault 
 wrote:

> x11r, le mer. 06 mars 2024 18:59:50 +, a ecrit:
> 
> > I've been working with a small team at my college trying to develop a tool 
> > to automate PXE booting and installation. We have targeted Debian as the 
> > first OS we want to get working over PXE boot. On every test we've ran of 
> > the Debian installation process, there's a visual bug that occurs late in 
> > the installation process. Effectively, the border of the progress interface 
> > turns into Çâö repeatedly. You can see an image of it in the issue here 
> > https://github.com/xeluior/genisys/issues/82
> 
> 
> That looks like an utf-8 encoding issue. Please tell us exactly how you
> boot it (kernel parameters and how you access the console).
> 
> Samuel

Bug#1065570: Interface border is replaced by ascii chars

[Samuel Thibault]

x11r, le mer. 06 mars 2024 18:59:50 +, a ecrit:
> I've been working with a small team at my college trying to develop a tool to 
> automate PXE booting and installation. We have targeted Debian as the first 
> OS we want to get working over PXE boot. On every test we've ran of the 
> Debian installation process, there's a visual bug that occurs late in the 
> installation process. Effectively, the border of the progress interface turns 
> into Çâö repeatedly. You can see an image of it in the issue here 
> https://github.com/xeluior/genisys/issues/82

That looks like an utf-8 encoding issue. Please tell us exactly how you
boot it (kernel parameters and how you access the console).

Samuel

Bug#1065570: Interface border is replaced by ascii chars

[x11r]

Package: debian-installer
Version: 20230607+deb12u5

I've been working with a small team at my college trying to develop a tool to 
automate PXE booting and installation. We have targeted Debian as the first OS 
we want to get working over PXE boot. On every test we've ran of the Debian 
installation process, there's a visual bug that occurs late in the installation 
process. Effectively, the border of the progress interface turns into Çâö 
repeatedly. You can see an image of it in the issue here 
https://github.com/xeluior/genisys/issues/82

This happens every install. We have tested it on a small selection of hardware 
(I don't have the details on hand right now) and in virtual machines 
(VirtualBox). The debian-installer version is the one bundled with 
https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/current/images/netboot/netboot.tar.gz

I'm not sure where to start looking for this so let me know what other 
information would be useful.

Thank you,
Robert Gingras

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 5. März 2024 20:44:52 MEZ schrieb Philip Hands :
>BTW I don't know much about how the translation side of things works,
>but given that there are many ways of getting the fine detail of this to
>be incorrect in various ways, is there a standard method for adding
>hints for translators, and should that be done?

Such hints for translators can be added to the templates file, as in

They will then end up in translator's po files.


Do you have some specific sentence in mind, which deserves a
special hint?
I noticed that my English is not good enough to formulate such details.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1065561: console-setup: typos in documentation

[Jakub Wilk]

Source: console-setup
Version: 1.226
Severity: minor
Tags: patch

--
Jakub Wilk
diff --git a/README.legacyfonts b/README.legacyfonts
index a707fcc..2078725 100644
--- a/README.legacyfonts
+++ b/README.legacyfonts
@@ -4,3 +4,3 @@ LEGACY FONTS: CONVERSION FROM PSF TO BDF
 
-The traditional font collection for Linux consolle was a big mess.
+The traditional font collection for Linux console was a big mess.
 There were many different fonts and nobody in the world knew the exact
@@ -18,4 +18,4 @@ generated for a group of fonts that share common typeface.  Console
 fonts that didn't have embedded Unicode table were simply ignored.
-The fonts LatArCyrHeb* were also ignored - partialy due to technical
-reasons and partialy because the other BDF fonts are better source for
+The fonts LatArCyrHeb* were also ignored - partially due to technical
+reasons and partially because the other BDF fonts are better source for
 making Unicode console fonts.
@@ -43,3 +43,3 @@ For example Greek-vga14.psf is the legacy font for Greek code set and
 size 14.  The list of BDF fonts that is used to produce
-Greek-vga14.psf was determined as folows.
+Greek-vga14.psf was determined as follows.
 
diff --git a/doc/console-setup.html/ch3.html b/doc/console-setup.html/ch3.html
index c2d3a1f..bc74c33 100644
--- a/doc/console-setup.html/ch3.html
+++ b/doc/console-setup.html/ch3.html
@@ -64,4 +64,4 @@ for a group of fonts that share common typeface.  Console fonts that didn't
 have embedded Unicode table were simply ignored.  The fonts
-LatArCyrHeb* were also ignored - partialy due to technical reasons
-and partialy because the other BDF fonts are better source for making Unicode
+LatArCyrHeb* were also ignored - partially due to technical reasons
+and partially because the other BDF fonts are better source for making Unicode
 console fonts.
@@ -148,3 +148,3 @@ fonts.  This font is named after the scheme
 size 14.  The list of BDF fonts that is used to produce Greek-vga14.psf was
-determined as folows.
+determined as follows.
 
diff --git a/doc/console-setup.sgml b/doc/console-setup.sgml
index 46e16a6..54f7fdf 100644
--- a/doc/console-setup.sgml
+++ b/doc/console-setup.sgml
@@ -388,3 +388,3 @@ Console fonts that didn't have embedded Unicode table were simply
 ignored.  The fonts LatArCyrHeb* were also ignored -
-partialy due to technical reasons and partialy because the other BDF
+partially due to technical reasons and partially because the other BDF
 fonts are better source for making Unicode console fonts.
@@ -465,3 +465,3 @@ from the legacy fonts.  This font is named after the scheme
 set and size 14.  The list of BDF fonts that is used to produce
-Greek-vga14.psf was determined as folows.
+Greek-vga14.psf was determined as follows.
 

Re: removing grub-legacy from Debian

[Pascal Hambourg]

Hi Felix,

On 03/03/2024 at 14:28, Felix Zielcke wrote:


we plan to totally remove GRUB Legacy from Debian.
But grub-installer still has references to the old grub package.
Especially if multipath is used.

grub2 has long time ago gained support for the multipath devices.
See #442382 [1]

Anyone knows or could test changes to grub-installer if the old grub-
legacy is still needed for it?

I'm not able (or at least don't know how) to test multipath with grub-
installer.


I created a draft MR to remove grub-legacy support from grub-installer:


The last patch removes all remaining multipath-specific code if it is 
not needed any more.


PS1: If grub-installer still needs specific support for multipath, then 
it is likely that grub2 packages will need it too in order to reinstall 
GRUB properly on package upgrade.


PS2: Has GRUB been tested with EFI boot from a multipath device ?

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Justin B Rye  writes:

...
> Post-coffee (also fixing that wobbly indent):
>
>Some account needs to have system administrative privileges. The
>password/passphrase for that account should be something that
>cannot be guessed.
>.
>To allow direct password-based access via the 'root' account, you
>can set the password/passphrase for that account here.
>.
>Alternatively, you can lock root's password
>by leaving this setting empty, and
>instead use the system's initial user account
>(which will be set up in the next step)
>to become root. This will be enabled for you
>by adding that user to the 'sudo' group.
>.
>Note: what you type here will be hidden (unless you select to show it).

I like that version better than mine, so commited it[1], and re-ran the
test to give a screenshot:

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

> Maybe instead of saying "use the system's initial user account to
> become root" it should say "allow the system's initial user account
> to gain administrative privileges"?  I'm not sure.  Oh, and we might
> even want to mention the word "superuser", or then again we might not.

I think Diederik's suggestion of using 'root' for the account and
'super-user' for the privileges might be the way to go.

Cheers, Phil.

[1] 
https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7/diffs?commit_id=2668d06de4f2de4735404a0671ecfb33f7bbd159
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1065546: d-i.debian.org: does not install "Recommends:" by default, at least uuid-runtime

[Vincent Lefevre]

I've eventuelly found

  https://www.debian.org/releases/stable/amd64/ch06s03.en.html#di-install-base

"For technical reasons packages installed during the installation of
the base system are installed without their “Recommends”. The rule
described above only takes effect after this point in the installation
process."

Then why are recommended packages not listed explicitly?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1065546: d-i.debian.org: does not install "Recommends:" by default, at least uuid-runtime

[Vincent Lefevre]

On 2024-03-06 13:53:48 +0100, Vincent Lefevre wrote:
> Note: I installed Debian with debian-12.1.0-amd64-netinst.iso.

Same issue on another machine where I installed Debian/testing using
debian-testing-amd64-netinst.iso on January 5.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1065546: d-i.debian.org: does not install "Recommends:" by default, at least uuid-runtime

[Vincent Lefevre]

Package: d-i.debian.org
Severity: important

A few days ago, I noticed that the uuid-runtime package wasn't
installed, though libuuid1 was installed (when I installed Debian)
and had "Recommends: uuid-runtime".

FYI, uuid-runtime got pulled due to the rename of libuuid1 to
libuuid1t64.

Note: I installed Debian with debian-12.1.0-amd64-netinst.iso.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1064617: Passwords should not be changed frequently

[Diederik de Haas]

On Wednesday, 6 March 2024 13:19:04 CET Justin B Rye wrote:
> Maybe instead of saying "use the system's initial user account to
> become root" it should say "allow the system's initial user account
> to gain administrative privileges"?  I'm not sure.  Oh, and we might
> even want to mention the word "superuser", or then again we might not.

How about using 'root' for the user/account and super-user for the privileges?
The 'root' user has super-user privileges all the time and the normal user can 
get those privileges via (the) sudo (mechanism).

FTR: that *is* a slight diversion from what's said here:
https://www.debian.org/releases/bookworm/amd64/ch06s03.en.html#di-user-setup

Whatever terminology we use, I think it's important that we use the same 
terminology in both the d-i screens and the Trixie Installation Guide.
Updating the Installation Guide should probably be done separately?

Cheers,
  Diederik

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

Bug#1064617: Passwords should not be changed frequently

[Justin B Rye]

Philip Hands wrote:
>> https://salsa.debian.org/installer-team/user-setup/-/commit/77c1517fade367bc465da2a5908c5ac47dd8bba7
>>
>>   Template: passwd/root-password
>>   Type: password
>>   # :sl1:
>>   _Description: Root password/passphrase:
>>One needs a password/passphrase that grants
>>access to the 'root' (system administrative) account.
>>Be aware that a malicious or unqualified user
>>that obtains root access can have disastrous results,
>>so you should choose a password/passphrase that cannot be guessed.
>>It should not be a word found in dictionaries,
>>or something that could be easily associated with you.
>>
>> (Summary: You DO need a root password.)
> 
> No, as I said, what that's trying to say is that there needs to exist a
> password that one way or the other will let one get access to the root
> account (since otherwise one is not going to be able to admin the
> machine), but that is not neccesarily the same thing as a "root
> password", 
> 
> If it comes across as meaning that there needs to be a "root password",
> then it's not succeeding in expressing the nuance of the situation
> correctly, and we probably need to fix that (assuming that we can come
> up with a better wording that still fits in the space available).

Yes; even reading it suspecting that that might be what it was meant
to be saying I found it hard to read that interpretation into it.  The
line starting "One needs a password..." implies that this dialogue
deals with the need for the particular *password* that gives access to
the root *account* - the obvious interpretation is that it's talking
about the "Root password/passphrase" in the Description.  It takes some
mental contortions to see that my own login password might also be
thought of as doing that, and further, that this dialogue can be seen
as creating (or no, I mean causing the existence of) such a password.

But I notice now that the way I've phrased it means users aren't
implicitly warned that a sudo-privileged user account needs a good
password, so maybe I need another coffee and a think...

>>.
>>To allow direct password-based access to root,
>>you should set the 'root' password/passphrase here.
>>.
>>Alternatively, you can lock root's password
>>by leaving this setting empty, and
>>instead use the system's initial user account
>>(which will be set up in the next step)
>>to become root. This will be enabled for you
>>by adding that user to the 'sudo' group.
>>.
>>Note: what you type here will be hidden (unless you select to show it).
>>
>> (Summary: You DON'T need a root password.)
>>
>> Suggested rewrite (short version):
>>
>>  _Description: Root password/passphrase:
>>   To allow direct password/passphrase-based access to the 'root'
>>   (system administrative) account you can set it up here.
>>   To protect your system you should not use one that can be guessed.
>>   .
>>   Alternatively, you can lock root's password
>>by leaving this setting empty, and
>>instead use the system's initial user account
>>(which will be set up in the next step)
>>to become root. This will be enabled for you
>>by adding that user to the 'sudo' group.
>>.
>>Note: what you type here will be hidden (unless you select to show it).
> 
> This is certainly better than good enough, so I'd be fine with this too.

Post-coffee (also fixing that wobbly indent):

   Some account needs to have system administrative privileges. The
   password/passphrase for that account should be something that
   cannot be guessed.
   .
   To allow direct password-based access via the 'root' account, you
   can set the password/passphrase for that account here.
   .
   Alternatively, you can lock root's password
   by leaving this setting empty, and
   instead use the system's initial user account
   (which will be set up in the next step)
   to become root. This will be enabled for you
   by adding that user to the 'sudo' group.
   .
   Note: what you type here will be hidden (unless you select to show it).

Maybe instead of saying "use the system's initial user account to
become root" it should say "allow the system's initial user account
to gain administrative privileges"?  I'm not sure.  Oh, and we might
even want to mention the word "superuser", or then again we might not.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Justin B Rye  writes:

> Philip Hands wrote:
>> Justin B Rye  writes:
>>> Philip Hands wrote:
 Justin B Rye  writes:> ...
 The reason behind that structure was supposed to be that one definitely
 needs _a_ password, but not necessarily a root password, so the password
 advice applies to whichever password you'll decide to grant root access
 to, which might not be set here.
>>>
>>> This template is specifically about the "Root password/passphrase";
>> 
>> Well, sort-of, except that the user's response (whether to leave this
>> blank or not) modifies what happens with the user account's permissions,
>> so it's also about explaining the way that logic works in the installer
>> and what that will do to the target system.
>>
>>> probably I should have quoted the patch I was looking at, which starts
>>> with "One needs a password/passphrase that grants access to the 'root'
>>> (system administrative) account" but goes on to say "Alternatively,
>>> you can lock root's password by leaving this setting empty".
>> 
>> I'm intimately familiar with the patches you're reading, so I feel like
>> this comment suggests that we may be talking past one another somehow.
>
> Yes, this is a common problem: you're so familiar with what we need
> it to say that you aren't noticing what the text currently does say.
> https://salsa.debian.org/installer-team/user-setup/-/commit/77c1517fade367bc465da2a5908c5ac47dd8bba7
>
>   Template: passwd/root-password
>   Type: password
>   # :sl1:
>   _Description: Root password/passphrase:
>One needs a password/passphrase that grants
>access to the 'root' (system administrative) account.
>Be aware that a malicious or unqualified user
>that obtains root access can have disastrous results,
>so you should choose a password/passphrase that cannot be guessed.
>It should not be a word found in dictionaries,
>or something that could be easily associated with you.
>
> (Summary: You DO need a root password.)

No, as I said, what that's trying to say is that there needs to exist a
password that one way or the other will let one get access to the root
account (since otherwise one is not going to be able to admin the
machine), but that is not neccesarily the same thing as a "root
password", because the password being refered to might well be the
initial user's password, as long as they end up in the sudo group.

If it comes across as meaning that there needs to be a "root password",
then it's not succeeding in expressing the nuance of the situation
correctly, and we probably need to fix that (assuming that we can come
up with a better wording that still fits in the space available).

>.
>To allow direct password-based access to root,
>you should set the 'root' password/passphrase here.
>.
>Alternatively, you can lock root's password
>by leaving this setting empty, and
>instead use the system's initial user account
>(which will be set up in the next step)
>to become root. This will be enabled for you
>by adding that user to the 'sudo' group.
>.
>Note: what you type here will be hidden (unless you select to show it).
>
> (Summary: You DON'T need a root password.)
>
> Suggested rewrite (short version):
>
>  _Description: Root password/passphrase:
>   To allow direct password/passphrase-based access to the 'root'
>   (system administrative) account you can set it up here.
>   To protect your system you should not use one that can be guessed.
>   .
>   Alternatively, you can lock root's password
>by leaving this setting empty, and
>instead use the system's initial user account
>(which will be set up in the next step)
>to become root. This will be enabled for you
>by adding that user to the 'sudo' group.
>.
>Note: what you type here will be hidden (unless you select to show it).

This is certainly better than good enough, so I'd be fine with this too.

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


signature.asc
Description: PGP signature

Bug#1064617: Passwords should not be changed frequently

[Justin B Rye]

Philip Hands wrote:
> Justin B Rye  writes:
>> Philip Hands wrote:
>>> Justin B Rye  writes:> ...
>>> The reason behind that structure was supposed to be that one definitely
>>> needs _a_ password, but not necessarily a root password, so the password
>>> advice applies to whichever password you'll decide to grant root access
>>> to, which might not be set here.
>>
>> This template is specifically about the "Root password/passphrase";
> 
> Well, sort-of, except that the user's response (whether to leave this
> blank or not) modifies what happens with the user account's permissions,
> so it's also about explaining the way that logic works in the installer
> and what that will do to the target system.
>
>> probably I should have quoted the patch I was looking at, which starts
>> with "One needs a password/passphrase that grants access to the 'root'
>> (system administrative) account" but goes on to say "Alternatively,
>> you can lock root's password by leaving this setting empty".
> 
> I'm intimately familiar with the patches you're reading, so I feel like
> this comment suggests that we may be talking past one another somehow.

Yes, this is a common problem: you're so familiar with what we need
it to say that you aren't noticing what the text currently does say.

https://salsa.debian.org/installer-team/user-setup/-/commit/77c1517fade367bc465da2a5908c5ac47dd8bba7

  Template: passwd/root-password
  Type: password
  # :sl1:
  _Description: Root password/passphrase:
   One needs a password/passphrase that grants
   access to the 'root' (system administrative) account.
   Be aware that a malicious or unqualified user
   that obtains root access can have disastrous results,
   so you should choose a password/passphrase that cannot be guessed.
   It should not be a word found in dictionaries,
   or something that could be easily associated with you.

(Summary: You DO need a root password.)
   .
   To allow direct password-based access to root,
   you should set the 'root' password/passphrase here.
   .
   Alternatively, you can lock root's password
   by leaving this setting empty, and
   instead use the system's initial user account
   (which will be set up in the next step)
   to become root. This will be enabled for you
   by adding that user to the 'sudo' group.
   .
   Note: what you type here will be hidden (unless you select to show it).

(Summary: You DON'T need a root password.)

Suggested rewrite (short version):

 _Description: Root password/passphrase:
  To allow direct password/passphrase-based access to the 'root'
  (system administrative) account you can set it up here.
  To protect your system you should not use one that can be guessed.
  .
  Alternatively, you can lock root's password
   by leaving this setting empty, and
   instead use the system's initial user account
   (which will be set up in the next step)
   to become root. This will be enabled for you
   by adding that user to the 'sudo' group.
   .
   Note: what you type here will be hidden (unless you select to show it).

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package