Fix build break on linux-armel

[jkotas]

No description provided.

[Copilot]

Pull Request Overview

This PR suppresses unused-parameter warnings for DSA parameters on Linux ARMEL to fix a build break.

• Adds void casts for hasSeed and hasSecretKey in CryptoNative_MLDsaGetPalId.

[jkotas]

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1046111&view=logs&jobId=2eda3965-9146-55d1-4226-c3d3f8432d8f&j=2eda3965-9146-55d1-4226-c3d3f8432d8f&t=27bbe0a6-6c05-550a-bc6f-305cf5eac8aa

 [ 10%] Building C object /__w/1/s/artifacts/obj/external/libunwind/CMakeFiles/libunwind.dir/__w/1/s/src/native/external/libunwind/src/arm/Linit_local.c.o
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:85: error: unused parameter 'hasSeed' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:103: error: unused parameter 'hasSecretKey' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
2 errors generated.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

The linux-armel leg didn't run in the original PR and is skipped in this one too. Should we be including src/native/libs/System.Security.Cryptography.Native/* in the paths for coreclr changes?

runtime/eng/pipelines/common/evaluate-default-paths.yml

Lines 84 to 90 in 6d3b842

	- subset: coreclr
	include:
	- src/libraries/System.Private.CoreLib/*
	- src/native/libs/Common/*
	- src/native/libs/System.Globalization.Native/*
	- src/native/libs/System.IO.Compression.Native/*
	exclude:

It is only used on non-Windows, so it might be broader than necessary - but I don't think our path evaluation makes that distinction.

[bartonjs]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

[jkotas]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

I think that the crux of the problem is that we have tiered validation system and that we do not expect to catch all breaks in the CI early. The question is whether catching this specific build break early is worth the extra CI cost, time and flakiness on many PRs.

I went back and forth on this. If we want to do something about this, it is best to do that in a separate PR.

[bartonjs]

and flakiness

Yeah, that's why I walked it back to saying my interest is about "build", not "test".

The question is whether catching this specific build break early is worth the extra CI cost

I think it's rare enough that "no" is a fine answer. I'm more saying if something is done, it is about "build everywhere", and that if we think running tests are relevant we should run the relevant tests (in this case, it'd be a libraries concern, not a CLR concern).

If we want to do something about this, it is best to do that in a separate PR.

I agree.

[elinor-fung]

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

Part of this is that the coreclr subset includes singlefilehost, which pulls in the src/native/libs - so in that sense, it is the build portion (I think the specific leg that would have hit this only builds). But yeah, if we do something here, we probably want a build vs test distinction.

If we want to do something about this, it is best to do that in a separate PR.

Agreed

[jkotas]

No description provided.

[Copilot]

Pull Request Overview

This PR suppresses unused-parameter warnings for DSA parameters on Linux ARMEL to fix a build break.

• Adds void casts for hasSeed and hasSecretKey in CryptoNative_MLDsaGetPalId.

[jkotas]

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1046111&view=logs&jobId=2eda3965-9146-55d1-4226-c3d3f8432d8f&j=2eda3965-9146-55d1-4226-c3d3f8432d8f&t=27bbe0a6-6c05-550a-bc6f-305cf5eac8aa

 [ 10%] Building C object /__w/1/s/artifacts/obj/external/libunwind/CMakeFiles/libunwind.dir/__w/1/s/src/native/external/libunwind/src/arm/Linit_local.c.o
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:85: error: unused parameter 'hasSeed' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:103: error: unused parameter 'hasSecretKey' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
2 errors generated.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

The linux-armel leg didn't run in the original PR and is skipped in this one too. Should we be including src/native/libs/System.Security.Cryptography.Native/* in the paths for coreclr changes?

runtime/eng/pipelines/common/evaluate-default-paths.yml

Lines 84 to 90 in 6d3b842

	- subset: coreclr
	include:
	- src/libraries/System.Private.CoreLib/*
	- src/native/libs/Common/*
	- src/native/libs/System.Globalization.Native/*
	- src/native/libs/System.IO.Compression.Native/*
	exclude:

It is only used on non-Windows, so it might be broader than necessary - but I don't think our path evaluation makes that distinction.

[bartonjs]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

[jkotas]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

I think that the crux of the problem is that we have tiered validation system and that we do not expect to catch all breaks in the CI early. The question is whether catching this specific build break early is worth the extra CI cost, time and flakiness on many PRs.

I went back and forth on this. If we want to do something about this, it is best to do that in a separate PR.

[bartonjs]

and flakiness

Yeah, that's why I walked it back to saying my interest is about "build", not "test".

The question is whether catching this specific build break early is worth the extra CI cost

I think it's rare enough that "no" is a fine answer. I'm more saying if something is done, it is about "build everywhere", and that if we think running tests are relevant we should run the relevant tests (in this case, it'd be a libraries concern, not a CLR concern).

If we want to do something about this, it is best to do that in a separate PR.

I agree.

[elinor-fung]

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

Part of this is that the coreclr subset includes singlefilehost, which pulls in the src/native/libs - so in that sense, it is the build portion (I think the specific leg that would have hit this only builds). But yeah, if we do something here, we probably want a build vs test distinction.

If we want to do something about this, it is best to do that in a separate PR.

Agreed

[jkotas]

No description provided.

[Copilot]

Pull Request Overview

This PR suppresses unused-parameter warnings for DSA parameters on Linux ARMEL to fix a build break.

• Adds void casts for hasSeed and hasSecretKey in CryptoNative_MLDsaGetPalId.

[jkotas]

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1046111&view=logs&jobId=2eda3965-9146-55d1-4226-c3d3f8432d8f&j=2eda3965-9146-55d1-4226-c3d3f8432d8f&t=27bbe0a6-6c05-550a-bc6f-305cf5eac8aa

 [ 10%] Building C object /__w/1/s/artifacts/obj/external/libunwind/CMakeFiles/libunwind.dir/__w/1/s/src/native/external/libunwind/src/arm/Linit_local.c.o
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:85: error: unused parameter 'hasSeed' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:103: error: unused parameter 'hasSecretKey' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
2 errors generated.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

The linux-armel leg didn't run in the original PR and is skipped in this one too. Should we be including src/native/libs/System.Security.Cryptography.Native/* in the paths for coreclr changes?

runtime/eng/pipelines/common/evaluate-default-paths.yml

Lines 84 to 90 in 6d3b842

	- subset: coreclr
	include:
	- src/libraries/System.Private.CoreLib/*
	- src/native/libs/Common/*
	- src/native/libs/System.Globalization.Native/*
	- src/native/libs/System.IO.Compression.Native/*
	exclude:

It is only used on non-Windows, so it might be broader than necessary - but I don't think our path evaluation makes that distinction.

[bartonjs]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

[jkotas]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

I think that the crux of the problem is that we have tiered validation system and that we do not expect to catch all breaks in the CI early. The question is whether catching this specific build break early is worth the extra CI cost, time and flakiness on many PRs.

I went back and forth on this. If we want to do something about this, it is best to do that in a separate PR.

[bartonjs]

and flakiness

Yeah, that's why I walked it back to saying my interest is about "build", not "test".

The question is whether catching this specific build break early is worth the extra CI cost

I think it's rare enough that "no" is a fine answer. I'm more saying if something is done, it is about "build everywhere", and that if we think running tests are relevant we should run the relevant tests (in this case, it'd be a libraries concern, not a CLR concern).

If we want to do something about this, it is best to do that in a separate PR.

I agree.

[elinor-fung]

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

Part of this is that the coreclr subset includes singlefilehost, which pulls in the src/native/libs - so in that sense, it is the build portion (I think the specific leg that would have hit this only builds). But yeah, if we do something here, we probably want a build vs test distinction.

If we want to do something about this, it is best to do that in a separate PR.

Agreed

[jkotas]

No description provided.

[Copilot]

Pull Request Overview

This PR suppresses unused-parameter warnings for DSA parameters on Linux ARMEL to fix a build break.

• Adds void casts for hasSeed and hasSecretKey in CryptoNative_MLDsaGetPalId.

[jkotas]

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1046111&view=logs&jobId=2eda3965-9146-55d1-4226-c3d3f8432d8f&j=2eda3965-9146-55d1-4226-c3d3f8432d8f&t=27bbe0a6-6c05-550a-bc6f-305cf5eac8aa

 [ 10%] Building C object /__w/1/s/artifacts/obj/external/libunwind/CMakeFiles/libunwind.dir/__w/1/s/src/native/external/libunwind/src/arm/Linit_local.c.o
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:85: error: unused parameter 'hasSeed' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:103: error: unused parameter 'hasSecretKey' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
2 errors generated.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

The linux-armel leg didn't run in the original PR and is skipped in this one too. Should we be including src/native/libs/System.Security.Cryptography.Native/* in the paths for coreclr changes?

runtime/eng/pipelines/common/evaluate-default-paths.yml

Lines 84 to 90 in 6d3b842

	- subset: coreclr
	include:
	- src/libraries/System.Private.CoreLib/*
	- src/native/libs/Common/*
	- src/native/libs/System.Globalization.Native/*
	- src/native/libs/System.IO.Compression.Native/*
	exclude:

It is only used on non-Windows, so it might be broader than necessary - but I don't think our path evaluation makes that distinction.

[bartonjs]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

[jkotas]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

I think that the crux of the problem is that we have tiered validation system and that we do not expect to catch all breaks in the CI early. The question is whether catching this specific build break early is worth the extra CI cost, time and flakiness on many PRs.

I went back and forth on this. If we want to do something about this, it is best to do that in a separate PR.

[bartonjs]

and flakiness

Yeah, that's why I walked it back to saying my interest is about "build", not "test".

The question is whether catching this specific build break early is worth the extra CI cost

I think it's rare enough that "no" is a fine answer. I'm more saying if something is done, it is about "build everywhere", and that if we think running tests are relevant we should run the relevant tests (in this case, it'd be a libraries concern, not a CLR concern).

If we want to do something about this, it is best to do that in a separate PR.

I agree.

[elinor-fung]

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

Part of this is that the coreclr subset includes singlefilehost, which pulls in the src/native/libs - so in that sense, it is the build portion (I think the specific leg that would have hit this only builds). But yeah, if we do something here, we probably want a build vs test distinction.

If we want to do something about this, it is best to do that in a separate PR.

Agreed

[jkotas]

No description provided.

[Copilot]

Pull Request Overview

This PR suppresses unused-parameter warnings for DSA parameters on Linux ARMEL to fix a build break.

• Adds void casts for hasSeed and hasSecretKey in CryptoNative_MLDsaGetPalId.

[jkotas]

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1046111&view=logs&jobId=2eda3965-9146-55d1-4226-c3d3f8432d8f&j=2eda3965-9146-55d1-4226-c3d3f8432d8f&t=27bbe0a6-6c05-550a-bc6f-305cf5eac8aa

 [ 10%] Building C object /__w/1/s/artifacts/obj/external/libunwind/CMakeFiles/libunwind.dir/__w/1/s/src/native/external/libunwind/src/arm/Linit_local.c.o
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:85: error: unused parameter 'hasSeed' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:103: error: unused parameter 'hasSecretKey' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
2 errors generated.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

The linux-armel leg didn't run in the original PR and is skipped in this one too. Should we be including src/native/libs/System.Security.Cryptography.Native/* in the paths for coreclr changes?

runtime/eng/pipelines/common/evaluate-default-paths.yml

Lines 84 to 90 in 6d3b842

	- subset: coreclr
	include:
	- src/libraries/System.Private.CoreLib/*
	- src/native/libs/Common/*
	- src/native/libs/System.Globalization.Native/*
	- src/native/libs/System.IO.Compression.Native/*
	exclude:

It is only used on non-Windows, so it might be broader than necessary - but I don't think our path evaluation makes that distinction.

[bartonjs]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

[jkotas]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

I think that the crux of the problem is that we have tiered validation system and that we do not expect to catch all breaks in the CI early. The question is whether catching this specific build break early is worth the extra CI cost, time and flakiness on many PRs.

I went back and forth on this. If we want to do something about this, it is best to do that in a separate PR.

[bartonjs]

and flakiness

Yeah, that's why I walked it back to saying my interest is about "build", not "test".

The question is whether catching this specific build break early is worth the extra CI cost

I think it's rare enough that "no" is a fine answer. I'm more saying if something is done, it is about "build everywhere", and that if we think running tests are relevant we should run the relevant tests (in this case, it'd be a libraries concern, not a CLR concern).

If we want to do something about this, it is best to do that in a separate PR.

I agree.

[elinor-fung]

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

Part of this is that the coreclr subset includes singlefilehost, which pulls in the src/native/libs - so in that sense, it is the build portion (I think the specific leg that would have hit this only builds). But yeah, if we do something here, we probably want a build vs test distinction.

If we want to do something about this, it is best to do that in a separate PR.

Agreed

[jkotas]

No description provided.

[Copilot]

Pull Request Overview

This PR suppresses unused-parameter warnings for DSA parameters on Linux ARMEL to fix a build break.

• Adds void casts for hasSeed and hasSecretKey in CryptoNative_MLDsaGetPalId.

[jkotas]

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1046111&view=logs&jobId=2eda3965-9146-55d1-4226-c3d3f8432d8f&j=2eda3965-9146-55d1-4226-c3d3f8432d8f&t=27bbe0a6-6c05-550a-bc6f-305cf5eac8aa

 [ 10%] Building C object /__w/1/s/artifacts/obj/external/libunwind/CMakeFiles/libunwind.dir/__w/1/s/src/native/external/libunwind/src/arm/Linit_local.c.o
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:85: error: unused parameter 'hasSeed' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:103: error: unused parameter 'hasSecretKey' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
2 errors generated.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

The linux-armel leg didn't run in the original PR and is skipped in this one too. Should we be including src/native/libs/System.Security.Cryptography.Native/* in the paths for coreclr changes?

runtime/eng/pipelines/common/evaluate-default-paths.yml

Lines 84 to 90 in 6d3b842

	- subset: coreclr
	include:
	- src/libraries/System.Private.CoreLib/*
	- src/native/libs/Common/*
	- src/native/libs/System.Globalization.Native/*
	- src/native/libs/System.IO.Compression.Native/*
	exclude:

It is only used on non-Windows, so it might be broader than necessary - but I don't think our path evaluation makes that distinction.

[bartonjs]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

[jkotas]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

I think that the crux of the problem is that we have tiered validation system and that we do not expect to catch all breaks in the CI early. The question is whether catching this specific build break early is worth the extra CI cost, time and flakiness on many PRs.

I went back and forth on this. If we want to do something about this, it is best to do that in a separate PR.

[bartonjs]

and flakiness

Yeah, that's why I walked it back to saying my interest is about "build", not "test".

The question is whether catching this specific build break early is worth the extra CI cost

I think it's rare enough that "no" is a fine answer. I'm more saying if something is done, it is about "build everywhere", and that if we think running tests are relevant we should run the relevant tests (in this case, it'd be a libraries concern, not a CLR concern).

If we want to do something about this, it is best to do that in a separate PR.

I agree.

[elinor-fung]

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

Part of this is that the coreclr subset includes singlefilehost, which pulls in the src/native/libs - so in that sense, it is the build portion (I think the specific leg that would have hit this only builds). But yeah, if we do something here, we probably want a build vs test distinction.

If we want to do something about this, it is best to do that in a separate PR.

Agreed

[jkotas]

No description provided.

[Copilot]

Pull Request Overview

This PR suppresses unused-parameter warnings for DSA parameters on Linux ARMEL to fix a build break.

• Adds void casts for hasSeed and hasSecretKey in CryptoNative_MLDsaGetPalId.

[jkotas]

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1046111&view=logs&jobId=2eda3965-9146-55d1-4226-c3d3f8432d8f&j=2eda3965-9146-55d1-4226-c3d3f8432d8f&t=27bbe0a6-6c05-550a-bc6f-305cf5eac8aa

 [ 10%] Building C object /__w/1/s/artifacts/obj/external/libunwind/CMakeFiles/libunwind.dir/__w/1/s/src/native/external/libunwind/src/arm/Linit_local.c.o
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:85: error: unused parameter 'hasSeed' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:103: error: unused parameter 'hasSecretKey' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
2 errors generated.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

The linux-armel leg didn't run in the original PR and is skipped in this one too. Should we be including src/native/libs/System.Security.Cryptography.Native/* in the paths for coreclr changes?

runtime/eng/pipelines/common/evaluate-default-paths.yml

Lines 84 to 90 in 6d3b842

	- subset: coreclr
	include:
	- src/libraries/System.Private.CoreLib/*
	- src/native/libs/Common/*
	- src/native/libs/System.Globalization.Native/*
	- src/native/libs/System.IO.Compression.Native/*
	exclude:

It is only used on non-Windows, so it might be broader than necessary - but I don't think our path evaluation makes that distinction.

[bartonjs]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

[jkotas]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

I think that the crux of the problem is that we have tiered validation system and that we do not expect to catch all breaks in the CI early. The question is whether catching this specific build break early is worth the extra CI cost, time and flakiness on many PRs.

I went back and forth on this. If we want to do something about this, it is best to do that in a separate PR.

[bartonjs]

and flakiness

Yeah, that's why I walked it back to saying my interest is about "build", not "test".

The question is whether catching this specific build break early is worth the extra CI cost

I think it's rare enough that "no" is a fine answer. I'm more saying if something is done, it is about "build everywhere", and that if we think running tests are relevant we should run the relevant tests (in this case, it'd be a libraries concern, not a CLR concern).

If we want to do something about this, it is best to do that in a separate PR.

I agree.

[elinor-fung]

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

Part of this is that the coreclr subset includes singlefilehost, which pulls in the src/native/libs - so in that sense, it is the build portion (I think the specific leg that would have hit this only builds). But yeah, if we do something here, we probably want a build vs test distinction.

If we want to do something about this, it is best to do that in a separate PR.

Agreed

[jkotas]

No description provided.

[Copilot]

Pull Request Overview

This PR suppresses unused-parameter warnings for DSA parameters on Linux ARMEL to fix a build break.

• Adds void casts for hasSeed and hasSecretKey in CryptoNative_MLDsaGetPalId.

[jkotas]

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1046111&view=logs&jobId=2eda3965-9146-55d1-4226-c3d3f8432d8f&j=2eda3965-9146-55d1-4226-c3d3f8432d8f&t=27bbe0a6-6c05-550a-bc6f-305cf5eac8aa

 [ 10%] Building C object /__w/1/s/artifacts/obj/external/libunwind/CMakeFiles/libunwind.dir/__w/1/s/src/native/external/libunwind/src/arm/Linit_local.c.o
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:85: error: unused parameter 'hasSeed' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
/__w/1/s/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey_ml_dsa.c:10:103: error: unused parameter 'hasSecretKey' [-Werror,-Wunused-parameter]
10 | int32_t CryptoNative_MLDsaGetPalId(const EVP_PKEY* pKey, int32_t* mldsaId, int32_t* hasSeed, int32_t* hasSecretKey)
| ^
2 errors generated.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

The linux-armel leg didn't run in the original PR and is skipped in this one too. Should we be including src/native/libs/System.Security.Cryptography.Native/* in the paths for coreclr changes?

runtime/eng/pipelines/common/evaluate-default-paths.yml

Lines 84 to 90 in 6d3b842

	- subset: coreclr
	include:
	- src/libraries/System.Private.CoreLib/*
	- src/native/libs/Common/*
	- src/native/libs/System.Globalization.Native/*
	- src/native/libs/System.IO.Compression.Native/*
	exclude:

It is only used on non-Windows, so it might be broader than necessary - but I don't think our path evaluation makes that distinction.

[bartonjs]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

[jkotas]

That might be the most expedient fix; but I think really it means that there should be a configuration group ("thing") that runs the libraries tests on "all relevant architectures" for any change under src/native/libs/.

I think that the crux of the problem is that we have tiered validation system and that we do not expect to catch all breaks in the CI early. The question is whether catching this specific build break early is worth the extra CI cost, time and flakiness on many PRs.

I went back and forth on this. If we want to do something about this, it is best to do that in a separate PR.

[bartonjs]

and flakiness

Yeah, that's why I walked it back to saying my interest is about "build", not "test".

The question is whether catching this specific build break early is worth the extra CI cost

I think it's rare enough that "no" is a fine answer. I'm more saying if something is done, it is about "build everywhere", and that if we think running tests are relevant we should run the relevant tests (in this case, it'd be a libraries concern, not a CLR concern).

If we want to do something about this, it is best to do that in a separate PR.

I agree.

[elinor-fung]

The CLR tests aren't really relevant to this change... they just happen to be the only group that causes the armel build to run.

And, really, it's not so much the "run tests" as "build". So any change under src/native/ really seems like it should be "build everywhere".

Part of this is that the coreclr subset includes singlefilehost, which pulls in the src/native/libs - so in that sense, it is the build portion (I think the specific leg that would have hit this only builds). But yeah, if we do something here, we probably want a build vs test distinction.

If we want to do something about this, it is best to do that in a separate PR.

Agreed