Given the recent attacks on the AUR, I’ve been reviewing how to migrate away from using it.
One of the more important programs I use from the AUR is Dropbox (which as far as I know hasn’t been affected). The best option for me looks like the Flatpak version. Are there similar risks with using this as opposed to the AUR version?
Yes - there are similar risk.
Many flatpak has been created by thirdparty - any one individual can upload a flatpak.
Verify who has uploaded flatpak in question by visiting the page e.g.
There is no problem in using custom scripts - just don’t automate the build - ALWAYS verify the content of the build scripts.
If the content is anything but human readable or anything but immediately understandable (e.g. obfuscated by using escaped Unicode et.al.) - do not use the files to build a package.
git clone https://aur.archlinux.org/dropbox
cd dropbox
less PKGBUILD
ls *.install
If an .install file is used - check the content
less <pkgname>.install
Thanks. I’ve used the yay wrapper as my AUR helper to date, and I guess I can do yay -G to check the PKGBUILDs, but not the .install files.
I’ve seen statements that say that the Flathub review process – even for packages that don’t have a verified maintainer – is still more robust than AUR and that e.g. turning off networking during the build process means that additional malicious resources can’t be pulled in during the build.
I am surprised that Dropbox does not have an official Flatpak or at least that someone in the Arch/Manjaro community hasn’t pushed for it to be in the official repos, given that it has officially sanctioned Debian, Ubuntu and Fedora packages.
Dropbox is also available as an unofficial Appimage – https://github.com/ivan-hc/Dropbox-appimage
Dropbox files can also be accessed using a web browser – https://www.dropbox.com/home
Dropbox is proprietary software so it is highly unlikely to be considered for Arch or Manjaro official repositories
For consideration: Syncthing is a viable alternative to Dropbox, albeit with a slight learning curve for those new to the project – it also has the advantage of being open-source and available for multiple platforms;
[ik@io ~]$ pacman -Qs syncthing
local/syncthing 2.1.0-1
Open Source Continuous Replication / Cluster Synchronization Thing
sudo pacman -S syncthing
I personally use syncthing together with the flatpak of syncthingtray (which is my preference due to dependency inconsistencies with the release schedule via AUR).
[ik@io ~]$ flatpak search syncthingtray
Name Description Application ID Version Branch Remotes
Syncthing Tray Tray application for Syncthing io.github.martchus.syncthingtray 2.1.2-1.d2aa384 stable flathub
flatpak install syncthingtray
The license does not allow third-party distribution. Dropbox provides packages for supported distros themselves, they are not in any official repos.
I only mount cloud storage using rclone. No flatpacks, no appimages, and no Microsoftie trash. Recommended.
Thanks. I already use Syncthing for syncing some files between machines, but I have yet to make the leap to setting up a NAS/homelab.
One small practical difference is the permissions you actually grant. The Flatpak still needs network access and usually broad access to the Dropbox folder, so I would not treat the sandbox as magic containment. I’d check the Flathub maintainer/source, then look at the permissions with Flatseal or flatpak info --show-permissions com.dropbox.Client and keep the synced folder as narrow as possible.
For AUR, yay -G dropbox should fetch the snapshot so you can inspect both PKGBUILD and any .install file before building.
You should be able to just use it from the official binary since it can auto update in your home folder Dropbox - ArchWiki
That are for Dropbox Nautilus Extension (GitHub - dropbox/nautilus-dropbox: Dropbox Integration for Nautilus · GitHub) not for Dropbox itself
Being proprietary isn’t the main issue, as Arch is repackaging
And Manjaro additionally have Softmaker and Crossover
Adding to this, the “verified”/“unverified” designation on Flathub seems to be whether or not the package maintainer is the developer of the package. It sounds as though both verified and unverified packages receive the same safety checks on Flathub (although an unverified maintainer would not suffer the same reputational damage for a compromised package as a verified one).