Happy to improve the UI part as I did only a minimal badge. Suggestions?

Documentation how to add the information to the xml needed, besides that looks good to me.

Where should I document it?

Where should I document it?

https://manual.joomla.org/docs/next/building-extensions/install-update/update-server/

I have tested this item ✅ successfully on 9d48714

I have tested this item ✅ successfully on 9d48714

Thinking aloud but I wonder if this should bubble through to the dashboard quickicon to indicate that there are x extensions with security updates

Thank you for this, really helpful.

A thought (not a blocker): I'm not sure if we need 4 level, especially all are red. Either it's a security update or it's not. So in my opinion we just need a 1/0 flag.

When 4 level are needed, we should separate it with colours, but still, I think true/false would be enough.

I have chosen the standard severity levels, so other consumers, like VEL or site management services can use that as well. But in the back end it is basically true or false. But I would keep the severity level for use cases outside of the back end.

I have chosen the standard severity levels, so other consumers, like VEL or site management services can use that as well. In the back end it is basically true or false. But I would keep the severity level for use cases outside of the back end.

With the last commit, I added the information also on the quick icon:

Any suggestion for the text?

just as a thought: for me, security updates you just 'push' and if needed repair later. So maybe have the level reflect not the risk of the vulnerability but the impact of the release. Have it accompanied with a url to page where instructions are given when the release breaks things etc.
An agree with @brianteeman that this should bubble up to the notification module. maybe also make this a task plugin that send out an email to the site owners (like the joomla update)?

just as a thought: for me, security updates you just 'push' and if needed repair later. So maybe have the level reflect not the risk of the vulnerability but the impact of the release. Have it accompanied with a url to page where instructions are given when the release breaks things etc.
An agree with @brianteeman that this should bubble up to the notification module. maybe also make this a task plugin that send out an email to the site owners (like the joomla update)?

Task is outside of the scope for this pr as I would like to have it in 6.2.

Task is outside of the scope for this pr as I would like to have it in 6.2, when possible.

and as another thought.
installed is version 1.0, I release security update 1.1 and a week after that I release a regular release 1.1.1

for siteowners with 1.0 they see that there is a security release up and until version 1.1.1 is released, then the batch is not displayed and they are not aware of the securityfix as it is displayed as a regular update (although 1.1 is part of 1.1.1)

and as another thought.
installed is version 1.0, I release security update 1.1 and a week after that I release a regular release 1.1.1

for siteowners with 1.0 they see that there is a security release up and until version 1.1.1 is released, then the batch is not displayed and they are not aware of the securityfix as it is displayed as a regular update (although 1.1 is part of 1.1.1)

So the 1.1 security badge should 'bubble up' to 1.1.1 when installed version is lower then 1.1

With the current architecture of the update detection, this is not possible. But if you have a code suggestion, I'm happy to solve that use case.

When it is a medium or low severity, then it will be shown as yellow label and not red anymore with 67570a9.

When it is a medium or low severity, then it will be shown as yellow label and not red anymore with 67570a9.

technically this is an accessibility failure as you are conveying meaning by the use of colour alone.

while looking into the current architecture I have the following finds / comments:

1. this label is not worth much for people who only do updates e.g. once a month (that is the behavior I see for my extensions, once a month or when a new Joomla version is released): when after the security release there is a regular release they will not be informed.
2. in the change log we already have 'SECURITY' type, why not use this to indicate that it is a security release instead of adding another XML field: feels doing things double and is 'error' prone (read: confusing): I have fixed a security issue and labeled it as such in my change log but do not set the security 'tag': is that then a security release or not.

