Since we only have the stable channel available for AUR, I added a beta.
Tracks latest beta.
Incidentally was wondering if electron binaries packaged in it are specially hardened? If they are just the regular binaries, I was wondering if I can submit it with a rebuild that uses the system binaries so that it can support more architectures than x64. (the chrome-sandbox with 13 and up does have the setuid permissions, so that won't be an interfering factor).
Would be cool if we could get such a package but as an official one, built and released by 1password.
I am a second for official 1password build on AUR. Is that possible?
The '1password' package is officially maintained by them, though it only tracks pinned stable releases. This one (1password-beta-bin) is a simple copy of if which tracks the latest url of the beta tarball. With included signing validation using 1password's gpg key. Which is why I did a binary release of the prepackaged build instead of rebuilding with system electron binaries.
I would be more than happy to transfer the package 1password team if they would like to maintain it. @dev team please hit me up if you'd like to. Or if you want me to take it down for some reason.
Also if you find it that you'd rather not officially support a beta build, by virtue of it, well being a beta build (😁), I would 100% understand it, and will continue to maintain this. Though could you consider pointing the documentation on the beta page to point to this for the AUR instead of the stable one currently mentioned, as opposed to the other distro release sections?
Hi Samarthj (and others),
Thanks for putting this together, I'm delighted to see passionate users like yourself who can't wait to get the new beta features. We try not to announce future plans and features because they can get stalled. Setting up an Arch Linux beta repository has been on my TODO list, but I hadn't gotten to it yet.
Peeling back the curtain a bit, we saw this post on Thursday, as the company was going into a long weekend to commemorate Juneteenth. We saw that your PKGBUILD pulls from one of our domains (https://downloads.1password.com) and uses our key 3FEF9748469ADBE15DA7CA80AC2D62742012EA22 so we didn't see a need to take any immediate action.
Going forward, we would like to be the sole maintainers of a beta repo. It's a good security practice to use an office source for software, and we don't want our users to build the habit of using unofficial repositories.
We'll create a new repo, and ask you to take your down at that time.
Thanks for the response. Happy to take it down once you set things up.
@samarthj Thanks so much! We'll reach out when there's some action on our end.
@samarthj, We've got the new beta repo up: 1password-beta. When convenient, please take down 1password-beta-bin. Soon we'll update the instructions on Use 1Password beta releases
Sweet! Submitted the deletion request and commented there pointing to the official pkg. should take effect when a TU gets to it.
Wondering a bit about that the maintainer is your personal account and not the 1Password account @James.Dressel_1P. Thanks anyway.
Thank you for maintainable beta package on AUR ^_^
@samarthj also thanks for be the first who up that, previously I had installed your version
@felixoi, You're right to wonder about that. I think I see two questions in your comment.
1password-beta is our official beta release for Arch Linux. We list the install instructions on our beta support page.
If you want to dive deeper you can compare the PKGBUILD file from both packages. You'll see that they both use the same pgp signing key (validpgpkeys=('3FEF9748469ADBE15DA7CA80AC2D62742012EA22')) and they both download a tarfile from https://downloads.1password.com/linux/tar/.
If you're at all uncomfortable you are welcome to stay on the main release.
AUR doesn't provide (or I couldn't find) an API to delegate permissions on an account. We couldn't create a set of credentials that provided limited access to the official 1Password account. As an example, I didn't see a way to generate a set of API credentials that would allow me to create a new package owned by the official account without also granting full permissions to the main 1password package.
We've previously written some GitLab automated jobs for deploying updates to the 1password package on AUR. We release updates often, but it's rare for us to create a new package. I didn't think it would be worth the time to create an automated system to create new AUR packages. Since it was not automated, the creation of 1password-beta would have to be manual.
We discussed two approaches to create the 1password-beta package. The first plan would be to have the account credentials of the official 1Password account shared to my 1Password vault. We have a great system for sharing credentials when needed, but it is still best to avoid sharing credentials. The AUR package submission process requires pushing a git repo. This means we would also have to share the SSH private key used to push commits. After the new package was setup, we would rotate the AUR user account credentials, and SSH key. This approach would violate the principal of least privilege. I would have full control of both the 1password and 1password-beta packages.
We decided to follow the second approach, I would create a new AUR account. I would use this account to create a new package, and configure it so our CI can push updates. I, and my computer, would never be exposed to the password or SSH private key.
This approach is ongoing:
The last two items require some coordination between a few teammates and myself. We will get there, we just haven't yet.
I hope this helps.
Thanks a lot for the long explanation @James.Dressel_1P! You guys are doing a great job, keep it up!