Developing for macos, I’ve gotten bit by keychain consistency issues far too many times. It’s a mess.

So many of the keychain APIs are "deprecated" (read: marked as "we will nuke this API whenever we want") and have been for a decade or more, but have no replacement either.

A lot of the Security Framework came from Classic, hell, the idea of a keychain came from Classic! Just a mess.

Can echo this, I've also fallen foul of keychain behaviour. In my case I found a lookup that passed the account name as raw bytes instead of text didn't match my item. On macOS it matched all items with a blank account (strictly, generic password items), which on my computer meant items from GitHub CLI, Malwarebytes, and Adobe Creative Cloud. The app I was building silently used one of those as its key, and would change whenever one of those apps would update its entry. The fix was to make sure the account is passed as a string and that it has a service name so that lookup either matches exactly my item or none. The API takes a loosely typed dictionary, so wrong types throw no errors, just different behaviour. I now always test against the real keychain and not a mock.

> The bug still exists to this day

You linked a commit and a Reddit post. Is there a proper Github issue as well?

from his link:

> Edit (March 2025):

> Wireguard, to my surprise, has no bug tracking system like Jira or issue tracking area such as GitHub.

> If you want to see this fixed, the only way to instigate change is to write [email protected] and [email protected].

> You linked a commit and a Reddit post. Is there a proper Github issue as well?

It's funny you mentioned that. The GitHub repository is a mirror of https://git.zx2c4.com/wireguard-apple. You cannot create issues there. You're supposed to send a bug report to the mailing list, which is enough friction that none of us did so far.

>enough friction that none of us did so far.

Emailed per https://news.ycombinator.com/item?id=50450200

Definitely still a bug right? Linked them to your parent comment.

Edit: oops sorry team, think you're on it (4d ago): https://github.com/whyredfire/wireguard-apple/commit/0bac142...

> Definitely still a bug right? Linked them to your parent comment.

Thanks! Yes, it is still a bug.

> Edit: oops sorry team, think you're on it (4d ago)

I don't think @zx2c4 has seen this PR, and the author of the PR has not sent a bug report yet, so it's probably fine :P

All right! :)

> Thanks! Yes, it is still a bug.

Its unfortunate no updates for Wireguard macOS have been pushed out for 3 years, App Store is still showing 1.0.16 as the latest version – as also confirmed on the Wireguard website at the latest version.

No doubt macOS APIs have moved on a lot in 3 years and so perhaps bugs that are being seen are simply a reflection of the lack of updates to keep up with API changes ? Just thinking aloud here, I don't know if the concept of OS API changes are applicable to this particular PR / bug.

>friction

I appreciate when both options exist, because I've passed on reporting so many bugs, because I refuse to create a Microsoft account to do it.

In fact, I don't understand how sending an email is high friction.

> I've passed on reporting so many bugs, because I refuse to create a Microsoft account to do it.

99% of the time it's perfectly fine to just email the maintainer with a bug report and maybe a patch.

> In fact, I don't understand how sending an email is high friction.

Judging from the fact that after so many years, such a widespread (as seen in the Reddit post and here) issue still hasn't resulted in a single bug report in the mailing list, I'd say most people (including myself) do indeed consider using a mailing list to be higher friction.

If I'm not mistaken, unless you're already CC'ed by a participant, you'd have to subscribe to the whole mailing list just to receive notifications for a single thread. For an "issue" on a Git forge, participation is usually as easy as upvoting and then clicking the "Subscribe" button.

Assuming you're already using MS Github. Anyway, even if I was, a lot of Github project require filling out an absurd Simon Says form. Or that scene from Indiana Jones where he takes a wrong step and falls through the floor. That's nothing to do with email or Microsoft specifically, it's just another reason I almost never bother reporting bugs. Talk about friction.

Yeah, I hate these forms (issue templates) too. Every time I have to fill such a form, I always feel that they are discouraging me from writing the bug description in a natural, coherent way. I'd spend more effort to make sure the description is clear and contains all necessary information, if there's no issue template requirements.

Yes, but most people won't. Most people will submit a bug report with important information missing that means we have to go back and forth. Also, there is often specific debugging information that people would not even know would be useful.

In the current age, its useful because AI will submit tickets using the CLI that don't use the form, so I can immediately close and lock them and go on living my life.

"MS Github"(?) is just "Github". They bought it, they own it.

I had this as well - funny enough I asked my local AI to "find the removed config" and it was able to restore everything.

Lucky for you! I first ran into this before AI agents were a thing, so :(

There are features built for security nerds (like PGP/GPG, etc)

And features built for normal people

The overlap is very rare

well but deletion isn't what even those "security nerds" would have expected...

Security nerd here. I would have expected it. But only in the sense that I have no faith in this industry to write secure software and protect from data loss.

I keep hoping better liability laws will force management to support doing it the right way, if not anything else than avoid hefty fines.

This is not a feature built for security nerds. This is a feature built for corporate compliance box tickers, and it works precisely as wanted in corporate environments, where all lost secrets can be easily replaced after visiting the helpdesk room personally.

True, there's that as well

The worst part: the people that work at your bank and at city hall are not security nerds, and don't care to become security nerds. do with that what you will.

I'm using WireGuard myself. Not on MacOS, but on Windows/Linux/Android. The reason I went with WireGuard to begin with, is due to how secure it suppsedly was. Having long standing unresolved issues like that is a bit worrying. I'm still most likely safe, but it's not exactly reassuring, either

This is likely just that if someone chooses an OS that requires a special HW just to build a release with no easy cross-compilation possible, and to pay a gatekeeper just to publish it, and that can't even run on an emulated computer properly, they can't expect FOSS maintainers will be bothered with much more than "here's a source code, build it/test it/do QA yourself if you like" for their particular pet platform.

Best common on HN this week.

Just going to reply to your comment here: the choice to use wireguard shouldn't come down to relative security (although I guess it gets a benefit here), but from being fast and simplistic.

All of the traditional components of VPN management are removed from the core code. Wireguard follows the model "do one thing, and do it well." It's also built into the kernel, which inherently can make it faster than userland VPN software.

This is why companies like Tailscale exist--as they're basically selling back the features that you would get in a more traditional IPSEC VPN, but in front of Wireguard instead.

This literally just happened to me yesterday. Again.