-
Notifications
You must be signed in to change notification settings - Fork 58
javac -parameters
support
#106
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
Comments
jonpryor
added a commit
to jonpryor/java.interop
that referenced
this issue
Dec 9, 2016
Fixes: dotnet#106 Java 8 adds support for a `javac -parameters` option, which adds a `MethodParameters` attribute to the `.class` file. The `MethodParameters` attribute blob contains *reliable* parameter names, including for abstract methods and interface methods, unlike existing `LocalVariableTable`, which only exists for `javac -g` builds, and only for methods with *bodies*, i.e. *not* abstract methods and interface methods. Add support for parsing the `MethodParameters` attribute blob.
jonpryor
added a commit
that referenced
this issue
Jan 3, 2017
…107) Fixes: #106 Java 8 adds support for a `javac -parameters` option, which adds a `MethodParameters` attribute to the `.class` file. The `MethodParameters` attribute blob contains *reliable* parameter names, including for abstract methods and interface methods, unlike existing `LocalVariableTable`, which only exists for `javac -g` builds, and only for methods with *bodies*, i.e. *not* abstract methods and interface methods. Add support for parsing the `MethodParameters` attribute blob.
jonpryor
added a commit
to jonpryor/java.interop
that referenced
this issue
Feb 9, 2021
Context: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 Context: https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/ Context: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/12676/ncident-help-for-Substitution-attack-risk-from-multiple-package-feeds Changes: dotnet/android-tools@26d65d9...479931c * dotnet/android-tools@479931c [build] Move global.json file to root directory (dotnet#106) * dotnet/android-tools@63510cf: [ci] Update packageSources in NuGet.config (dotnet#105) * dotnet/android-tools@83ed0a4: Bump ta xamarin/LibZipSharp/1.0.22@9f563dd1 (dotnet#104) * dotnet/android-tools@8ea78a4: Add Microsoft.Android.Build.BaseTasks project (dotnet#101) * dotnet/android-tools@b2d9fdf: [NDK] Locate and select only compatible NDK versions (dotnet#103) * dotnet/android-tools@5ff1702: [tests] Use dotnet test to run AndroidSdk-Tests (dotnet#102) * dotnet/android-tools@ad80a42: [ci] Use the new "main" default branch (dotnet#100) There is a Package Substitution Attack inherent in NuGet, whereby if multiple package sources provide packages with the same name, it is *indeterminate* which package source will provide the package. For example, consider the [`XliffTasks` package][0], currently provided from the [`dotnet-eng`][1] feed, and *not* present in the NuGet.org feed. If a "hostile attacker" submits an `XliffTasks` package to NuGet.org, then we don't know, and cannot control, whether the build will use the "hostile" `XliffTasks` package from NuGet.org or the "desired" package from `dotnet-eng`. There are two ways to prevent this attack: 1. Use `//packageSources/clear` and have *only one* `//packageSources/add` entry in `NuGet.config` 2. Use `//packageSources/clear` and *fully trust* every `//packageSources/add` entry in `NuGet.config`. `NuGet.org` *cannot* be a trusted source, nor can any feed location which allows "anyone" to add new packages, nor can a feed which itself contains [upstream sources][2]. As the `XliffTasks` package is *not* in `NuGet.org`, option (1) isn't an option. Go with option (2), using the existing `dotnet-eng` source and the new *trusted* [`dotnet-public`][3] package source. [0]: https://github.com/dotnet/xliff-tasks [1]: https://dev.azure.com/dnceng/public/_packaging?_a=feed&feed=dotnet-eng [2]: https://docs.microsoft.com/en-us/azure/devops/artifacts/concepts/upstream-sources?view=azure-devops [3]: https://dev.azure.com/dnceng/public/_packaging?_a=feed&feed=dotnet-public
jonpryor
added a commit
that referenced
this issue
Feb 9, 2021
…796) Context: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 Context: https://azure.microsoft.com/en-us/resources/3-ways-to-mitigate-risk-using-private-package-feeds/ Context: https://devdiv.visualstudio.com/DevDiv/_wiki/wikis/DevDiv.wiki/12676/ncident-help-for-Substitution-attack-risk-from-multiple-package-feeds Changes: dotnet/android-tools@26d65d9...479931c * dotnet/android-tools@479931c [build] Move global.json file to root directory (#106) * dotnet/android-tools@63510cf: [ci] Update packageSources in NuGet.config (#105) * dotnet/android-tools@83ed0a4: Bump ta xamarin/LibZipSharp/1.0.22@9f563dd1 (#104) * dotnet/android-tools@8ea78a4: Add Microsoft.Android.Build.BaseTasks project (#101) * dotnet/android-tools@b2d9fdf: [NDK] Locate and select only compatible NDK versions (#103) * dotnet/android-tools@5ff1702: [tests] Use dotnet test to run AndroidSdk-Tests (#102) * dotnet/android-tools@ad80a42: [ci] Use the new "main" default branch (#100) There is a Package Substitution Attack inherent in NuGet, whereby if multiple package sources provide packages with the same name, it is *indeterminate* which package source will provide the package. For example, consider the [`XliffTasks` package][0], currently provided from the [`dotnet-eng`][1] feed, and *not* present in the NuGet.org feed. If a "hostile attacker" submits an `XliffTasks` package to NuGet.org, then we don't know, and cannot control, whether the build will use the "hostile" `XliffTasks` package from NuGet.org or the "desired" package from `dotnet-eng`. There are two ways to prevent this attack: 1. Use `//packageSources/clear` and have *only one* `//packageSources/add` entry in `NuGet.config` 2. Use `//packageSources/clear` and *fully trust* every `//packageSources/add` entry in `NuGet.config`. `NuGet.org` *cannot* be a trusted source, nor can any feed location which allows "anyone" to add new packages, nor can a feed which itself contains [upstream sources][2]. As the `XliffTasks` package is *not* in `NuGet.org`, option (1) isn't an option. Go with option (2), using the existing `dotnet-eng` source and the new *trusted* [`dotnet-public`][3] package source. [0]: https://github.com/dotnet/xliff-tasks [1]: https://dev.azure.com/dnceng/public/_packaging?_a=feed&feed=dotnet-eng [2]: https://docs.microsoft.com/en-us/azure/devops/artifacts/concepts/upstream-sources?view=azure-devops [3]: https://dev.azure.com/dnceng/public/_packaging?_a=feed&feed=dotnet-public
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Java 8's
javac
now supports storing method parameter name information within.class
files, using thejavac -parameters
option. Consider the following Java code:If we compile with:
We can see that there's a new
MethodParameters
metadata blob:class-parse
needs support for the newMethodParameters
Attribute blob:The text was updated successfully, but these errors were encountered: