Password of secondary encrypted partitions shown in /var/log/archinstall/install.log (be mindful of posting the log until v2.4.2)

[Torxed]

As pointed out in #137 in comment https://github.com/archlinux/archinstall/issues/137#issuecomment-1086801464. When archinstall creates a encryption key which it uses to encrypt a secondary volume, the password is seen in plain text in the log:

Marking partition for use with encryption-key: {'type': 'primary', 'encrypted': True, 'format': > True, 'start': '40GB', 'size': '100%', 'mountpoint': '/home', 'filesystem': {'format': 'btrfs'}, > '!password': 'plain.text.password.here'}

Until v2.4.3 is released, be mindful of posting your install.log anywhere. Apologies for the inconvenience, this will be addressed in a more central manner.

[ghost]

I was going to make a similar issue but I thought I'd point it out here instead: the password is also printed on screen in plaintext while the system is being installed, with the message being Formatting a partition that has no mountpoint target.

[shervinsahba]

Permissions of /var/log/archinstall/install.log are rw-r--r-- on my system. In addition to scrubbing the encryption password, would changing permissions to rw------- be a further improvement?

[Torxed]

Absolutely, while we make sure the other thing is taken care of we should change that too. We've also discussed copying over all the logs, the ones that should contain the credentials and that needs attention too before we do.

[Torxed]

So the original issue is fixed in master (and has been for a while, but it's taken longer than anticipated to really make sure it's not been creeping during tests).

In regards to permissions, I circled back on changing permissions on install.log. Setting 440 or something similar won't change much to protect us from issues like this, as users will still be able to post the log as they're root during installation. And the file should never contain sensitive information to begin with. However, cmd_history.txt, cmd_output.txt, user_credentials.json and user_disk_layout.json will most likely contain sensitive information and thus they needed to be better protected.

So going forward, they now have rw-r----- on all of them. I therefore consider this closed and fixed :)

Thank you all for your patience and for reporting this!