-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
verify the path in the autoloader #18396
Conversation
cc @LukasReschke @Xenopathic @DeepDiver1975 @PVince81 |
👍 |
$this->validRoots = $validRoots; | ||
} | ||
|
||
public function addValidRoot($root) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PHP Doc please
Will this potentially break any existing apps ? (especially thinking about the ones where class name doesn't match file name) |
It only checks the path that the autoloader comes up with, not the classname so it shouldn't break anything using classmaps |
What's the state on this? |
8d8a92f
to
e9b91b1
Compare
A new inspection was created. |
@LukasReschke should be good to merge |
verify the path in the autoloader
There is code in
|
@oparoz Make sure you are calling the bootstrap correctly, it initializes the autoloader path |
Thanks for the tip @Xenopathic! I can see that it adds Couldn't that line be added to |
@oparoz The autoloader should be 'locked down' to its minimum set of directories, for maximum security. The fact that no-one has found a security bug in our tests does not mean that there isn't one (we take a lot of liberties in the tests), so it makes sense only to enable the tests subdirectory when we are actually running tests. For that, you have to make sure that the bootstrap is loaded, or you manually add the prefix. Perhaps it's a documentation issue? |
Ah, got it, thanks :) I think it would be wise to post something on the mailing list. I'll open an issue on ocdev. |
It has started... |
I vote for revert, not loading all the stuff by default anymore causes major problems for apps. Also the expected minimum for a change like this would be a mail to the dev list with a code sample how to get it working again, don't you think? |
Revert! |
I agree that the process is broken, but the fix is a one-liner and the patch adds extra security to ownCloud. Maybe fire an email on the dev list asap and keep it in? |
Well test folderis removed while creating the packages, so... |
Don't revert, only impacts test, simple fix |
"only" |
Some of my apps are symlinks and have always worked, but it's broken: An unhandled exception has been thrown: Stack trace: |
Yes. Symlinks seem not to be resolved. For the meantime you can use Lines 621 to 635 in e9e42ff
|
Can we revert this? Even after adjusting my tests this won't work for cli commandline tests. Why not simply ship without the tests directory? Or very simply don't load test cases when we are not in debug mode .... |
Apart from that this makes no sense: All tests in the tests folder that are autoloadable should be wrapped in classes that extend a PHPUnit testcase. Now even if someone loads a test through an attack, nothing will happen. Also this is half assed: what about test folders in an app directory? TL;DR: PR makes no sense, fix your tests to not execute code when included (if there even are any) 👎 |
@BernhardPosselt I thought your problem was about loading your app code when running tests? Therefore the problem lies in loading your app, not in registering the tests directory in the autoloader. This was done as part of #18839 to harden ownCloud against outdated installed-but-not-enabled apps. |
That's fine, but you are also breaking the test suite. |
Another thing: if you are still going for the appinfo/app.php approach, the autoloader needs to be run before including the app.php, otherwise it depends on what app gets executed first and stuff breaks. |
#19039 should do what you need. |
limit auto loaded files to only the paths we expect code to be in