Skip to content
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

Failing test disableaiaoptionworks on OSX #47492

Closed
runfoapp bot opened this issue Jan 26, 2021 · 9 comments · Fixed by #47766
Closed

Failing test disableaiaoptionworks on OSX #47492

runfoapp bot opened this issue Jan 26, 2021 · 9 comments · Fixed by #47766
Labels
area-System.Security bug disabled-test The test is disabled in source code against the issue os-mac-os-x macOS aka OSX

Comments

@runfoapp
Copy link

runfoapp bot commented Jan 26, 2021

Runfo Tracking Issue: Failing test disableaiaoptionworks on OSX

Build Definition Kind Run Name Console Core Dump Test Results Run Client
1065396 runtime PR 50478 net5.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open console.log test results runclient.py
1056062 runtime PR 50236 net6.0-windows-Release-x86-CoreCLR_release-Windows.10.Amd64.Server19H1.ES.Open
1046506 runtime PR 49336 net6.0-windows-Release-x86-CoreCLR_release-Windows.10.Amd64.Server19H1.ES.Open
1038929 runtime Rolling net5.0-OSX-Release-x64-CoreCLR_checked-OSX.1013.Amd64.Open console.log test results runclient.py
1034901 runtime PR 49512 net5.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open console.log test results runclient.py
1032466 runtime PR 49460 net5.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open console.log test results runclient.py
1030556 runtime Rolling net6.0-OSX-Release-x64-CoreCLR_release-OSX.1013.Amd64.Open
1018830 runtime PR 49006 net6.0-windows-Debug-x64-Mono_release-Windows.81.Amd64.Open
974982 runtime PR 47732 net5.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open console.log test results runclient.py
966776 runtime PR 47349 net6.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open
965921 runtime Rolling net6.0-OSX-Release-x64-Mono_release-OSX.1013.Amd64.Open
965355 runtime PR 47437 net6.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open
964682 runtime PR 47128 net6.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open
963077 runtime Rolling net6.0-OSX-Release-x64-CoreCLR_release-OSX.1013.Amd64.Open
962912 runtime PR 47359 net5.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open console.log test results runclient.py
961921 runtime Rolling net6.0-OSX-Release-x64-Mono_release-OSX.1013.Amd64.Open
961703 runtime PR 47149 net6.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open
961035 runtime PR 47125 net6.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open

Build Result Summary

Day Hit Count Week Hit Count Month Hit Count
0 0 4
@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Jan 26, 2021
@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@hoyosjs hoyosjs added area-System.Security blocking-clean-ci Blocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms' labels Jan 26, 2021
@ghost
Copy link

ghost commented Jan 26, 2021

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

Issue Details

Runfo Tracking Issue: Failing test disableaiaoptionworks on OSX

Build Definition Kind Run Name Console Core Dump Test Results Run Client
965921 runtime Rolling net6.0-OSX-Release-x64-Mono_release-OSX.1013.Amd64.Open
965355 runtime PR 47437 net6.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open
964682 runtime PR 47128 net6.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open
963077 runtime Rolling net6.0-OSX-Release-x64-CoreCLR_release-OSX.1013.Amd64.Open
962912 runtime PR 47359 net5.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open console.log test results runclient.py
961921 runtime Rolling net6.0-OSX-Release-x64-Mono_release-OSX.1013.Amd64.Open
961703 runtime PR 47149 net6.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open
961035 runtime PR 47125 net6.0-OSX-Debug-x64-CoreCLR_checked-OSX.1013.Amd64.Open

Build Result Summary

Day Hit Count Week Hit Count Month Hit Count
2 8 8
Author: runfoapp[bot]
Assignees: -
Labels:

area-System.Security, blocking-clean-ci, untriaged

Milestone: -

@hoyosjs hoyosjs added bug disabled-test The test is disabled in source code against the issue os-mac-os-x macOS aka OSX and removed untriaged New issue has not been triaged by the area owner blocking-clean-ci Blocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms' labels Jan 26, 2021
@vcsjones
Copy link
Member

Always failing here. Hmm.

Assert.False(chain.Build(endEntity), "Chain build with no intermediate, AIA disabled");

@vcsjones
Copy link
Member

vcsjones commented Jan 31, 2021

@bartonjs

