Package Details: spideroak-one 7.5.0-1

Git Clone URL: https://aur.archlinux.org/spideroak-one.git (read-only, click to copy)
Package Base: spideroak-one
Description: Secure file backup, sync and sharing client. This provides the client for SpiderOakONE.
Upstream URL: https://crossclave.com/
Keywords: backup
Licenses: custom
Conflicts: spideroak, spideroak-beta
Provides: spideroak
Replaces: spideroak
Submitter: warnem2
Maintainer: mbc
Last Packager: mbc
Votes: 269
Popularity: 0.004740
First Submitted: 2015-07-18 19:17 (UTC)
Last Updated: 2023-09-04 21:57 (UTC)

Latest Comments

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 .. 27 Next › Last »

warnem2 commented on 2015-05-18 23:16 (UTC)

@infinitezero: Sounds to me like an upstream issue. You really should contact the developers: https://spideroak.com/help/

infinitezero commented on 2015-05-18 21:07 (UTC)

Makes me wonder if this is a marriage issue between the .rpm and Gnome 3.

infinitezero commented on 2015-05-18 21:03 (UTC)

I have a fix for the issue. The variable that is different, is the package used to create the AUR version, it is from the .rpm, not the .deb. Make sure you have uninstalled the previous SpiderOak install from the AUR. 01. Install deb2targz: $ pacaur -Syu deb2targz 02. Download current .deb from SpiderOak: 03. Convert: $ deb2targz spideroak_5.2.0_amd64.deb 04. Decompress: $ tar -xzvf spideroak_5.2.0_amd64.tar.gz 05. Copy the following newly created directories (etc, usr, opt) as follows: $ sudo cp -r etc/ / $ sudo cp -r usr/ / $ sudo cp -r opt/ / 06. Start SpiderOak and set it to, "Launch SpiderOak at OS Startup" $ SpiderOak ## Is case sensitive. 07. Reboot Now SpiderOak will automatically scan for changes like it should.

infinitezero commented on 2015-05-18 20:15 (UTC)

I have noticed over the last 5 months or so SpiderOak does not automatically (or if you set a time) scan the directories for changed files and upload them. I have not seen this issue with other distros running SpiderOak (for example Debian 7 & 8 and Ubuntu 14.04.2), only Arch, is there a fix for it? I have seen the same symptom on two different fresh Arch installs, and two different (fresh) installs of SpiderOak, include the most current 5.2.0. If I make a change a to file, or add a new file, SpiderOak does not detect it (not scanning for changes) unless I manual tell it to scan, or kill it and then restart it. I have even set it to backup every 5 minutes and it still does not scan for changes. All distros running gnome-shell. There is at least one other user experiencing the same issue. https://bbs.archlinux.org/viewtopic.php?pid=1529938#p1529938

warnem2 commented on 2015-03-14 18:56 (UTC)

I've decided that I'm not going to include SpiderOak's PGP signature in this PKGBUILD. My reasons are too numerous to list here, but suffice it to say that I don't think it's appropriate. Feel free to contact me directly (email's in the PKGBUILD) if you want to discuss further. I still want to improve the PKGBUILD wherever I can, so I've changed from sha1sum to sha256sum. I think this will allow users to better verify the integrity of the RPM.

cb474 commented on 2015-03-12 00:27 (UTC)

@coolpyfreak I got a response from SpiderOak explaining what's going on with the GPG keys. Apparently with the .deb files, it's not the package itself that is signed. Apt (in Debian distros) using a sha1sum to verify the file and the sha1sum is signed with GPG. So that's what apt checks, if one uses the spideroak apt repository and apt to update spideroak. With the rpm files it is the .rpm package itself that is signed. And then rpm checks the package. However spideroak failed to update the signature, found in the blog post that you link to below. They said they are going to correct that, but have not yet. But I was sent the new signature as an attachment in an email. I'm not really sure how this signature can be used in Arch to verify the .rpm package, if one is not using rpm to do this. I sent an email asking if there's a way to verify the .rpm with gpg itself. Perhaps you know more than I do about how to do this (I'm getting a little beyond my cursory gpg knowledge). I guess I can't attach the .rpm signature I was sent here, but I could just copy and paste the text of it into a comment, if you want. But then you'd be getting it from me, rather than directly from SpiderOak's website, which kind of breaks the chain of trust. So perhaps it's better to wait until the SpiderOak website is updated. That's the latest info I have.

cb474 commented on 2015-03-09 22:56 (UTC)

@coolpyrofreak Yes the key for the .deb packages is newer and has not expired yet. But as far as I can tell the actual .deb downloads for Spideroak have not been signed with GPG. I'm still waiting to hear back from SpiderOak about this. I got an intial response form someone who did not have an answer, but said he would check with other people.

nesk_aur commented on 2015-03-08 06:28 (UTC)

@cb474 They updated the key for .deb packages just 1 year ago, can you check please? https://blog.spideroak.com/20130920145427-ubuntudebian-apt-repository-gpg-key-update

cb474 commented on 2015-03-08 00:29 (UTC)

@coolpyrofreak That blog post that you link to is six years old. The GPG key in that post expired four years ago. It's even more out of date that the GPG key for the .deb files. In any case, it also does not appear in the PKGBUILD for this AUR version of of SpiderOak that the download is being verified with GPG (the sha1sum check does not accomplish the same thing). As I said, as far as I can tell, there are no GPG keys for SpiderOak anymore. I'm emailing them and waiting for a response. In the meantime, in principle, it seems there is no way to know that this install of SpiderOak has not been compromised. If it was something else, I might not be as concerned. But if one is going out of one's way to use the sort of zero knowledge encryption that SpiderOak provides, it really kind of defeats the purpose not to verify the package with GPG.

warnem2 commented on 2015-03-07 05:06 (UTC)

@cb474 - They sign the RPMs used for this PKGBUILD. Read here: https://blog.spideroak.com/20090219070000-hello-fedora