Leave unlocked is not working for me. Constant requests for signing when using Visual Studio Code

[carumusan]

A "requires authentication" key that I'm using for GitHub is constantly asking for permission. Leaving unlocked does nothing and currently it is unusable.

[maxgoedjen]

@carumusan just to double check, you're clicking "leave unlocked for _" in the notification, and authorizing the unlock, and still seeing it prompt you every time?

[carumusan]

It does not prompt to authorise to leave unlocked. I am clicking on the leave unlocked for one day from the drop down in the notification.

[dgattey]

Seeing this as well - constantly bugging me every time I use the app, despite selecting 1 hour or 1 day from the notification dropdown

[lvangool]

This works for me as long as its in the same process chain, and so long as auth is regularly requested. So what I normally do when I get started:

1. Launch iTerm
2. Run: git fetch --> Auth, select "Leave Unlocked One Day", Auth
3. Launch SourceTree VIA iTerm This seems to keep my terminal/SourceTree working as expected.

One thing I noticed though is this works only as long as they are actively used, regardless of using "Leave Unlocked". Is there an internal timeout somewhere, if auth isn't requested for X minutes (60?) then a single re-auth is always required? (NOTE: I don't think it correlates to my laptop sleeping, but rather auth just not being requested for a while)

[maxgoedjen]

I would guess this is just the same issue as https://github.com/maxgoedjen/secretive/issues/384 – can you download a recent nightly (eg https://github.com/maxgoedjen/secretive/actions/runs/2621315270) and see if that fixes?

[dgattey]

Working so far @maxgoedjen with that new build! Annoying to see the notifications all the time when the key is signed (about every ~5 min in VSCode for whatever reason) but it does seem to be persisting for the day I asked for. I can open another issue for this, but having a A) 7 day option and B) a way to silence the "signed the unlocked key" notifications would be amazing. Additionally, is there a way to unlock for 1 day/etc from the Secretive window itself or just the notification? The former would be useful.

[dgattey]

Oh no, I spoke too soon. About ~15 min after I first asked it to sign for 1 day, I got another request to sign it

[marcantoinegodde]

I also experience this phenomenon. It is quite random. If I choose Leave unlocked for 1h, I could be prompted to TouchID after 10min and it starts working again just after the unlocking.

[tmountjr]

I'll chime in here that while I love not having to cart around a yubikey with my SSH key on it, the "leave unlocked" behavior leaves quite a bit to be desired. I thought maybe it was that VS Code prompted me to unlock my key and my terminal didn't know anything about that, which was why it kept asking me, but even after choosing to leave it unlocked for a day, VS Code will still nag me every few minutes. My only option has been to deny it to keep it from popping up (since that prompt sits above every other window, even when the focus isn't on the prompt).

[maxgoedjen]

I think the sone might be fixed by some of the changes in 2.3.0. Please let me know if you continue seeing this on that version!

[zhenghaven]

I'm still seeing this in 2.3.0. It seems to be working properly in Terminal. But when I use VSCode, even though I clicked leave unlocked for 1 day, within that day, sometimes it will just show a notification saying the key is used, but other times it will still ask me to unlock the key.

[tmountjr]

Same, it's most obvious in VSCode, though I haven't noticed it as much with Terminal (the app, not the terminal window in VSCode).

[codyhatch]

I'm seeing the same thing with 2.3.0. In my case, the terminal works, but requests made from a Jetbrains IDE generally do not.

[tmountjr]

This is getting to the point of me being about to uninstall this app - at this point I don't even get prompted to remember my decision (even though that hasn't been working). I'm in VS Code all day long toggling between multiple projects and every time I switch a window, I get this modal popup that intercepts whatever code I happen to be writing at the time. Extremely disruptive. Best case is to leave it the modal open but move it somewhere unobtrusive (another monitor, maybe) until I need it, at which point I have to authenticate a few times before whatever action I was trying to do gets its turn to ask.

I really love the concept because remembering to take around a ubikey (which was how I managed this previously) is annoying and they're easy to lose...and with ports at a premium on most macbooks, I don't really want to dedicate a port solely to a ubikey. But I may have to go back to that if this doesn't get fixed.

[dgattey]

Yup @tmountjr I uninstalled - the popups are constant and experience is too tedious to use

[boabdilperez]

I am also having this issue. VSCode is constantly making checks to git to see if the origin repo has had updates, so I clicked to leave it unlocked for a day. It keeps prompting me every few minutes whenever VSC makes another call to git and now it's stopped asking if I want to leave it unlocked altogether.

[tmountjr]

Don't suppose the latest release addresses this?

[maxgoedjen]

@tmountjr /anyone else seeing this issue still: do you see any crash reports in ~/Library/Logs/DiagnosticReports or Console.app? I don't have any leads on this issue right now, if the leave unlocked feature isn't working properly, but I'd suspect a crash, and reports would help there.

[tmountjr]

I haven't been in code much the last few days - I'll look closer next week.

On Sun, Aug 6, 2023, 19:07 Max Goedjen @.***> wrote:

@tmountjr https://github.com/tmountjr /anyone else seeing this issue still: do you see any crash reports in ~/Library/Logs/DiagnosticReports or Console.app? I don't have any leads on this issue right now, if the leave unlocked feature isn't working properly, but I'd suspect a crash, and reports would help there.

— Reply to this email directly, view it on GitHub https://github.com/maxgoedjen/secretive/issues/372#issuecomment-1666999187, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJF3W5JPL6WFS6VEENKDE3XUAPUXANCNFSM5SZ33TRQ . You are receiving this because you were mentioned.Message ID: @.***>

