+ abdulsyed@ due to M70 regression.

Issue 896272 has been merged into this issue.

Debugging this without hardware to work with is difficult. Would someone running into this be willing to do a bisect? You would need to have Python installed on your machine:
https://www.python.org/downloads/release/python-2715/

The instructions are here:
https://www.chromium.org/developers/bisect-builds-py

Use the command:
python bisect-builds.py -a win64 -g 561733 -b 587811

That will check changes between Chrome 68 and 70. It'll successfully launch different builds of Chromium. In each, check if the issue occurs or not, close the window, and type whether it was good (issue did not occur) or bad (issue did occur). When it's done, paste the output here.

Thanks!

I can narrow that down a litte: I have 70.0.3504.0 on Win7, still showing the PIN entry form; so I guess the problem must have been introduced somewhere between 70.0.3504.0 (mine) and 70.0.3534.4 (reporter's).

Hey!
The "stable" ver. 70.x.x takes the same issue within!!
The problem has not been solved at all!
Many lawyers like me are reporting the same problem in the Facebook lawyers group "PCT Civilian Telematic Process" at https://goo.gl/Q6umy1
Please solve it, it's very serious!

Hello,
I did a bisect as requested. (on a 32-bit machine though)
You are probably looking for a change made after 581046 (known good), but no later than 581074 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/cff971dad65e4a2b31aff297dca32955269b2a3f..e64c72b93c42763e3adc6ff37568737400bb33f2

Deleted: PINentry_chrome_bisect.txt 3.1 KB

PINentry_chrome_bisect.txt 3.1 KB View Download

Could it be: https://chromium.googlesource.com/chromium/src/+/58443848dec954f3ae041db1f70e0342df460c6b since this is Windows 7 only. I believe there were reports that it is working on Windows 10 fine.

 Issue 897081  has been merged into this issue.

" I believe there were reports that it is working on Windows 10 fine."
I can confirm this, works fine on all our Windows 10 systems, and only Windows 7 users are reporting this issue. (But that's estimated still over a million users)

re: 58443848dec954f3ae041db1f70e0342df460c6b that CL would only make a difference if the smart card provider was DLL planting in Chrome's install directory - which they really should not be doing. Can the reporter check for DLLs in chrome's executable directory? This can be found by going to chrome://version and looking for "Executable Path" field, then doing a 'dir' in that directory. There should just no DLLs in there, just one (or maybe two, if you have an update pending) executable files: chrome.exe (and maybe new_chrome.exe).

oh the system with the issue, can you paste the contents of chrome://conflicts ?

Just to clarify; The dialog being shown is this one: (comming from Windows)
https://docs.microsoft.com/en-us/windows-hardware/drivers/smartcard/card-pin-operations#span-idsecretpurposespanspan-idsecretpurposespansecretpurpose

Here is the content of chrome://conflicts

Deleted: chrome_conflicts.txt 16.9 KB

chrome_conflicts.txt 16.9 KB View Download

And of the chrome 70 dir (previous one was of older version)

Deleted: chrome70_content.png 14.3 KB

	chrome70_content.png 14.3 KB View Download

I can't see obviously why this would be failing. to be honest I'm not sure what "digital sign key Windows" is. What exact steps do we need to take here to reproduce this issue in the lab?

perhaps gather a chrome://conflicts window from the working version of Chrome (68) and paste it here, then I can compare to see if there is any difference in the modules that are loaded.

Also, can you paste the "Variations" from your chrome://version from the non-working Chrome 70? Thanks.

> What exact steps do we need to take here to reproduce this issue in the lab?

Essentially, you need something that adds certificates to the Windows certificate store through a minidriver for the BaseCSP:

https://www.microsoft.com/en-us/download/details.aspx?id=18152
https://docs.microsoft.com/en-us/windows/desktop/SecCrypto/microsoft-base-cryptographic-provider

Make sure that the minidriver requires a PIN code for access to the certificate's private key.

Then try to log on to a website with a certificate that is provided by that minidriver.

How to stop notifications emails?

Il giorno ven 19 ott 2018 alle ore 17:50 wverhe… via monorail <
monorail+v2.3584018964@chromium.org> ha scritto:

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Here's my screenshot of my Chrome's executable directory:

Deleted: Content.jpg 55.3 KB

	Content.jpg 55.3 KB View Download

And here's the content of my chrome://conflicts :

Deleted: chrome_conflicts.txt 22.9 KB

chrome_conflicts.txt 22.9 KB View Download

@Comment 38 - To unsubscribe from notification emails, please visit the bug page directly, then click the "star" icon in the top left (it should switch from blue to transparent).

---

Adding the gTech hotlist as this also surfaced on our Italian Chrome community:

- https://productforums.google.com/forum/#!msg/chrome-it/QLVqVyO1Z9A/pTGTk6ZJAAAJ

Thanks!

I do not see any star. How to visit bug directly?

Il 19/10/2018 18:37, craigtum… via monorail ha scritto:

@Comment 43 - Here's a direct link to the bug:  https://crbug.com/880835 

Alternatively you can also manage your preferences here: https://bugs.chromium.org/hosting/settings

it would be really useful to get a copy of chrome://conflicts from when this was working (M68? - or before the bisect in comment 25 starts to fail) vs the copy of chrome://conflicts after. Comparing the two would see if there is a DLL needed for the CSP failing to load somehow.

Additionally, is this an issue with a smartcard, or also the default Microsoft software provider?

 Issue 896688  has been merged into this issue.

Setting Needs-Feedback. There are a number of outstanding requests on this bug. Folks, could we have:

1. chrome://conflicts both when this was working AND when it's not working. Also please make sure chrome://conflicts is captured AFTER attempting to use the key.

2. Is this an issue with a smartcard or also the default Microsoft software provider? Which smartcard and driver?

3. Can you paste the "Variations" from your chrome://version from the non-working Chrome 70?

Thanks, all!

For query number 3, you can find your answer in  Issue 896688 .

The screenshot covers up the Variations field. :-P Could you include the whole thing? Thanks! Answers to (1) and (2) would also be useful.

Hey all,

Chiming in from the gTech side with some of the listnr reports we've received in case they're useful:

- https://listnr.corp.google.com/report/85733011068
- https://listnr.corp.google.com/report/85732950577
- https://listnr.corp.google.com/report/85732750441
- https://listnr.corp.google.com/report/85732744112
- https://listnr.corp.google.com/report/85732726520
- https://listnr.corp.google.com/report/85732608383
- https://listnr.corp.google.com/report/85732575580

Unfortunately we don't have a clear idea of the percentage increase in volume =\

Thanks!

What we need is an answer to the questions in comment #48.

Hoping this is what #48 is looking for - from my non-working Chrome.
We use ActivIdentity's ActivClient as the middleware for smartcard authentication.


Google Chrome	70.0.3538.67 (Official Build) beta (64-bit) (cohort: Beta)
Revision	9ab0cfab84ded083718d3a4ff830726efd38869f-refs/branch-heads/3538@{#1002}
OS	Windows
JavaScript	V8 7.0.276.28

Variations	411b6d4e-f23d1dea
b7d3b6c2-3f4a17df
d01ab0d3-ca7d8d80
3e006338-3f4a17df
e202a358-3f4a17df
66df3e9d-e7f62c8
2b6b7805-2f57bab8
b7e2524c-f23d1dea
a6674cf-10e61f62
b1681d28-1410f10
cc20827f-ca7d8d80
8502ae4f-e1031ab5
38eb801c-3f4a17df
c27fec31-c982d8da
7c1bc906-8122a015
9def365c-5d0302cf
125b7f68-26e7b859
d442dfb7-3257dc2
9ca1387e-3f4a17df
41e765a5-f23d1dea
1149accc-5c943877
4dc30737-b8a5ea08
a582a1b8-ad75ce17
8ee5ed19-ca7d8d80
74658432-ca7d8d80
ebbb4e0a-ca7d8d80
e56c5101-7d60f345
267255c3-f4950e99
aa011017-48b9f718
88a387d2-8a5e150c
334aa58d-3f4a17df
5e3a236d-59e286d0
345b5b61-f23d1dea
edbcf7c5-ddf1844d
5485fc4d-3d47f4f4
e111fcd-3f4a17df
41f007f9-ca7d8d80
9b4c4257-592e7888
3a0563a1-65222f0b
9e5c75f1-e10fa620
6872f671-991e1e1
2ca9c26b-3f4a17df
4ea303a6-c11ffda7
6e6e0c7e-3f17a7d8
95876445-83ca4230
d92562a9-441539fd
fc369826-3d47f4f4
7aa46da5-c946b150
4da5ae82-91c810ef
2c1d398c-3f4a17df
58a025e3-36e97b2c
ad6d27cc-1627c3cf
df072bba-ca7d8d80
51b9b54d-f23d1dea
7345ea6-f23d1dea
4bc337ce-f483b7fd
ddf77e2c-9346db1
17507c76-3d47f4f4
494d8760-52325d43
3ac60855-486e2a9c
f296190c-767e51a8
4442aae2-a90023b1
ed1d377-e1cc0f14
75f0f0a0-4ad60575
e2b18481-6e3b1976
e7e71889-4ad60575
5e60f31d-803f8fc4
94e68624-803f8fc4
cc73f8a1-ca02b375
10a311eb-10a311eb
8834fcca-cf4f6ead
6204e469-e3d9cd05
ea0f933d-29e3c6de

Thanks! Could you also get chrome://conflicts before and after the change?

Sure! I am not comfortable sharing the //conflicts output from my work (fed gov) machine, but will be happy to do so later today from home if no one else has contributed it by then. 

variations in 53 have NetworkService-Enabled

johnpdoyle: can you try totally exiting Chrome and relaunching with --disable-features=NetworkService on the command line, just to remove the possibility that this could be caused by that experiment.

Hi - as requested, I tried with the --disable-features=NetworkService flag added to the target - with the same result (no text box for PIN entry in the smartcard pop-up window).

thanks for trying. I think we're going to have to try and get a local repro to make any progress on this issue.

regarding question 2:
It seems like an issue with the baseCSP, see my earlier comment about https://docs.microsoft.com/en-us/windows-hardware/drivers/smartcard/card-pin-operations#span-idsecretpurposespanspan-idsecretpurposespansecretpurpose

minidriver installations can influence this dialog though (e.g. by putting some translations in some registry keys as mentioned in that site)
But as I've seen different smart cards with this issue passing already, I don't think its a minidriver.
Here I use a Belgian eID, but in a merged issue I also noticed the Estonian eID passing

I'll try to provide 1) as well, but have been travelling and am now at a different location with different test machines

I don't suppose there's some "fake software smartcard that triggers a PIN prompt for testing" driver that one could install?

I suspect what's probably happening here is that the CSP provider DLLs are doing an insecure DLL load. 58443848dec954f3ae041db1f70e0342df460c6b applied policy to the browser process to further strengthen DLL load order and prevent preloading attacks. The practices as described by Microsoft are:

https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-security

...what we will probably need to do is try and get a repro, then run with process monitor [1] and see which DLLs are failing to load - those will have to be copied into the system32 directory to work. If someone is familiar with this, they could run process monitor, work out which DLLs are failing to load, and then copy them selectively to system32.

Without a repro, this is really hard for us to diagnose. If it is at all possible to contact the vendor for your smart card solution and have them work with us (ideally, send us a link to the software so we can install it, and verify the bug) that would certainly help the triage process here. If it's possible to do this purely with tools from MSFT then we will need a step-by-step guide for setting up a test environment that replicates your environment.

[1] - https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

That being said, I think, given we have a high degree of confidence that 58443848dec954f3ae041db1f70e0342df460c6b is at fault here, I would be happy for this to be reverted and then users could test on canary. We could then, in theory, merge to a beta/stable branch depending on the impact (a decision left up to the release TPMs).

Speculative revert is going in with https://chromium-review.googlesource.com/c/chromium/src/+/1292370.

Will's out next week, so I'll take point next week. The plan:

1. A day or so after that revert goes on, I'd like someone to run Chrome Canary and see if the issue is resolved. Please be sure to include both whether it resolved it AND the version (go to chrome://version) so we're sure your Canary build included the revert.
https://www.google.com/chrome/canary/

2. If the speculative revert does NOT resolve it, it's something else. I'll revert the revert and go back to the drawing board.

3. If the speculative revert DOES resolve it, it'll be up to TPMs whether they wish to merge it to beta/stable. Additionally, we'll want to figure out what to do with smart cards conflicting with this security mitigation.

One thing Will and I chatted about was banishing all this insanity to a dedicated utility process. I think that should be possible now that ClientCertStore and all are nicely abstracted. Will says we can toggle the flag differently between the two processes. Of course, this introduces a risk that something *else* will break once moved out-of-process. Anyway, that'll need discussions and some deeper investigation as to what's going on. (rsleevi?)

A way to reproduce this would also be really helpful. This use case is disproportionately difficult to support, between buggy smartcard drivers, weird scenarios, and lack of any clear way to simulate these behaviors. In the past I've resorted to asking users to run random exes I'd put together to figure out what bug a smartcard driver had! (Spoiler: it didn't bounds-check output buffers correctly and lied when you asked it the key size.)

I ran into some complications, but I have the conflicts lists now of a working and non-working build now.
When I diff them, there is only 1 lib different (1 extra in the working case)
And it is Microsoft's smart card credential provider, so I join your confidence (though it is sitting in system32)

Windows Smartcard Credential Provider	Microsoft Windows	6.1.7600.16385	524E20E727000	%systemroot%\system32\ smartcardcredentialprovider.dll	

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/432f4e5b65bcea622a49e2df274d72fd9c581d84

commit 432f4e5b65bcea622a49e2df274d72fd9c581d84
Author: Will Harris <wfh@chromium.org>
Date: Fri Oct 19 22:23:17 2018

Revert "Strengthen MITIGATION_DLL_SEARCH_ORDER on non-component builds."

This reverts commit 58443848dec954f3ae041db1f70e0342df460c6b
(just the policy setting on browser process).

Reason for revert: breaks some third party CAPI providers.
BUG= 880835 

Original change's description:
> Strengthen MITIGATION_DLL_SEARCH_ORDER on non-component builds.
>
> Also, add this mitigation to the browser process.
>
> BUG=870463
>
> Change-Id: I1e749a4ede0b41cca69f60262fd878c57ed35564
> Reviewed-on: https://chromium-review.googlesource.com/1162581
> Reviewed-by: Penny MacNeil <pennymac@chromium.org>
> Commit-Queue: Will Harris <wfh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#581067}

TBR=pennymac@chromium.org,wfh@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 870463
Change-Id: I2ae97b0955cc5d1196ab002e02285da05b3a4d35
Reviewed-on: https://chromium-review.googlesource.com/c/1292370
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Commit-Queue: David Benjamin <davidben@chromium.org>
Commit-Queue: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601318}
[modify] https://crrev.com/432f4e5b65bcea622a49e2df274d72fd9c581d84/content/app/sandbox_helper_win.cc

Comment #64: Interesting. Perhaps that dll is loaded in a really strange way on Win7. (We don't have any Win10 reports, right? Just Win7?)

The speculative revert is in. Sometime in the next few days, when the next canary release is happens (it should be 72.0.3586.0 or later), could someone respond whether the issue is resolved there?
https://www.google.com/chrome/canary/

If the revert works please merge it with stable as this already influences, like mentioned before, 100k / millions of workers in different corporate environments which utilize smartcards. 

Probably this can be clarified independently from the solution in some general way with the TPMs beforehand.

(due to the urgency)

Hi - I confirm that my smartcard prompt includes box for PIN entry when using Chrome Canary ver 72.0.3586.0.  Evidence attached (and authentication was successful).

Deleted: smartcard_canary_72_0_3586_0.JPG 23.4 KB

	smartcard_canary_72_0_3586_0.JPG 23.4 KB View Download

> Without a repro, this is really hard for us to diagnose. If it is at all possible to contact the vendor for your smart card solution and have them work with us

Well, Frederik and I *are* paid to maintain the official Belgian eID software, so...

> (ideally, send us a link to the software so we can install it, and verify the bug) that would certainly help the triage process here.

Since you ask:

Our software can be downloaded from https://eid.belgium.be/. However, you wouldn't be able to test it without a physical test card; a set of five cards can be acquired through https://www.eazysign.be/en/eazyset-your-set-of-eid-testing-cards (although only three of them will contain an active authentication certificate that would work for a proper test)

> One thing Will and I chatted about was banishing all this insanity to a dedicated utility process. I think that should be possible now that ClientCertStore and all are nicely abstracted. Will says we can toggle the flag differently between the two processes. Of course, this introduces a risk that something *else* will break once moved out-of-process. Anyway, that'll need discussions and some deeper investigation as to what's going on. (rsleevi?)

Yes. That was something that I'd talked about with pennymac@ as something to keep an eye on for Windows, as it was a concern. It's also a concern for Network S13N, which also depends on CAPI providers, which is why I wanted to move verification out as well, so that both of these functions could be colocated in a utility process. That said, there are some gotchas with respect to UI display and processing that the utility process would need to address (i.e. it would need to have a MessageLoopForUI). However, with moving verification out-of-process being blocked, it sounds like we may need to address these piece-meal for now as reports come in from Stable users who are broken, since it will primarily be Enterprise users.

If Chrome team is having trouble with testing this locally, here is another issue that shares the same root cause:

Many Chinese users that use Google Input Tools for Windows reported that it no longer works in Chrome 70 only (all other browsers and Windows software still work, Chrome 69 still works).

After the speculative revert was landed in Chrome Canary, I asked them to install Chrome Canary. A few replied that it works in Chrome Canary.

It seems to only affect Windows 7 users.

Forum thread: https://productforums.google.com/forum/#!topic/chrome/Gv9cIsJCZVk

I can confirm that 72.0.3589.0 (x64 on Windows 7) downloaded minutes ago from download-chromium.appspot.com displays the PIN entry field again, seemingly solving the issue.

I can confirm too that 72.0.3589.0 (x86 on Windows 7) downloaded minutes ago from download-chromium.appspot.com displays the PIN entry field again.

I can confirm the displaying of the PIN entry field as well (32bit on Windows 7)

output of chrome://version:
Google Chrome	72.0.3588.0 (Official Build) canary (32-bit) 
Revision	56533f367ba451d6545ab0045e8e11f288b36326-refs/branch-heads/3588@{#1}

The PIN prompt is also broken in Windows 10 with build 70.0.3538.67 (worked in build 69) but fixed with 72.0.3588.0 canary build.

The PIN prompt works for me with Chrome 70.0.3538.67 (intranet pages of my company) - Windows 10 64-bit v1803 build 17134.285.

PIN prompt was broken for us on both Win7x64 and Win10x64 (1803) with Chrome v70 x64 and the default Windows minidriver.

Chrome v70 x86 on Win10x64 (1803) worked properly (PIV prompt displayed)

Confirmed Chrome Canary v72.0.3588.0 64-bit works properly on both Win7 and Win10 (1803).

Since it sounds like this fixed the issue, requesting a merge for davidben since he's OOO as per #63.

TPMs:

A change to the mitigations applied in M70 caused issues with enterprise smart cards and other third-party providers. Details and the current plan are in comment #63.

If possible, we'd like to get the following change merged into both M70 Stable and M71 Beta:

https://chromium.googlesource.com/chromium/src.git/+/432f4e5b65bcea622a49e2df274d72fd9c581d84%5E%21/

Its been deployed in Canary over the weekend, and is a reasonably safe merge as its a revert to just the policy setting.

This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge to M71 branch 3578 based on commment #78. Pls merge ASAP. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c4431930dbf73f0a09abf50e5fc6db739e2562b5

commit c4431930dbf73f0a09abf50e5fc6db739e2562b5
Author: Will Harris <wfh@chromium.org>
Date: Mon Oct 22 14:48:32 2018

Revert "Strengthen MITIGATION_DLL_SEARCH_ORDER on non-component builds."

This reverts commit 58443848dec954f3ae041db1f70e0342df460c6b
(just the policy setting on browser process).

Reason for revert: breaks some third party CAPI providers.
BUG= 880835 

Original change's description:
> Strengthen MITIGATION_DLL_SEARCH_ORDER on non-component builds.
>
> Also, add this mitigation to the browser process.
>
> BUG=870463
>
> Change-Id: I1e749a4ede0b41cca69f60262fd878c57ed35564
> Reviewed-on: https://chromium-review.googlesource.com/1162581
> Reviewed-by: Penny MacNeil <pennymac@chromium.org>
> Commit-Queue: Will Harris <wfh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#581067}

TBR=pennymac@chromium.org,wfh@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 870463
Change-Id: I2ae97b0955cc5d1196ab002e02285da05b3a4d35
Reviewed-on: https://chromium-review.googlesource.com/c/1292370
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Commit-Queue: David Benjamin <davidben@chromium.org>
Commit-Queue: Will Harris <wfh@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#601318}(cherry picked from commit 432f4e5b65bcea622a49e2df274d72fd9c581d84)
Reviewed-on: https://chromium-review.googlesource.com/c/1293558
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#205}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/c4431930dbf73f0a09abf50e5fc6db739e2562b5/content/app/sandbox_helper_win.cc

The relevance of this broken M70 for the Enterprise segment should not be underestimated when considering the merge.

Premium customers highly demand this fix to be merged asap to current stable M70. I see this bug has been marked Merge-Review-70. What's the review progress? Any ETA?
Thank you.

Thanks all for feedback - we are waiting for final dev confirmation today and then will merge to M70 (if all looks good). 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0f1671993f5a7501789a62833f542423f83c6b54

commit 0f1671993f5a7501789a62833f542423f83c6b54
Author: Will Harris <wfh@chromium.org>
Date: Tue Oct 23 14:45:47 2018

Revert "Strengthen MITIGATION_DLL_SEARCH_ORDER on non-component builds."

This reverts commit 58443848dec954f3ae041db1f70e0342df460c6b
(just the policy setting on browser process).

Reason for revert: breaks some third party CAPI providers.
BUG= 880835 

Original change's description:
> Strengthen MITIGATION_DLL_SEARCH_ORDER on non-component builds.
>
> Also, add this mitigation to the browser process.
>
> BUG=870463
>
> Change-Id: I1e749a4ede0b41cca69f60262fd878c57ed35564
> Reviewed-on: https://chromium-review.googlesource.com/1162581
> Reviewed-by: Penny MacNeil <pennymac@chromium.org>
> Commit-Queue: Will Harris <wfh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#581067}

TBR=pennymac@chromium.org,wfh@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 870463
Change-Id: I2ae97b0955cc5d1196ab002e02285da05b3a4d35
Reviewed-on: https://chromium-review.googlesource.com/c/1292370
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Commit-Queue: David Benjamin <davidben@chromium.org>
Commit-Queue: Will Harris <wfh@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#601318}(cherry picked from commit 432f4e5b65bcea622a49e2df274d72fd9c581d84)
Reviewed-on: https://chromium-review.googlesource.com/c/1296615
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#1032}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
[modify] https://crrev.com/0f1671993f5a7501789a62833f542423f83c6b54/content/app/sandbox_helper_win.cc

The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/0f1671993f5a7501789a62833f542423f83c6b54

Commit: 0f1671993f5a7501789a62833f542423f83c6b54
Author: wfh@chromium.org
Commiter: svaldez@chromium.org
Date: 2018-10-23 14:45:47 +0000 UTC

Revert "Strengthen MITIGATION_DLL_SEARCH_ORDER on non-component builds."

This reverts commit 58443848dec954f3ae041db1f70e0342df460c6b
(just the policy setting on browser process).

Reason for revert: breaks some third party CAPI providers.
BUG= 880835 

Original change's description:
> Strengthen MITIGATION_DLL_SEARCH_ORDER on non-component builds.
>
> Also, add this mitigation to the browser process.
>
> BUG=870463
>
> Change-Id: I1e749a4ede0b41cca69f60262fd878c57ed35564
> Reviewed-on: https://chromium-review.googlesource.com/1162581
> Reviewed-by: Penny MacNeil <pennymac@chromium.org>
> Commit-Queue: Will Harris <wfh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#581067}

TBR=pennymac@chromium.org,wfh@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 870463
Change-Id: I2ae97b0955cc5d1196ab002e02285da05b3a4d35
Reviewed-on: https://chromium-review.googlesource.com/c/1292370
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Commit-Queue: David Benjamin <davidben@chromium.org>
Commit-Queue: Will Harris <wfh@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#601318}(cherry picked from commit 432f4e5b65bcea622a49e2df274d72fd9c581d84)
Reviewed-on: https://chromium-review.googlesource.com/c/1296615
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Cr-Commit-Position: refs/branch-heads/3538@{#1032}
Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}

The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/c4431930dbf73f0a09abf50e5fc6db739e2562b5

Commit: c4431930dbf73f0a09abf50e5fc6db739e2562b5
Author: wfh@chromium.org
Commiter: svaldez@chromium.org
Date: 2018-10-22 14:48:32 +0000 UTC

Revert "Strengthen MITIGATION_DLL_SEARCH_ORDER on non-component builds."

This reverts commit 58443848dec954f3ae041db1f70e0342df460c6b
(just the policy setting on browser process).

Reason for revert: breaks some third party CAPI providers.
BUG= 880835 

Original change's description:
> Strengthen MITIGATION_DLL_SEARCH_ORDER on non-component builds.
>
> Also, add this mitigation to the browser process.
>
> BUG=870463
>
> Change-Id: I1e749a4ede0b41cca69f60262fd878c57ed35564
> Reviewed-on: https://chromium-review.googlesource.com/1162581
> Reviewed-by: Penny MacNeil <pennymac@chromium.org>
> Commit-Queue: Will Harris <wfh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#581067}

TBR=pennymac@chromium.org,wfh@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: 870463
Change-Id: I2ae97b0955cc5d1196ab002e02285da05b3a4d35
Reviewed-on: https://chromium-review.googlesource.com/c/1292370
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Commit-Queue: David Benjamin <davidben@chromium.org>
Commit-Queue: Will Harris <wfh@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#601318}(cherry picked from commit 432f4e5b65bcea622a49e2df274d72fd9c581d84)
Reviewed-on: https://chromium-review.googlesource.com/c/1293558
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#205}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}

Thanks all. 

Just to confirm that the PIN prompt issue has been fixed in "Version 72.0.3589.1 (Official Build) canary-dcheck (32-bit)". I am on Windows 7 Enterprise Service Pack 1 (64 bit).

What is the timeline of this change making it to the currently available stable release "Version 70.0.3538.67 (Official Build) (64-bit)"?

We're making another Dev release later today, that we'll ask people to verify work and if the timing works out, the next Stable refresh should include the patch.

Thank you - can someone please verify additionally on M71 Dev if the fix is working? It just rolled out few minutes ago.  

https://www.google.com/chrome/dev/
Version: 71.0.3578.20

I've confirmed the fix on M71 Dev is working (71.0.3578.20 on Win10x64).

Before closing this as fixed, can someone confirm that 71.0.3578.20 also fixes the issue on Win7.

Fix works great in Dev release: Version 71.0.3578.20 (Official Build) dev (32-bit).

How soon can this make it to the upper channels (Beta, Stable)? Thanks.

+ goanuj@  (Chrome Enterprise PM)

Thank you for the fix and merge.

Requesting a postmortem for this, pls see go/chrome-postmortems for more details.

As this issue requires smart cards to test,requesting some one from dev team please verify the fix & update the issue accordingly.

Thanks in advance!

I can also confirm Version 71.0.3578.20 (Official Build) dev (32-bit) shows the PIN entry field on Windows 7.
Can we assist by testing a pre-release 70 updated version?

Smart card test performed. Getting PIV prompt as it was the case prior to Update 70.

Thanks everyone for the feedback. We've rolled out M70 respin to stable. Can someone please test 70.0.3538.77 in stable and confirm?

Hi - I confirm that 70.0.3538.77 (64-bit) running on Win7 resolves the PIN issue.  Thanks to all involved for expediting the production push.

Thanks a lot for a very quick turnaround on this issue! Confirming that I can now see a "healthy" PIN prompt after Chrome update to Version 70.0.3538.77 (Official Build) (64-bit) in Windows 7 machine.

Issue 898561 has been merged into this issue.

hello, I can confirm the PIN entry dialog is shown on version 70.0.3538.77 (32-bit) on Windows 7

Yes, me too. I confirm that today Chrome 70.0.3538.77 (Official) (64 bit) works on my Win7.
How the **ll did u solve the problem?? ;-)

Still does not work for me.  Windows 10 Enterprise and Chrome Version 70.0.3538.77 (Official Build) (64-bit)

Issue 900172 has been merged into this issue.

Issue 900172 was merged into this issue.  This issue dealt with Windows 7.  It is still broken for me in Windows 10.  Recommend Undupe.

The 70.0.3538.77 build fixed the PIN issue for us on Windows 10 Enterprise (x64 OS and 64-bit Chrome)

well not for me.  Still doesn't work for any sites that require smart card login.

re: Comment 115:

Could you file a new bug and report that number here? We'd be happy to investigate further. Please include the full chrome://version and OS.

Thank you.  I did file a new bug yesterday.  Issue number 900172.  

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36

Steps to reproduce the problem:
1. Select Smart Card Logon for any site that requires/offers that option
2. 
3. 

What is the expected behavior?
The Windows Security Smart Card login popup window should have a PIN entry box

What went wrong?
The Windows Security Smart Card Login popup windows did not have a entry field for the PIN

Did this work before? Yes Unsure

Chrome version: 70.0.3538.77  Channel: stable
OS Version: 10.0
Flash Version: 31.0.0.122