So based on this I would suggest (for #2) to not implement the security field but display the security label based on the changelog items having security items, or have both where the security items on a version bubble up to the new security field (with e.g. level 5 = COM_INSTALLER_SECURITY_SEVERITY_UNSPECIFIED)
and for #1 ./libraries/src/Changelog/Changelog.php should be extended with a range scan alongside the existing exact-match mode (as that is still needed for rendering a specific version's note) This should then be hooked up into the Updater.php (installed and candidate version already known here).

and as a side note, not for this PR but maybe for future PR's: it would IMO make a lot of sense to also not only display the changes in the last version, but to display the changes in the versions from the current instaled version up to the latest version: for the same reason as why the security tag should bubble up: rendering the change log useless if it is not displaying all that is changed from the installed version. I already posted this as an idea long ago, still relevant IMO.

just my 2cts.

What happens in this scenario

I have Module v1.0 installed
A new security release v1.1 happens with the element <security>4</security> I am on holiday so I do not see that A new regular release v1.2 happens with the element 0

What happens in this scenario

I have Module v1.0 installed
A new security release v1.1 happens with the element <security>4</security>
I am on holiday so I do not see that
A new regular release v1.2 happens with the element <security>0</security>

its beyond the scope of this improvement but definitely something that needs to be considered and addressed

@brianteeman that is what I said here #48127 (comment) and analyzed here: #48127 (comment) (number 1) with suggestion on how to address

I do not agree with your suggestion. It requires

• a changelog which few extensions do
• parsing of the changelog

@brianteeman that is why i wrote "or have both where the security items on a version bubble up to the new security field"
the changelog is there for a reason: lets 'facilitate' developers who do use it instead of 'abandon' it because there are few extensions using it.
And parsing of the changelog can only be done when there is a changelog, when there is no change log or when you do not parse the changelog this is what happens: #48127 (comment)

FYI there is a pr for improve changelog #48015

@Ruud68 so please test the existing PR for the changelog changes that you want. If it never gets tested then nothing will ever change. And as a developer I am sure you will be able to contribute improvements if you see the need for any.

I did and it failed.
also it is not related to this change for which I, as a developer, am able and willing to contribute (like I already did here: #48127 (comment)) to the discussion needed.

When it is a medium or low severity, then it will be shown as yellow label and not red anymore with 67570a9.

technically this is an accessibility failure as you are conveying meaning by the use of colour alone.

So should I revert that change? For me it makes more sense to distinguish High and Critical from the rest.

Showing a security flag from an older version or a higher one than installed is currently out of scope for this pr, because as far as I saw it, it needs a bigger refactoring which I'm not sure it can be done in a backwards compatible way. So better have for now only the status from the latest version than nothing. I really see great potential having a security flag in the update stream for services outside of joomla. So hopefully this gets soon tested.

You dont have to revert it. Quickicons already use color alone when they should not. you could add something like
<span class="visually-hidden">Critical Warning</span>

In quickicons I add only text, the change is for the updates list

yes sorry I wasnt clear - I meant that quickicons already mis-use color - nothing to do with this PR

my suggestion for the screen reader text was just for the list

Showing a security flag from an older version or a higher one than installed is currently out of scope for this pr, because as far as I saw it, it needs a bigger refactoring which I'm not sure it can be done in a backwards compatible way. So better have for now only the status from the latest version than nothing. I really see great potential having a security flag in the update stream for services outside of joomla. So hopefully this gets soon tested.

understand, what about the security items we already have in the change log: when set should they then not also be displayed as 'security' instead of as a regular update?

Note that I can work around that by setting the security flag in the XML when there is a security item in the changelog for that extension, but that is a workaround then for every developer who wants to have this. IMO this would be added value if it came from the core instead. For me that would be a 'must have' in this PR as how it is now is IMO to basic.

Also note that the way you implement the change now with levels of security that would complicate things down the road if this would be implemented later (the changelog items only have one level, not multiple). Another reason to think this through

Showing a security flag from an older version or a higher one than installed is currently out of scope for this pr, because as far as I saw it, it needs a bigger refactoring which I'm not sure it can be done in a backwards compatible way. So better have for now only the status from the latest version than nothing. I really see great potential having a security flag in the update stream for services outside of joomla. So hopefully this gets soon tested.

understand, what about the security items we already have in the change log: when set should they then not also be displayed as 'security' instead of as a regular update?

Note that I can work around that by setting the security flag in the XML when there is a security item in the changelog for that extension, but that is a workaround then for every developer who wants to have this. IMO this would be added value if it came from the core instead. For me that would be a 'must have' in this PR as how it is now is IMO to basic.

Also note that the way you implement the change now with levels of security that would complicate things down the road if this would be implemented later (the changelog items only have one level, not multiple). Another reason to think this through

and as an after thought: the security level (high, medium) has no value without context on what that means for the site owner. So it is medium.... "do i have to do it now, and if not then when? Do i have time to test? or is that only with low?" etc.

I think we can afterwards implement to use the security items from the changelog (I see here a performance issue as we have to parse for every update the changelog). I don't want to block this one any further.

and as an after thought: the security level (high, medium) has no value without context on what that means for the site owner. So it is medium.... "do i have to do it now, and if not then when? Do i have time to test? or is that only with low?" etc.

I think adding the levels to the help screen would be a good addition.

To be honest, I am very unsure about this.

On the one hand, giving developers the ability to indicate that an update contains a critical security fix is a good and potentially useful feature.

On the other hand, displaying this information prominently in the dashboard is more likely to cause panic and damage Joomla’s reputation.

Let’s be honest. People who do not maintain their websites will ignore these warnings anyway. Those who actively maintain their websites already know when a security update is released, whether it affects their particular site, and whether the update can safely be postponed.

It is also important to remember that a release may contain other changes besides security fixes. Even an update addressing a critical vulnerability does not necessarily need to be installed immediately. If the update may affect the site’s functionality, it can be better to apply a temporary patch first and properly prepare the site for the update.

Now look at this from the perspective of an ordinary administrator whose website security is managed by other people.

They open the dashboard and see a large number of security updates. Nowadays, even XSS issues that barely exist in practice are often fixed simply to satisfy AI-based code reviewers. So the administrator opens the dashboard and sees twenty security updates ranging from Low to Medium severity, and this happens three or four times a week.

The first thing they may think is: why am I using Joomla if it constantly has so many security problems?

The second problem is that, when they see a Critical warning, they may click the update button themselves. The update could then break the website, while the support team would also have to deal with endless questions and complaints.

There is another important point. Publicly disclosing that a vulnerability was found is a very complicated ethical matter, and many developers prefer to disguise or downplay such fixes. As a result, not everyone will use this security flag, and the developers who do use it honestly may end up being the ones who are punished for it.

Overall, I am genuinely not sure whether this feature is worth it.

How will you know when a security release is published?

I have tested this item ✅ successfully on edd5e1e

I have tested this item ✅ successfully on edd5e1e

@laoneo
It varies.

Official websites, Telegram channels, social media, directly from developers, mysites.guru =)

I also regularly check for updates myself and look at what is included in each release.

Updating extensions is routine. Checking the release notes and testing the update locally first has simply become a habit.

Besides, the set of extensions is usually more or less the same across the sites.

For me, there is not much difference in how I review a security release compared with a regular bug-fix release.

Sometimes an ordinary release with fixes and new features can be much more important than a fix for an XSS vulnerability that is practically impossible to exploit.

@laoneo
It varies.

Official websites, Telegram channels, social media, directly from developers, crontab, mysites.guru =)

I also regularly check for updates myself and look at what is included in each release.

Updating extensions is routine. Checking the release notes and testing the update locally first has simply become a habit.

Besides, the set of extensions is usually more or less the same across the sites.

For me, there is not much difference in how I review a security release compared with a regular bug-fix release.

Sometimes an ordinary release with fixes and new features can be much more important than a fix for an XSS vulnerability that is practically impossible to exploit.

How will you know when a security release is published?

as developer you are obliged (at least when under the EU Cyber Resilience Act) to not only provide free updates for 5 years, but also to inform your customers (via email) that there is a security update and where they can download it.

Signalling it via this proposed label is not enough as like we already established, the label will not show when a regular update is done after the security release.

Can we keep on topic here - this is simply about adding the possibility of a developer flagging an update for security and for this to be immediately visible to site owners. Anything more is really off-topic and it would be great if you created a discussion to hear all views and come up with a valid plan

I have tested this item ✅ successfully on 9378106

on PostgreSQL (PDO) 15.14

I have tested this item ✅ successfully on 9378106

on PostgreSQL (PDO) 15.14

RTC

RTC

Thank you!

I found a way to detect updates with a higher severity in between. Please test #48190.