[PeterStaev]

@maxgoedjen , yes I'm still getting this behavior. I do not see any related carshlogs.

[PeterStaev]

And just to bring more context to the issue - when we have the key unlock and vscode prompts to re-authenticate, in the notification that the key is unlocked there is no options to again leave the key unlocked. So I'm guessing the key is being detected as unlocked already but no idea why a re-authentication prompt is triggered.

[tmountjr]

Confirmed for me too - had a repo and definitely said to allow all day; a few hours later it asked again, this time with no option to keep unlocked.

On Mon, Aug 7, 2023 at 7:51 AM Peter Staev @.***> wrote:

And just to bring more context to the issue - when we have the key unlock and vscode prompts to re-authenticate, in the notification that the key is unlocked there is no options to again leave the key unlocked. So I'm guessing the key is being detected as unlocked already but no idea why a re-authentication prompt is triggered.

— Reply to this email directly, view it on GitHub https://github.com/maxgoedjen/secretive/issues/372#issuecomment-1667711739, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJF3W3ZLQXDGG7CRIBS7HDXUDJCLANCNFSM5SZ33TRQ . You are receiving this because you were mentioned.Message ID: @.***>

[PeterStaev]

I think I found the issue with this. Looking at how the unlock is achieved: https://github.com/maxgoedjen/secretive/blob/2a4da36c4e2efc7fc06072950eb24eea8b355ca8/Sources/Packages/Sources/SecureEnclaveSecretKit/SecureEnclaveStore.swift#L181-L184 And according to: https://developer.apple.com/documentation/localauthentication/lacontext/1622329-touchidauthenticationallowablere The reuse authentication has a max duration allowed. From what I've read the value of LATouchIDAuthenticationMaximumAllowableReuseDuration is 5 minutes. So anything higher than this would result in a re-authentication request, sadly 😞

Not sure if an alternative approach of caching can be achieved w/o relying on the reusability of the LAContext.

[maxgoedjen]

@PeterStaev my understanding from testing is that that's not quite correct: that property (which is documented a little better here: https://developer.apple.com/documentation/localauthentication/lacontext/1622329-touchidauthenticationallowablere) is specific to "how long can the interval between device unlock and Touch ID prompt be" – not specifically around the reuse of LAContexts). I've definitely observed it being longer than 5 minutes, but there is something going on here.

[PeterStaev]

@maxgoedjen I had a few spare minutes and decided to debug this. From my tests seems what I've wrote in my previous comment is true: Once cached if I try to use the secret within 5 minutes after allowing it to be cached. All works perfectly. If I try to access it after that (for example I tried 7 minutes after) the process successfully pulls the cached context here:https://github.com/maxgoedjen/secretive/blob/2a4da36c4e2efc7fc06072950eb24eea8b355ca8/Sources/Packages/Sources/SecureEnclaveSecretKit/SecureEnclaveStore.swift#L106-L108 But when it gets to the actual signing here: https://github.com/maxgoedjen/secretive/blob/2a4da36c4e2efc7fc06072950eb24eea8b355ca8/Sources/Packages/Sources/SecureEnclaveSecretKit/SecureEnclaveStore.swift#L135-L137 I get a prompt to re-authenticate. During those 7 minutes I was actively using the computer.

[maxgoedjen]

@PeterStaev I think there may be some configuration difference in play here or something. I'm able to sign past 5 minutes with the steps you described:

• Sign request with auth-required secret
• Select unlock for 1 hour
• Authorize unlock
• Wait 7 minutes, attempt new request.

I made sure that no additional requests were triggered in that 7 minute gap, in order to prevent any "refreshes" of the context.

(also, for posterity: the value of LATouchIDAuthenticationMaximumAllowableReuseDuration on my system is 5 minutes. I'm still not super convinced that's the cause of this issue, but if it was, I'd expect this to reproduce on my Mac given that value).

[maxgoedjen]

I do seem to be able to reproduce this with slightly longer intervals. Re-approving the context seems to be enough to "refresh" it within the unlock window though – so long as it's within the time period I've authorized for unlock, it doesn't require a full "select unlock -> reauthorize" flow. Basically just touching the context refreshes it.

Thinking through this a little more, it might be possible to just perform periodic no-op context reevaluations to keep it alive within the window. I"ll need to think through the security implications of that though.

[maxgoedjen]

Experimenting with that here: https://github.com/maxgoedjen/secretive/blob/experimental_refresh/Sources/Packages/Sources/SecureEnclaveSecretKit/SecureEnclaveStore.swift#L201-L212

[PeterStaev]

@maxgoedjen , really strange, there might be some other settings in play, if the value of the constant is the same on your Mac is the same but you do not experience the same behavior.

If I get a chance I would build from that branch and try it locally to see if this would fix the problem. I will let you know the results once I do!

[PeterStaev]

@maxgoedjen , the code doesn't seem to be working fully correct. So it refreshes the context once or twice. But when it tries to refresh it after that I got the prompt:

After the re-authentication, on the next timer it requests authentication again. After a few prompts it refreshes w/o a prompt couple of times again...

[maxgoedjen]

Yeah I'm unfortunately seeing this as well. I'll continue playing with it but the resolution might just be "pull the unlock functions longer than 10m or so"

[PeterStaev]

From my tests here seems the unlock state has nothing to do with LATouchIDAuthenticationMaximumAllowableReuseDuration. It does seem like it is fixed to 10 minutes after the context is authenticated. After those 10 minutes the LAContext seems invalidated and even if you access it couple of secs before the expiration that doesn't seem to extend the 10 minute duration.