Comments (5)
There has been much talk over the last two years about a hash validation for extension integrity. Would this be aimed at that?
I think if this is mostly aimed at blocking extensions that do not pass the requirement then we will have edge cases that do not pass, but are in fact allowed. Like JCB that has many many base64_encoding but used in a valid allowed way to store code in the database. How will these kind of cases be handled? since the base64 issue is a red error.
I think this is a great idea, but we will need to make sure we handle edge cases well and amicable before any of this is implemented, so the developers is able to get to the front-desk without the need of a big fight. Meaning if extensions do not comply but are valid there must be a way for the developer to appeal, an easy way (even from in the extension... possible). This is what I have always said... Joomla extension directory should be the kind of door keeper that is intelligent enough to grow with ease into best practice of the PHP industry as the architecture of the core Joomla dictates. We should not become a system that has rules for the sake of rules... or even preferences. We must acknowledge that there are large debate about implementation and therefore afford the extension developers the freedom they need, with the protection our community deserves. Showing developers best practice is one thing, but forcing them is not cool...
This is also why I have not merged some PR's since they have error messages where I think the nature of the detected implementation is not worthy to disqualify the extension.
So it will follow that we closely scan over all error reports to see if the weight they have is equal their importance. Yes I want to ensure quality, but not at the price of warping freedom software principles of our GNU GPL position.
from jedchecker.
The idea of this "signature" is only to confirm that people check the extension before submitting it. Nothing more and nothing else.
Of course, if we look into the big picture, the JED Checker could be the client that generates a hard signature to sign the download and confirm that the extension has not been tampered in any step of the distribution chain. We did something like that on GSoC EEM.
So, that's why I suggest that the simple signature that I propose is simply SHA1(MD5("file.zip")). Of course, anyone can look into the code and manually generate the hash. The aim of this signature is only to force people to use JED Checker and check the extension at least the first time, the extension is submitted.
from jedchecker.
I can agree with that, I made that long... blablabla... because of this you said:
.... OK to be submitted (no red errors)βfor instance, something like SHA1(MD5("file.zip")).
Only giving the hash if there is no errors require what I explained. But if we say, just because they tested the extension, we generate an hash... this is much easier and also a good idea.
We did something like that on GSoC EEM.
Yes I remember this, was part of that years team... but dropped out due to personal reasons. Honestly I think it will be brilliant if we could go the whole nine yards... meaning actually setup the path for this more secure distribution.
But in that case I would suggest we add the key to the update server xml and not on the JED. But okay that is a whole conversation in of itself. But worth doing....
Back to this idea as a more simple and almost "just to prove you checked" signature... I think it is a good start.
from jedchecker.
It's a good idea to promote JEDChecker, but surely we cannot trust that JEDChecker is actually passed.
@Llewellynvdm As to base64, my opinion is that it's a data obfuscation and not the code obfuscation. To transform data to code it's necessary to either eval
it or save to a file and include
it (so, I'd mitigate this error to a warning message). I'm working on a rule that will detects all possible RCE, but it will take months to be finalized (hope to finally include CSRF, XSS, and SQL injection as well). For example, my current draft is able to found RCE in the following code:
$task = $app->input->getCmd('task');
$action = $app->input->getCmd('action');
$data = $app->input->getTrim('data');
$result = "{$task($action,$data)}";
(e.g. index.php?option=com_...&task=file_put_contents&action=eval.php&data=%3C%3Fphp%20...
)
from jedchecker.
we could go the whole nine yards
I've been thinking a lot about if "strong secure distribution" can be done. Nowadays, I think it is not possible. The infrastructure requirements are very high and devops time would be huge. @Llewellynvdm
we cannot trust that JEDChecker is actually passed
Yes. That's why we always manually double-check the extensions. @dryabov
from jedchecker.
Related Issues (20)
- False positive The JEXEC security check was not found in this file. HOT 18
- [Suggestion] - Extend the readme on Crowdin Project
- False positive PH2 error HOT 4
- Dependency Dashboard
- Error: Whitespace in the key is not allowed HOT 3
- JED Checker 2.4.1 extension downloaded from the JED differs from development repository
- Language file is not loaded, when lang prefix is missing. HOT 1
- JEXEC security check HOT 6
- [PHP 8.1] Deprecated: trim(): Passing null to parameter #1 ($string) in rules/xmlinfo.php on line 322 HOT 2
- Warning: syntax error, unexpected '{' or '!' HOT 1
- NOTICE: Node <folder> has unknown attribute 'plugin' is wrong? HOT 2
- Not recognized in XML: <name>language KEY</name> HOT 3
- JEDchecked in Joomla 3.10.12 failed: TypeError: Failed to fetch HOT 17
- [J5] JED Checker extension only works with b/c plugin enabled HOT 2
- JEF Checker 2.4.2 has no checksum HOT 2
- 0 strpos(): Argument #3 ($offset) must be contained in argument #1 ($haystack) HOT 1
- JED Checker to report linebreaks in language files HOT 4
- JED Checker never finishes in PHP 8.3.0 HOT 14
- Wrong deprecation: Joomla\CMS\Filesystem\File and Joomla\CMS\Filesystem\Folder ? HOT 4
- There is interference in the mobile version, Joomla 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jedchecker.