-
Notifications
You must be signed in to change notification settings - Fork 14
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
Replace deprecated SecKeychain API with SecItem #33
Conversation
This is great, thanks a lot! I'll try to review as soon as possible, but it'll be a few days at least. |
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #33 +/- ##
===========================================
- Coverage 63.03% 48.51% -14.52%
===========================================
Files 3 3
Lines 165 202 +37
Branches 51 77 +26
===========================================
- Hits 104 98 -6
- Misses 22 45 +23
- Partials 39 59 +20
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
The failing build and test job is unrelated to your changes, I'll look into it. |
b5d53ad
to
5eb9750
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I finally got around to taking a closer look at this. Again, thanks a lot, this is great (and really needed since that API has been deprecated for a while...)
I left some comments, my main worry is that CF*Create functions could fail.
Besides that, there are two things I'd like improved, but I don't mind merging the PR without them and doing it afterwards:
The first would be getting rid of the CFRelease
tirades. For example, we could use RAII to ensure the CFRef is released when it goes out of scope.
The other would be reduce the code duplication of creating those query dicts. I'm not sure if this pays out in the end, because they keys are always different. But then again class, account, service; and converting the account and service strings, is always the same.
Let me know if you want to address these refactorings in this PR.
Gave it a shot to address your feedback. Most of it was fairly straightforward, but figuring out how to use RAII was not easy considering I've written more lines of C++ today than in the rest of my life, so let me know if I did something super weird. 😅 I would recommend looking at the individual commits first, as I tried to address each piece of feedback individually. I tried to make the |
Amazing! I like it. I want to think about the AutoRefs a bit more and play around with it. I found some examples how others deal with the problem, like various implementations of |
I tried some things and I've come up with something that I hope should work. Admittedly, I haven't tested it in the real code. But could we do something like this? https://godbolt.org/z/cranneTnP |
This now uses the SecItem APIs instead of the now deprecated SecKeychain APIs.
ba18957
to
fffc9c5
Compare
That's perfectly fine by me. I ended up using Rust for this instead, so I didn't get around to finishing this up. |
Good choice ;) Thanks for taking the initiative to address this! |
fffc9c5
to
d0fa42a
Compare
@hrantzsch @Nevon It would be awesome to have a fallback code, otherwise this breaks the build, unfortunately. P. S. Sorry, I realize that I am a bit late with this, but I came to know about this software just today, since it turned out to be a dependency for a port I want to build. |
Consider this a bit of a draft, as I'm definitely not a C++ developer and have never developed against the Mac APIs before, so there may be consequences of this change that I'm not aware of. The tests are passing locally, so it seems to work.