Package Details: sirikali 1.8.1-1

Git Clone URL: https://aur.archlinux.org/sirikali.git (read-only, click to copy)
Package Base: sirikali
Description: A Qt/C++ GUI front end to sshfs, ecryptfs-simple, cryfs, gocryptfs, securefs, fscrypt and encfs
Upstream URL: https://mhogomchungu.github.io/sirikali/
Licenses: GPL
Conflicts: sirikali-git
Submitter: None
Maintainer: mhogomchungu
Last Packager: mhogomchungu
Votes: 34
Popularity: 0.41
First Submitted: 2016-12-26 21:50 (UTC)
Last Updated: 2025-01-22 11:49 (UTC)

Dependencies (16)

Required by (0)

Sources (2)

Pinned Comments

mhogomchungu commented on 2024-10-31 10:20 (UTC) (edited on 2024-11-07 15:57 (UTC) by mhogomchungu)

Those who are experiencing error in source verification, please run the following command first before building.

gpg --keyserver hkps://pgp.surf.nl --recv-keys 16E2E1ACC6F51242

<deleted-account> commented on 2017-05-17 15:52 (UTC)

Adding GPG signature check as per @egrupled's comment. You will need to run: `gpg --recv-keys 5F96A606C4F72905`

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

<deleted-account> commented on 2018-02-23 19:03 (UTC)

@mhogomchungu thanks for the further details. I'd suggest that users who can't accept the SHA-1 sig should use the PKGBUILD in the snapshot (https://goo.gl/UXTWvq) until you make a new release. Using the AUR is considered "advanced" usage for Arch et al., so I would expect users to be able to implement this workaround themselves. I will update this PKGBUILD when you've made a new release or if Arch also moves away from SHA-1 before a new release.

However, another option would be for you to create a new .asc signature on the old .tar.xz file, which I could swap in for the older signature temporarily. Is there something specific about your release process that prevents that from happening?

mhogomchungu commented on 2018-02-23 06:27 (UTC)

I was notified of the issue through email and here[0] is the text of the email i received.

Newer versions of debian and ubuntu do not accept sha1 using certificates[1] and it maybe that Antergos has patched their version of gpg to follow what these distributions are using.

I too should move away from sha1 because i think more and more people will start to be affected by this if i do not and i will do that with the next release of SiriKali.

[0] https://imgur.com/a/p8xP5

[1] https://github.com/git-lfs/git-lfs/issues/1110

<deleted-account> commented on 2018-02-22 21:42 (UTC)

@mhogomchungu, I made that change, but I reverted.

I also have: gpg 2.2.4 (with libgcrypt 1.8.2) and have no problems with the sig. I don't see why we should compromise the security for all users when there is only one user who is affected.

To the Antergos user: remove the .asc source entry, the 'SKIP' sum and the valid PGP key as done here: 3afde86dbb70 (Snapshot: https://goo.gl/UXTWvq)

P.S. @mhogomchungu, can't see an issue for this on GitHub. Was this an email chain? Feel free to forward the info and I'll see if the errors give me a hint as to what is going on.

mhogomchungu commented on 2018-02-22 07:18 (UTC) (edited on 2018-02-22 07:18 (UTC) by mhogomchungu)

I have received a report from Antergos (Arch-based) user who said their build is failing because the gpg version they are using(2.2.4) is refusing to accept a sha1 using signature.

Arch linux is using the same version of gpg and why is it that the problem does not exist here?

Will update the signature to make it use sha2 with the next version of SiriKali to address this issue but we are stuck with this signature for now and will appreciate a work around in the mean time.

Will appreciate a work around to this problem for now. How should be build file be edited to accept a build without a valid signature?

bko commented on 2018-01-16 10:17 (UTC)

Hi, please help fix segfault on my laptop - https://github.com/mhogomchungu/sirikali/issues/54

mhogomchungu commented on 2017-08-17 20:16 (UTC) (edited on 2018-02-25 09:55 (UTC) by mhogomchungu)

It is necessary to import a key that was used to sign the SiriKali archive to build the project.

You can install the key by running the following command:

gpg --recv-keys 0x6855E493B5B2DF96E319BB6D16E2E1ACC6F51242

avamk commented on 2017-05-22 15:07 (UTC)

@mhogomchungu "Your problem is most likely not due to SiriKali but Qt mismatch between the version you currently have and the version KDE was build against." Ah yes that turned out to be the key. I discovered that library paths were set up in my environment variables that caused a mismatch in QT libraries. I changed it in my environment variables and building SiriKali worked. Thank you!!

mhogomchungu commented on 2017-05-20 18:38 (UTC) (edited on 2017-05-21 04:34 (UTC) by mhogomchungu)

@avamk Edit: Post the entire output of your build process. Your problem is most likely not due to SiriKali but Qt mismatch between the version you currently have and the version KDE was build against. The solution to your current problem are: 1. Build SiriKali without kwallet support. 2. Rebuild KDE against your currently updated Qt version.

avamk commented on 2017-05-20 18:10 (UTC)

I'd just like to report that I ran "gpg --recv-keys 5F96A606C4F72905" which allowed me to actually start the build process (it previously refused to even start). Unfortunately, build still fails with the same error as before even with manually changing line 46 per your previous response: [ 92%] Linking CXX executable sirikali /usr/lib/libKF5Wallet.so.5.34.0: undefined reference to `qt_version_tag@Qt_5.8' /usr/lib/libKF5Wallet.so.5.34.0: undefined reference to `QIODevice::isTransactionStarted() const@Qt_5' /usr/lib/libKF5ConfigCore.so.5: undefined reference to `QDateTime::QDateTime(QDateTime&&)@Qt_5' /usr/lib/libKF5WindowSystem.so.5: undefined reference to `QJsonValue::toString() const@Qt_5' collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/sirikali.dir/build.make:1134: sirikali] Error 1 make[1]: *** [CMakeFiles/Makefile2:102: CMakeFiles/sirikali.dir/all] Error 2 make: *** [Makefile:130: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

egrupled commented on 2017-05-17 19:15 (UTC)

@ConorIA thanks, it works great!

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »