Skip to content

Conversation

atsushieno
Copy link
Contributor

AndroidSupportComponents/percent/source has some build issues that
PercentFrameLayout.LayoutParams generates wrong constructors that take
java.lang.Object as an argument. For example, for this:
https://developer.android.com/reference/android/support/percent/PercentFrameLayout.LayoutParams.html#PercentFrameLayout.LayoutParams(android.view.ViewGroup.LayoutParams)

And they resulted in build errors (which was rather fortunate; it
could be worse that the method is successfully generated with
java.lang.Object while the actual type isn't...)

Where are those weird java.lang.Object from?

Surprisingly(?), it was not about failed type resolution, but this:
8dac926e

It hides nonpublic types up to java.lang.Object.

Why does it happen? Isn't android.view.ViewGroup.LayoutParams public?

It is. However, it was not treated as "public" - when it was loaded
via managed ACWs(!). Why? We were checking:

TypeDescription.IsPublic

whereas it should also check

TypeDescription.IsNestedPublic

... that's why it blew up to java.lang.Object which is (non-nested type).

Type iteration should also check GenBase.NestedTypes to load types
from DLLs. Hence another loader change.

AndroidSupportComponents/percent/source has some build issues that
PercentFrameLayout.LayoutParams generates wrong constructors that take
java.lang.Object as an argument. For example, for this:
https://developer.android.com/reference/android/support/percent/PercentFrameLayout.LayoutParams.html#PercentFrameLayout.LayoutParams(android.view.ViewGroup.LayoutParams)

And they resulted in build errors (which was rather fortunate; it
could be worse that the method is successfully generated with
java.lang.Object while the actual type isn't...)

Where are those weird java.lang.Object from?

Surprisingly(?), it was not about failed type resolution, but this:
dotnet@8dac926e

It hides nonpublic types up to java.lang.Object.

Why does it happen? Isn't android.view.ViewGroup.LayoutParams public?

It is. However, it was not treated as "public" - when it was loaded
via managed ACWs(!). Why? We were checking:

	TypeDescription.IsPublic

whereas it should also check

	TypeDescription.IsNestedPublic

... that's why it blew up to java.lang.Object which is (non-nested type).

Type iteration should also check GenBase.NestedTypes to load types
from DLLs. Hence another loader change.
@jonpryor jonpryor merged commit 29e4d9b into dotnet:master Nov 17, 2016
atsushieno added a commit that referenced this pull request Nov 17, 2016
AndroidSupportComponents/percent/source has some build issues that
PercentFrameLayout.LayoutParams generates wrong constructors that take
java.lang.Object as an argument. For example, for this:
https://developer.android.com/reference/android/support/percent/PercentFrameLayout.LayoutParams.html#PercentFrameLayout.LayoutParams(android.view.ViewGroup.LayoutParams)

And they resulted in build errors (which was rather fortunate; it
could be worse that the method is successfully generated with
java.lang.Object while the actual type isn't...)

Where are those weird java.lang.Object from?

Surprisingly(?), it was not about failed type resolution, but this:
8dac926e

It hides nonpublic types up to java.lang.Object.

Why does it happen? Isn't android.view.ViewGroup.LayoutParams public?

It is. However, it was not treated as "public" - when it was loaded
via managed ACWs(!). Why? We were checking:

	TypeDescription.IsPublic

whereas it should also check

	TypeDescription.IsNestedPublic

... that's why it blew up to java.lang.Object which is (non-nested type).

Type iteration should also check GenBase.NestedTypes to load types
from DLLs. Hence another loader change.
jonpryor added a commit to jonpryor/java.interop that referenced this pull request 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...63510cf

  * 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 to jonpryor/java.interop that referenced this pull request 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 pull request 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

Successfully merging this pull request may close these issues.

2 participants