Skip to content

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

Closed
jonpryor opened this issue Dec 8, 2016 · 0 comments
Closed

javac -parameters support #106

jonpryor opened this issue Dec 8, 2016 · 0 comments

Comments

@jonpryor
Copy link
Contributor

jonpryor commented Dec 8, 2016

Java 8's javac now supports storing method parameter name information within .class files, using the javac -parameters option. Consider the following Java code:

class f {
	public void m (String a, int b, int[] c) {
	}
}

If we compile with:

javac -parameters f.java

We can see that there's a new MethodParameters metadata blob:

$ mono class-parse.exe f.class --dump
...
        10: Utf8("MethodParameters")
...
        1: m (Ljava/lang/String;I[I)V Public
                Code(1, Unknown[LineNumberTable](6))
                Unknown[MethodParameters](13)

class-parse needs support for the new MethodParameters Attribute blob:

MethodParameters_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u1 parameters_count;
    {   u2 name_index;
        u2 access_flags;
    } parameters[parameters_count];
}
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
@github-actions github-actions bot locked and limited conversation to collaborators Apr 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant