Brendan Forster

Not sure I understand the issue, as we're using `3.1.0` in the lockfile: https://github.com/atom/node-keytar/blob/12484088ce0980a903627b6fc7ddaaf02188e982/package-lock.json#L2206-L2210 And our `dependency` is not `3.2.0` specifically: https://github.com/atom/node-keytar/blob/12484088ce0980a903627b6fc7ddaaf02188e982/package.json#L53 There's some extra context here about how we're...

I was also able to do this successfully with the latest version on macOS (using our version of `node-gyp`, not the global one): ``` $ ./node_modules/.bin/node-gyp rebuild --target=13.0.0-beta.27 --arch=x64 --dist-url=https://electronjs.org/headers...

We had a shot at this for Electron in #329 but had to back it out in #340. I think we need to be on a later version of `node-gyp`...

There's a related question in #168 where the caller would like to control the "place" where a credential is stored on Windows. I'd prefer to not add duplicate APIs that...

@GuillaumeRx thanks for this report! I did a cursory glance of the `package.json` file (where our scripts are located) and `binding.gyp` (which handles building the native module) and couldn't spot...

Bumping this to indicate that #316 seems to suggest that it's also possible to encounter this on Linux

Reading into some more history about this and it seems like `gyp` (which `node-gyp` is based upon, and is a key part of the Node ecosystem for building native modules)...

This is a generic error resulting from `dbus` not being ready for keytar to query. I'm not familiar with how to setup a Docker container that will support `keytar`, but...

> Although this would increase the size of the Keytar package by a few MB, it speeds up install time and has additional benefits listed below. For reference the total...

> Is is a no-no to keytar get/set from renderer process? This is fine, and a very common scenario. It's just that keytar doesn't care about where it gets run...