Arch Linux User Repository

1Password for Arch Linux - Stable

The source is signed with the GPG key 3FEF9748469ADBE15DA7CA80AC2D62742012EA22 and can be seen on the install-linux guide.

Getting Started

Our getting started guide can be found at https://support.1password.com/install-linux/#arch-linux

Support

Our Linux support discussion is available at https://1password.community/categories/linux

Beta Releases

Our beta releases can be found at 1password-beta. Beta releases are more likely to have regressions than our stable releases.

That's weird, I didn't have to do anything for 1password to integrate with the google-chrome-stable package.

Manifests can be written in user directory, which the app should do (haven't checked myself: did you enable browser integration in the settings?)

I have a patch to this PKGBUILD to create native-messaging-host configs for Chrome and Chromium, which allows the browser extensions for reliably communicate with the app.

I'm not sure what is the right way to provide submit this change to this AUR repo, but my patch can be found at https://github.com/kshlm/pkgbuilds/commit/159aed38500c055111dc838d6ddbd644e17c4298.patch

This can be applied directly onto this repo with,git am -p2 159aed38500c055111dc838d6ddbd644e17c4298.patch

I've tested this with Chrome, Chromium and Brave/Brave-beta, and this enables the extensions in these browsers to be unlocked by the desktop app.

I suggess adding "libappindicator-gtk3" as an optional dependency.

Without it, the 1password statusbar icon will not show on GNOME even with the AppIndicator extension. It wasn't super fun to figure that out.

@Feakster Thanks for the suggestion. We will keep it in mind as our Linux support continues to grow.

Would you be able to make this a multi-arch package once you start using the tar instead of the AppImage? The arm architectures have a growing user base on Arch & Manjaro.

@Orangutan We actually have some plans to base the install on a tar instead of the AppImage. While we get that ready we plan on keeping this based on the AppImage.

Wouldn’t using the .deb be nicer and simpler? It’s what packages usually do in this situation

It looks like helpers that cache the AppImage (like yay) are using a previously downloaded version (before the signature change introduced in 1936c4e). I've appended the pkgrel to the name of the binary to bust this cache.