WildTypePattern: fix hashCode and toString methods
Especially 'hashCode' did not correspond to 'equals', disregarding
several fields, array dimension information being only one of them. This
led to parts of pointcuts being ignored, because they were regarded as
duplicates. Example:
execution(Foo* *(..)) && !execution(Foo*[] *(..))
Here, the negated pattern was falsely regarded as equal to the first
pattern, leading to an "A && !A" situation, i.e. no match at all.
Furthermore, 'toString' did not print array strings, i.e. instead of
"Foo*[][]" something like "Foo*" was printed. This false information was
also present in annotations generated by the weaver.
FuzzilyMatchingAspect was adjusted to actually match exactly once, as
expected, for the "Foo*" return types, i.e. exclusions for the array
return types have been added.
Relates to #24.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Handle one- and multi-dimensional array return types correctly
Fixes https://github.com/eclipse/org.aspectj/issues/24, both the array
return type matching as such as well as matching dimensionality patterns
correctly. E.g., 'Foo*[]' is not the same as 'Foo*[][]'. This also works
correctly in combination with asterisks, even for primitive types, i.e.
'in*[][]' correctly matches a 2-dimensional array of 'int'.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Refactor, comment and reactivate Ajc183Tests.testAnnoStyleDecp_442425
This test was always inactive and did not add any value other than
during development. No it runs, passes and documents the status quo of
- what was fixed (regression for AJC 1.8.2 core dump fixed in 1.8.3),
- the current limitations of @DeclareParents and @DeclareMixin
regarding generic interfaces.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
GitHub CI build: upgrade GabrielBB/xvfb-action to 1.6
CI builds started showing warnings as follows:
Node.js 12 actions are deprecated. For more information see:
https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.
Please update the following actions to use Node.js 16:
GabrielBB/xvfb-action@v1
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
This commit is a follow-up for 65f1ec72. The SOURCE retention case is
documented now and considered in a few more call sites. The
previously already similar code structures in
- DeclareAnnotation.ensureAnnotationDiscovered,
- DeclareAnnotation.getAnnotationType
have both been streamlined and still remain logically in sync.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
BCEL: use MAX_CP_ENTRIES from internal class, not from JRE
Instead of importing com.sun.org.apache.bcel.internal.Const, use
use org.aspectj.apache.bcel.Constants. The former class is from the
internal JRE module 'java.xml' which is not exposed by default.
Actually, no existing test failed because of it, but javadoc generation
for the AspectJ weaver.
Relates to #192.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Fix #366085 concerning declared annotations with source retention
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=366085.
See https://stackoverflow.com/q/74618269/1082681.
The issue described in the Bugzilla issue is about 'declare @type', but
similar issues also existed for 'declare @field', 'declare @method',
'declare @constructor'. This fix is rather superficial and leaves
things to be desired, because it is rather hacky and simply ignores
errors source retention annotation declarations during weaving. A better
fix would drop the corresponding declarations while parsing and also
issue compiler warnings in each case.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
See https://github.com/advisories/GHSA-97xg-phpr-rg8q.
See https://issues.apache.org/jira/browse/BCEL-363.
See https://github.com/apache/commons-bcel/pull/147.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
OutputSpec.matchesThisVm better supports version ranges
vmVersionRanges might be a single version like "9", a list of versions
like "1.2,1.3,1.4,1.5", an equivalent range of "1.2-1.5", an open range
like "-1.8", "9-" (equivalent to "9+") or a more complex list of ranges
like "-1.6,9-11,13-14,17-" or "8,11,16+".
Empty ranges like in "", " ", "8,,14", ",5", "6-," will be ignored.
I.e., they will not yield a positive match.
Bogus ranges like "9-11-14" will be ignored, too.
Existing XML test specs using '<line text="..." vm="v,v2,...,vn"/>
have been adjusted to use version ranges rather than long lists of
consecutive versions. Furthermore, ranges with a trailing '+' like '14+'
were replaced by using the new canonical format '14-', even though the
parser still correctly recognises '14+'.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
For now, only the "pattern matching for switch" tests from previews 1
and 2 were adjusted to work in preview 3, because guarded patterns were
replaced by 'when' clauses in 'switch' blocks. Therefore, existing test
classes did not compile anymore and had to be replaced by syntactically
upgraded versions with content merged from preview 1 and 2 classes.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Firstly, Batik is not needed for running AspectJ tests.
Secondly, the fixed Windows path separators led to GitHub CI/CD tests
failing under Java 18+ on GitHub. Replacing ';' by 'File.pathSeparator'
would have fixed the problem, but removing the paths altogether is the
cleaner solution.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Add docs/dist/LICENSE-AspectJ.html to all public artifacts
The license file will be included right in the main directory of both
binary and source artifacts for
- AspectJ Matcher,
- AspectJ Runtime,
- AspectJ Weaver,
- AspectJ Tools (Compiler),
- AspectJ Installer.
Fixes #185.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
This fixes a partial path traversal vulnerability.
Replaces `dir.getCanonicalPath().startsWith(parent.getCanonicalPath())`, which is vulnerable to partial path traversal attacks, with the more secure `dir.getCanonicalFile().toPath().startsWith(parent.getCanonicalFile().toPath())`.
To demonstrate this vulnerability, consider `"/usr/outnot".startsWith("/usr/out")`.
The check is bypassed although `/outnot` is not under the `/out` directory.
It's important to understand that the terminating slash may be removed when using various `String` representations of the `File` object.
For example, on Linux, `println(new File("/var"))` will print `/var`, but `println(new File("/var", "/")` will print `/var/`;
however, `println(new File("/var", "/").getCanonicalPath())` will print `/var`.
Weakness: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Severity: Medium
CVSSS: 6.1
Detection: CodeQL & OpenRewrite (https://public.moderne.io/recipes/org.openrewrite.java.security.PartialPathTraversalVulnerability)
Reported-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com> Signed-off-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>
Bug-tracker: https://github.com/JLLeitschuh/security-research/issues/13
In order to create the docs separately, running just a single module,
add 'install' to the previous build step, so the 'docs' module can find
the 'lib' dummy JAR in the local Maven repo.
Relates to #150.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
I have not used those directories or any files inside them at all. I
hope I am not taking away anything helpful from people who prefer
working with inter-linked Eclipse projects instead of Maven, but I think
we will notice if anyone complains and can revert in case of an
emergency.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Remove Aspectj.dev artifact and plugin repositories
After having removed the custom-built Maven Shade version, there should
be no more references to artifacts in that repository left. Let us see
if the build passes.
Furthermore, since being a committer, I can also attach AspectJ
installers to GitHub releases.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Bump Maven Shade Plugin to 3.3.0, add TODO to remove Flatten Maven Plugin
Fixed issues of concern include MSHADE-252, MSHADE-396, MSHADE-391.
TODO: MSHADE-36 is in Maven Shade 3.3.0 -> it should be possible to
include the dependency-reduced POM there directly. So maybe, we can rid
of Flatten Maven Plugin.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
POM bug: separate jvm.arg.allowSecurityManager from jvm.arg.addOpens
Before, this was in a single variable, and for JDK 18+, the security
manager setting also falsely overwrote the '--add-opens' command. This
was the root cause for a few dozen LTW tests to fail on JDK 18, if they
were not run in full LTW mode, i.e. in a separate JVM.
After this fix, it should be possible to revert the corresponding
commits, at least their non-cosmetic parts.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
AjcTestCase: be less verbose when appending to buffer repeatedly
Also put 'else (if)' and 'finally' on new lines rather than after the
preceding closing curly braces. This helps IDEs when using code folding
(show/hide content of code blocks enclosed in curly braces).
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Use upstream method to generate '--add-reads', '--add-exports' info
and copy it into our FileSystem instance. In order to be able to access
JDT Core's FileSystem.moduleUpdates field, we had to make it public
there first.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
At present, no tests are failing without those resources, but for good
measure, I added them anyway, because then the same path could in the
future also be used for stand-alone compilation tests which are not
triggered in-process via AJDT interface but, not unlike "full LTW"
test execution mode, in a separate JVM.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
projects / aspectj.git / log