WIP: Introduce a new security issue list that is fetched alongside the app catalog, such that the diagnosis reports warnings/errors for older versions of apps or system packages vulnerable to known security issues

[alexAubin]

The problem

Software regularly have security issues because computers™, but we lack a proper way to communicate to the users about the fact that their system may be vulnerable. Posts on the forum are nice but we can't just expect people to come and read the forum every week.

Solution

cf draft in YunoHost/issues#1438

The diagnosis should trigger a warning/error when finding that an app or system packages is installed and affected by the issue.

The security.json should be made available as security.json next to the catalog's apps.json

security.json could be derived from a TOML looking like (syntax to be validated etc) :

[apps]
	
    # Two [[ ]] here, because each entry (app id) is associated with a *list* of such infos
    [[apps.opensondage]]
	title = "zomg big vulnerability"
	more_infos = "https://github.com/yunohost-apps/opensondage_ynh/issues/12345"
	fixed_in_version = "1.2.3~ynh1"
	level = "danger"

[system]

	[[system.dovecot]]
	title = "zomg big permission vulnerability"
	more_infos = ""
	fixed_in_version = "2.2.27-3+deb9u5"
	level = "warning"

PR Status

Yoloimplemented

• collectively validate the syntax/infos for the security.toml
• actually test it
• implement the system package part
• we may want to use this to support the case of "app changed name" which can be somehow be argued to fit as a security issue i suppose, but with no fixed_in_version ? we could have an optional replaced_by: "new_app_id" key/value
• ???

How to test

...

[OniriCorpe]

if the diagnosis is setup to run automatically, we could also show the warning in the top of every webadmin page

[zamentur]

Detect exposition to Visitors (or ynh standard users) ?

There are a lot of situations in which SSO could protect and reduce the criticity of a security hole inside an app.

May be we could, distinguish this in the format ?

Display alternative countermeasures

Sometimes the app could not be upgraded easily in a quick way, for example:

• the instance could not be upgraded onto the last ynh major version quickly cause an app or something block the upgrade
• the app is customized (theme or patched)
• the app db upgrade is not sure
• the
• final users usage need a feature that disappears, is buggy or changed in new version

However, with a lot of high security hole, alternative countermeasures are possible than just upgrade to the last version...

Could be nice to be able to display, a sum up info on that ?

[apps]
	
    # Two [[ ]] here, because each entry (app id) is associated with a *list* of such infos
    [[apps.opensondage]]
	title = "zomg big vulnerability"
	more_infos = "https://github.com/yunohost-apps/opensondage_ynh/issues/12345"
	fixed_in_version = "1.2.3~ynh1"
        sso_countermeasure = True
        others_countermeasure = "Deactivate email feature from opensondage web admin"
	level = "danger"