ISO - no default for encryption on/off - user should choose explicitly

Patrick · September 10, 2024, 11:48pm

The user should either:

select encryption
not select encryption

But there should be no default choice. The user should make an explicit choice.

This is because unfortunately on Freedom Software Linux desktop distributions, there is no easy way to enable full disk encryption after installation.

arraybolt3 · September 25, 2024, 8:33pm

There are a few ways one could implement this, some of them more invasive than others. One way that might work is to simply prevent the user from proceeding past the partitioning screen if encryption is enabled but a passphrase isn’t set, and then have the disk encryption checkbox checked by default. In that instance a user would be required to either choose a passphrase or disable encryption. IMO this is the best solution since it should be reasonably obvious to the user why they can’t proceed, and it forces them to make a conscious choice, which is the goal.

It’s also possible to make the “Encrypt system” checkbox tristate, but that comes with some disadvantages and probably won’t have good UX (it might not be clear to the user why they can’t proceed, especially since users oftentimes don’t even notice that the disk encryption checkbox is there at all).

Patrick · September 26, 2024, 1:06pm

arraybolt3 via Kicksecure Forums:

There are a few ways one could implement this, some of them more
invasive than others. One way that might work is to simply prevent the
user from proceeding past the partitioning screen if encryption is
enabled but a passphrase isn’t set, and then have the disk encryption
checkboxchecked by default.
In that instance a user would be required to either choose a passphrase
or disable encryption. IMO this is the best solution since it should be
reasonably obvious to the userwhy they can’t proceed, and it forces them to make a conscious choice, which is the goal.

This “easy” solution sounds good for now.

Later maybe…

Do you wish to use Full Disk Encryption (FDE)?

[ ] use FDE
[ ] do not use FDE

Setting up FDE later is very difficult.

The text needs more work probably if this is even realistic. The text
could be improved to explain what FDE is and whatnot.

“Setting up FDE later is very difficult.” - maybe only show if selecting
“no”

Could be difficult since that might require modifications to the
calamares partition module, which is not written in python.

Patrick · September 27, 2024, 2:27am

github.com/calamares/calamares

After checking "Encrypt system", the user can proceed past the Partitions screen without entering a passphrase

opened 11:00PM - 25 Sep 24 UTC

ArrayBolt3

