It is confusing to combine the user's intent of wanting to have backports
activated with whether they have actually been configured in the system.
- Separate out checking for requested which is a key in the kvstore from enabled
which is about checking system configuration for backports.
- Implement convenience method for setting whether user requested backports.
- Do not base the status display (in security and upgrades modules) on the
configuration status and instead focus on user intent.
- If user requested backports but they have not been enabled yet due to not
being available, show as activated. System will keep trying the background and
configure eventually.
- If user requested backports but their configuration is outdated yet due to
newer release, show as activated. System will keep trying in the background
and configure latest settings eventually.
- In all places where backports enabling is being checked, split the logic for
'can be activated' from 'already activated' and 'user requested activation'
properly.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Tests:
- Build deb and install in buster image. Manually remove backports
sources file. Security page does not show backports notice. Updates
page shows button to activate backports.
- Activate backports from updates page. Success message is shown and
button to activate backports is removed. Security page shows
backports notice.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
- Remove the need to pass all the individual information elements to the AppView
separately. This eliminates many issues with elements that were mistakenly not
sent to AppView. Also reduces a lot of code duplication.
- Create App classes for power and sso for consistency.
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Show the number of vulnerabilities reported by debsecan for freedombox
package and for managed_packages of each installed app.
Essential apps are not included in the list. Also note that
dependencies of the managed_packages are not included yet.
The purpose of this information is to help users decide which apps to
use, and what level of personal information to store in each app.
Closes#1609.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
[sunil@medhas.org Show essential apps too]
[sunil@medhas.org Fix HTML tags]
[sunil@medhas.org Use setup_helper to get the installed state of an app]
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Closes#930
- Make targets to download wiki pages of each service
- Add post-processor script for DocBook file processing
Signed-off-by: Joseph Nuthalapati <njoseph@thoughtworks.com>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Run sudo-required action via actions.superuser_run
Actions related to services those require `sudo` permissions need to
be executed via actions.superuser_run.
NOTE:
If plinth service is started via `sudo ./run --debug` (in dev mode)
all actions will be executed silently. But plinth in user machines
won't be executed with sudo permissions.
- Do stricter matches when editing configuration file. Earlier
mechanism would match comments etc.
- Move action methods to module core from views.
- During first boot, notify users that console login is restricted and
that they can changed that from security settings.
- Recommend enabling conosle login restrictions. Add message about why
console restrictions are important.
- Show title in security module.
