Recently going through an older site I was examining third party modules trying to eliminate security risks. In the process I discovered several items that were either no longer supported or that had been identified as malicious on the Joomla extensions site. It would really be beneficial to flag extensions in the management screen that were no longer supported or that had been identifies as malicious. This way we could remove the functionality or look for alternative solutions, rather than have these unidentified security risks on the site.
Identify files that are no longer supported and/or flag files that pose a security risk.
obsolete or malicious files appear to be current (no update available).
The bots are out there probing sites for known vulnerabilities while all our files/extensions appear to be up to date.
Would it be possible to link extensions to that are available on the Joomla site so that they can be listed as "current" or status "unknown"?
Labels |
Added:
J3 Issue
|
Labels |
Removed:
J3 Issue
|
Labels |
Added:
J3 Issue
|
Isn't the update server in the extensions xml? and so if that node exists in the xml and has a link in it - you could "assume" it supports updates. No need to use the JED at all. Thats about as much as core Joomla can hope for. The Joomla VEL is not fit for production purpose either.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-02-21 22:38:37 |
Closed_By | ⇒ | Quy |
Closed_Date | 2019-02-21 22:38:37 | ⇒ | 2019-02-21 22:38:38 |
Closed_By | Quy | ⇒ | joomla-cms-bot |
Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/22872
It would be impossible to support this.
We couldn't introduce a system to check if an extension is supported. If it relied on calls to the JED, it would mis-report custom extensions (or even Joomla core because no parts of it are on the JED). If it relied on the extension's own update server, this still relies on the developer making an update saying "extension abandoned".
Scanning for malicious content is subjective at best and really requires a specialized service to do this. This code couldn't be included in core because of how frequently it would need to be updated, and I don't think we're going to introduce something into
joomla.org
that tries to emulate features from myJoomla or Sucuri or other security driven services and inherently code in the CMS that tries to send this code to us.