I find a few things odd about this.

  1. The docs say:

    By default, network fetch of missing certificates is enabled if the trust evaluation includes the SSL policy. Otherwise it is disabled.

    My understanding of X509Chain is that it uses a Basic Policy, not a SSL policy.

  2. It seems that SecTrustSetNetworkFetchAllowed controls all network access during chain building, not just AIA. Meaning this, if I understand correctly, affects revocation checking. From Apple's source:

    if (!allowFetch) {
        status = SecTrustSetOptionInPolicies(trust->_policies, kSecPolicyCheckNoNetworkAccess, kCFBooleanTrue);
    } else {
        status = SecTrustRemoveOptionInPolicies(trust->_policies, kSecPolicyCheckNoNetworkAccess);
    }

    Along with this comment:

    The current SecTrustServer implementation doesn't distinguish between network
    access for revocation and network access for fetching.

    and if you look in SecPolicyCreateRevocation:

    if (revocationFlags & kSecRevocationNetworkAccessDisabled) {
    	CFDictionaryAddValue(options, kSecPolicyCheckNoNetworkAccess, kCFBooleanTrue);
    } else {
        /* If the caller didn't explicitly disable network access, the revocation policy
         * should override any other policy's network setting.
         * In particular, pairing a revocation policy with BasicX509 should result in
         * allowing network access for revocation unless explicitly disabled.
         * Note that SecTrustSetNetworkFetchAllowed can override even this. */
        CFDictionaryAddValue(options, kSecPolicyCheckNoNetworkAccess, kCFBooleanFalse);
    }

So, based on my understanding then, AIA and revocation fetching are internally controlled by a single flag on the policy, kSecPolicyCheckNoNetworkAccess. It seems... possible then that even if you disable AIA fetching, but want revocation checking, the revocation checking is going to re-enable AIA fetching anyway.

I wrote a quick test for this, and indeed, DisableCertificateDownloads also disables revocation checking.

        [Theory]
        [MemberData(nameof(AllViableRevocation))]
        public static void WhatIsEvenGoingOn(PkiOptions pkiOptions)
        {
            SimpleTest(
                pkiOptions,
                (root, intermediate, endEntity, holder, responder) =>
                {
                    DateTimeOffset now = DateTimeOffset.UtcNow;
                    intermediate.Revoke(endEntity, now);
                    holder.Chain.ChainPolicy.VerificationTime = now.AddSeconds(1).UtcDateTime;

                    // Remove the line below and the test will pass
                    holder.Chain.ChainPolicy.DisableCertificateDownloads = true;

                    SimpleRevocationBody(
                        holder,
                        endEntity,
                        rootRevoked: false,
                        issrRevoked: false,
                        leafRevoked: true);
                });
        }

@bartonjs
Copy link
Member

bartonjs commented Feb 1, 2021

I wrote a quick test for this, and indeed, DisableCertificateDownloads also disables revocation checking.

Well, revocation checking won't happen unless it can build a chain to a trust anchor. With AIA off is it completing the chain and just failing as RevocationStatusUnknown?

We can certainly, on macOS, say that if the revocation mode is Online that'll override DisableCertificateDownloads. Not the happiest of states, but it is two caller-controlled elements and probably doesn't come up much.

I guess now I'm confused as to why this ever worked.

@vcsjones
Copy link
Member

vcsjones commented Feb 1, 2021

@bartonjs

With AIA off is it completing the chain and just failing as RevocationStatusUnknown?

That appears to be the case. A complete chain is formed, revocation checking is still skipped.

Expected: X509ChainStatusFlags[] [NoError, NoError, Revoked]
Actual:   X509ChainStatusFlags[] [NoError, NoError, RevocationStatusUnknown]

I guess now I'm confused as to why this ever worked.

I'm still trying to get my head around what is happening. I am finding that the documentation around this is on the misleading side, and it's a bit slow going for me to dig through source code.

It seems to me, that (perhaps unrelated from this issue) this unearthed the issue that we should maybe change the macOS chain builder to ignore DisableCertificateDownloads if revocation checking is enabled.

@bartonjs
Copy link
Member

bartonjs commented Feb 1, 2021

That appears to be the case. A complete chain is formed, revocation checking is still skipped.

Ah, because I was helpful in SimpleTest. It is already adding the intermediate to chain.ChainPolicy.ExtraStore, so that's the "AIA not needed, but revocation gets impacted" test (maybe you knew that, but I had forgotten). Since I had not assumed that line, I expected a length 1 PartialChain result (though, thinking about it, I'm not sure why I would have assumed the root was in CustomTrustStore without the intermed being in ExtraStore... but that's what I did).

I am finding that the documentation around this is on the misleading side

Maybe it used to be only for AIA and they recently decided that obviously it should also apply to OCSP/CRL? The sudden pass rate change does suggest it was an OS change, not a .NET change, that triggered things. I'm pretty well aware of how easy it is for documentation to be out of date 😄.

@bartonjs
Copy link
Member

bartonjs commented Feb 1, 2021

With #47718 merged, I think the action left in this issue is to make the DisableCertificateDownloads test only check NoCheck revocation on macOS (and remove the activeissue attribute).

@vcsjones
Copy link
Member

vcsjones commented Feb 2, 2021

@bartonjs yeah, that's sensible. Will open a PR soon.

@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Feb 2, 2021
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Feb 2, 2021
@ghost ghost locked as resolved and limited conversation to collaborators May 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Security bug disabled-test The test is disabled in source code against the issue os-mac-os-x macOS aka OSX
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants