Package Details: ente-auth-bin 3.0.17-1

Git Clone URL: https://aur.archlinux.org/ente-auth-bin.git (read-only, click to copy)
Package Base: ente-auth-bin
Description: Ente two-factor authenticator.
Upstream URL: https://github.com/ente-io/ente/tree/main/auth
Licenses: AGPL-3.0
Conflicts: ente-auth
Provides: ente-auth
Submitter: alessandroberna
Maintainer: alessandroberna
Last Packager: alessandroberna
Votes: 6
Popularity: 2.16
First Submitted: 2024-03-30 19:10 (UTC)
Last Updated: 2024-06-26 20:36 (UTC)

Pinned Comments

nktnet commented on 2024-07-02 15:44 (UTC)

For the error

ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: PlatformException(Libsecret error, Failed to unlock the keyring, null, null

See this issue: - https://github.com/ente-io/ente/issues/2046

In short, install xdg-user-dirs, e.g.

yay -S xdg-user-dirs

alessandroberna commented on 2024-06-26 22:53 (UTC)

The package is still incorrectly symlinking libsodium.so.23 to libsodium.so.26, with only the version having been bumped.

Due to ongoing university exams, I won't have much time to look into this for about a month. The fix isn't trivial, as I can't make pacman remove the symlink /usr/lib/libsodium.so.23 before the new dependency (libsodium-1.0.18) gets installed. This causes pacman to error out, since the shared object is already present during installation. In order for that to work, manual intervention would be required: either uninstalling the package before reinstalling, or manually removing /usr/lib/libsodium.so.23.

This would not be a seamless upgrade, and I'd prefer to fix it differently. It might make more sense to report the issue upstream, as the developers now seem interested in building for Arch-based distros too. They're currently using the same symlink hack for their Arch builds (see https://github.com/ente-io/ente/blob/80d5d7e44e7ea7956490989c44c11d7e358037fa/auth/linux/packaging/pacman/make_config.yaml).

If they update their Arch build to depend on the newer libsodium, it would be enough to just remove the symlink post-upgrade to fix everything, without needing to install the older libsodium and somehow remove the existing symlinked libsodium.so.23

Latest Comments

1 2 Next › Last »

nktnet commented on 2024-07-02 15:44 (UTC)

For the error

ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: PlatformException(Libsecret error, Failed to unlock the keyring, null, null

See this issue: - https://github.com/ente-io/ente/issues/2046

In short, install xdg-user-dirs, e.g.

yay -S xdg-user-dirs

yochananmarqos commented on 2024-06-27 19:35 (UTC) (edited on 2024-06-27 19:36 (UTC) by yochananmarqos)

@alessandroberna: Symlinking libraries like that is absolutely wrong. They're versioned for a reason. Upstream making the same mistake is no justification.

Good news is, upstream is listening to community feedback. Eventually they'll figure it out.

windy commented on 2024-06-27 19:31 (UTC)

Hi, thank you very much for maintaining this packages.

One suggestion: Could you use the version number variable in the download URL? This would make the diff easier to read. Thank you!

Proxy-A23 commented on 2024-06-27 06:32 (UTC) (edited on 2024-06-27 06:37 (UTC) by Proxy-A23)

I have the same problem as with ente-auth 3.0.17-1 , when i log in appears the message "Recreate password: The current device is not powerful enough to verify your password, but we can regenerate in a way that works with all devices. Please login using your recovery key and regenerate your password (you can use the same one again if you wish)."

I saw the following on Reddit:

Hey, this means that the parameters that were used to derive your master-key on your original device, are incompatible with your current device (likely because it's less powerful). If you recover your account via your current device and reset the password, it will re-generate a key that will be >compatible on both devices.

I tried this, but every time I use my key, it says it's incorrect and I can't change the password.

In the previous version of this package I could log in but since the update I could no longer log in.

alessandroberna commented on 2024-06-26 22:53 (UTC)

The package is still incorrectly symlinking libsodium.so.23 to libsodium.so.26, with only the version having been bumped.

Due to ongoing university exams, I won't have much time to look into this for about a month. The fix isn't trivial, as I can't make pacman remove the symlink /usr/lib/libsodium.so.23 before the new dependency (libsodium-1.0.18) gets installed. This causes pacman to error out, since the shared object is already present during installation. In order for that to work, manual intervention would be required: either uninstalling the package before reinstalling, or manually removing /usr/lib/libsodium.so.23.

This would not be a seamless upgrade, and I'd prefer to fix it differently. It might make more sense to report the issue upstream, as the developers now seem interested in building for Arch-based distros too. They're currently using the same symlink hack for their Arch builds (see https://github.com/ente-io/ente/blob/80d5d7e44e7ea7956490989c44c11d7e358037fa/auth/linux/packaging/pacman/make_config.yaml).

If they update their Arch build to depend on the newer libsodium, it would be enough to just remove the symlink post-upgrade to fix everything, without needing to install the older libsodium and somehow remove the existing symlinked libsodium.so.23

alessandroberna commented on 2024-06-08 20:14 (UTC) (edited on 2024-06-08 20:16 (UTC) by alessandroberna)

@yochananmarqos I said that I WILL edit the PKGBUILD and make the package depend on libsodium-1.0.18 (and remove that symlink, in case it was not clear)

I was just discussing the fix, I never said that the package is ok in its current state.

I will update this as soon as I can, thank you for your report and I apologize for the poor quality PKGBUILD

yochananmarqos commented on 2024-06-08 19:40 (UTC)

@alessandroberna: Okay...so why doesn't this package depend on libsodium-1.0.18, then? Apparently it doesn't work if you're creating incompatible symlinks to "fix" things.

alessandroberna commented on 2024-06-08 19:35 (UTC) (edited on 2024-06-08 19:35 (UTC) by alessandroberna)

Got it, I won't do that again.

Anyways I didn't mean to build libsodium in the package but rather to have this other package as a dependency instead of libsodium.

It provides libsodium.so.23 without conflicting with libsodium from the official repos

yochananmarqos commented on 2024-06-08 19:14 (UTC)

@alessandroberna: Symlinking incompatible libraries is always a bad idea.

At this point, there's nothing you can do that's sane. No, do not build an older version of libsodium in the package.

alessandroberna commented on 2024-06-08 19:11 (UTC) (edited on 2024-06-08 19:30 (UTC) by alessandroberna)

Well you're right. At the time I had simply symlinked libsodium.so to libsodium.so.23 which somehow works despite the ABI change but I agree that it's a really ugly hack.

I'll edit the PKGBUILD so that it depends on libsodium-1.0.18 rather than libsodium. Having dependencies that can only be built from source in a -bin package is not pretty but i don't see any better alternative.