**Describe the bug** If the user checks "Encrypt System", the "Next" button rem…ains enabled and they can proceed past the partitions screen without entering a passphrase. Unchecking and rechecking the box results in the "Next" button being grayed out as expected. **To Reproduce** Steps to reproduce the behavior: 1. Launch Calamares. 2. Click "Next" until you get to the partitions screen. 3. Click "Erase Disk". 4. Check the "Encrypt system" checkbox. 5. Click "Next" (do not enter a passphrase first). **Expected behavior** "Next" button should be disabled and unable to be clicked. **Screenshots and Logs** ![Screenshot_20240925_175929](https://github.com/user-attachments/assets/ab1133bc-0c72-4de7-9285-ab8fc998bee1) **Additional context** I debugged this issue using gdb and traced it to a logic error in `src/modules/partition/gui/EncryptWidget.cpp`: ```c++ // In function EncryptWidget::updateState( const bool notify ): // ... if ( newState != m_state ) { m_state = newState; if ( notify ) { Q_EMIT stateChanged( m_state ); } } ``` The `if ( newState != m_state )` is causing the issue. In the constructor, `m_state` is initialized to `Encryption::Disabled`, but when the constructor calls `updateState()` in EncryptWidget.cpp line 68, `m_state` gets changed to `Encryption::Unconfirmed`. This is because `updateState()` is called while the "Encrypt system" checkbox is still invisible, thus triggering the following code path: ```c++ EncryptWidget::Encryption EncryptWidget::state() const { Encryption newState = Encryption::Unconfirmed; // This `if` statement is entered because the "Encrypt system" check box is invisible since the app is still starting up if ( m_ui->m_encryptCheckBox->isChecked() || !m_ui->m_encryptCheckBox->isVisible() ) { // And naturally, the passphrase text boxes are also empty, so this `if` statement will be skipped over... if ( !m_ui->m_passphraseLineEdit->text().isEmpty() && m_ui->m_passphraseLineEdit->text() == m_ui->m_confirmLineEdit->text() ) { newState = Encryption::Confirmed; } else // ...and this one is run instead, thus returning `Encryption::Unconfirmed` which is what m_state is then set to. { newState = Encryption::Unconfirmed; } } else { newState = Encryption::Disabled; } return newState; } ``` So ultimately `m_state` ends up being set to `Encryption::Unconfirmed` once the encryption widget's constructor is finished. Then when the user checks the "Encrypt system" checkbox later on, `EncryptWidget::state()` properly determines that the state is `Encryption::Unconfirmed`, but because `m_state` is already `Encryption::Unconfirmed`, it does **not** emit a `stateChanged` signal. This means that `ChoicePage::onEncryptWidgetStateChanged` is not called when the user first checks the checkbox, and thus the "Next" button is not disabled. Simply removing the `if ( newState != m_state )` statement from EncryptWidget.cpp should be enough to resolve the bug.

Patrick · September 27, 2024, 2:38am

Patrick · September 29, 2024, 9:09am

Implemented in Kicksecure 17.2.3.7 and above.

Patrick · September 29, 2024, 9:53am

A post was split to a new topic: Ubiquity / LVM / TPM

Patrick · September 29, 2024, 9:56am

Patrick:

Later maybe…
Do you wish to use Full Disk Encryption (FDE)?

[ ] use FDE
[ ] do not use FDE

Setting up FDE later is very difficult.
The text needs more work probably if this is even realistic. The text
could be improved to explain what FDE is and whatnot.

“Setting up FDE later is very difficult.” - maybe only show if selecting
“no”

Ubiquity has a nice implementation.

related: Ubiquity / LVM / TPM

Patrick · October 2, 2024, 4:27pm

related issue:

github.com/calamares/calamares

With `preCheckEncryption` enabled, it becomes impossible to disable encryption without using manual partitioning

opened 04:02PM - 02 Oct 24 UTC

ArrayBolt3

**Describe the bug** Calamares provides a feature, `preCheckEncryption`, that c…an be set in the `partition` module. This feature is designed to make the encryption checkbox checked automatically, requiring the user to either enter an encryption passphrase *or* disable encryption in order to proceed. This ensures that the user notices that encryption is available and is encouraged to use it. This feature however only half works - while the user is encouraged to set a passphrase, they are *not* able to disable encryption and proceed past the "Partitions" screen. Trying to do so results in erratic behavior, and the "Next" button is never enabled even if the "Encrypt system" check box is unchecked. A video of exactly what happens can be seen below. **To Reproduce** Steps to reproduce the behavior: 1. Boot up an ISO from a distro that uses Calamares as the installer. 2. Ensure that `/etc/calamares/modules/partition.conf` has the `preCheckEncryption` setting enabled. 3. Launch Calamares. 4. Proceed through the screens until you get to the "Partitions" screen. 5. Click "Erase disk". 6. Uncheck the "Encrypt system" checkbox - the passphrase text boxes will vanish, but the "Encrypt system" checkbox itself will remain checked, and the "Next" button will not be enabled. 7. Uncheck the "Encrypt system" checkbox again - this time it will become unchecked, but the "Next" button will still not be enabled. **Expected behavior** Unchecking the "Encrypt system" checkbox should result in the box becoming unchecked, the passphrase text boxes vanishing, and the "Next" button becoming clickable. **Screenshots and Logs** https://github.com/user-attachments/assets/82710517-9716-4290-9064-8879bf175f95 **Additional context** Looking at the code, I think the problem is in `calamares/src/modules/partition/gui/ChoicePage.cpp`, in function `ChoicePage::updateActionChoicePreview`. There are a couple of spots in the function that run `if ( m_config->preCheckEncryption() ) { m_encryptWidget->setEncryptionCheckbox( true ); }`. This happens *every time* the preview is updated, which means that even if the user explicitly unchecks the box, it could end up becoming checked again. I assume that this is what's causing the encrypt system box to not really uncheck the first time you go to uncheck it - the very action of unchecking it triggers a preview refresh, which then re-checks it. Assuming this is the problem, it would probably solve the issue to simply ensure that the box is only ever checked once. After the first time, it should never be put into a checked state programatically. That way what the user chooses to do thereafter is respected. I'll test this and probably append it to my existing PR for fixing https://github.com/calamares/calamares/issues/2375.