Skip to content
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

Issue #9511 Verify location of scanned class files #10777

Closed

Conversation

janbartel
Copy link
Contributor

Closes #9511

Check that a class file that is about to be scanned is in the correct location, skipping it if not.
For example, given a class with fully qualified name com.acme.Foo that comes from jar:file://someplace/somewhere.jar!/ ensure that class is located at jar:file://someplace/somewhere.jar!/com/acme/Foo.class.
This would skip the class if it was in eg jar:file://someplace/somewhere.jar!/this/is/the/wrong/place/com/acme/Foo.class. See the original issue #9400 for more examples.

@janbartel janbartel self-assigned this Oct 25, 2023
@sbordet
Copy link
Contributor

sbordet commented Oct 25, 2023

@janbartel make sure we also test for some.jar!/META-INF/versions/<ver>/com/acme/Foo.class.

@janbartel
Copy link
Contributor Author

@sbordet there are already tests for that.

gregw
gregw previously approved these changes Oct 29, 2023
Copy link
Contributor

@gregw gregw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fix looks reasonable, but ee8 tests are failing?? So a LGTM if those CI tests are fixed.

janbartel and others added 8 commits October 30, 2023 18:38
…etTestResourcePathFile

Signed-off-by: Olivier Lamy <olamy@apache.org>
Signed-off-by: Olivier Lamy <olamy@apache.org>
Signed-off-by: Olivier Lamy <olamy@apache.org>
Signed-off-by: Olivier Lamy <olamy@apache.org>
Signed-off-by: Olivier Lamy <olamy@apache.org>
Signed-off-by: Olivier Lamy <olamy@apache.org>
@olamy olamy force-pushed the jetty-12.0.x-9511-verify-scanned-class-location branch from dad52e5 to de7498a Compare October 30, 2023 08:41
//Check that the named class exists in the containingResource at the correct location.
//eg given the class with name "com.foo.Acme" and the containingResource "jar:file://some/place/something.jar!/"
//then the file "jar:file://some/place/something.jar!/com/foo/Acme.class" must exist.
if (_containingResource.resolve(name + ".class") == null)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is causing issues for osgi bundles as classes are not resolved anymore within bundles

Copy link
Member

@olamy olamy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AnnotatioParser doesn't look to be related to any eeX version. could it be in a single place?

@janbartel
Copy link
Contributor Author

AnnotatioParser doesn't look to be related to any eeX version. could it be in a single place?

Potentially we could move it into a core jetty-annotations module, but I think that would be a separate PR.

@janbartel janbartel requested a review from olamy November 1, 2023 02:46
@janbartel janbartel requested a review from gregw November 6, 2023 22:32
Copy link
Contributor

@gregw gregw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going a bit cold on this idea.

if (relative == null)
return false; //unable to be verified

StringTokenizer tokenizer = new StringTokenizer(classname, "/", false);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't the classname have '.' separators rather than '/'?

If it has '/' separators, then maybe we should split it with Path?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The classname when referenced via a resource has slashes.

Comment on lines +560 to +564
if (i == relative.getNameCount() - 1)
{
if ("class".equals(FileID.getExtension(s)))
s = s.substring(0, s.length() - 6);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A comment saying what this is doing would be good. something like // strip the .class suffix from the last path item.
Also, if the .class is missing then we should not match
Finally, it should be an equalsIgnoreCase

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be changed to ...

// strip class extensions
if (FileID.isExtension(s, "class"))
    s = s.substring(0, s.length() - 6)

As that will verify the extension in a case insensitive way.

@janbartel janbartel requested a review from gregw December 13, 2023 22:41
@joakime joakime linked an issue Jan 24, 2024 that may be closed by this pull request
@janbartel
Copy link
Contributor Author

@gregw shall we can this PR?

@joakime
Copy link
Contributor

joakime commented Apr 11, 2024

@janbartel @gregw shall we close this PR as not useful?

@janbartel janbartel closed this Apr 13, 2024
@janbartel
Copy link
Contributor Author

These changes aren't crucial.

@janbartel janbartel deleted the jetty-12.0.x-9511-verify-scanned-class-location branch April 13, 2024 07:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Jetty 12 Verify scanned class is in the expected package
5 participants