Package Details: sirikali 1.4.8-1

Git Clone URL: (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:
Licenses: GPL
Conflicts: sirikali-git
Submitter: ConorIA
Maintainer: ConorIA (mhogomchungu)
Last Packager: ConorIA
Votes: 24
Popularity: 0.80
First Submitted: 2016-12-26 21:50
Last Updated: 2020-12-02 13:33

Dependencies (16)

Required by (0)

Sources (2)

Latest Comments

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

leoneill commented on 2018-02-26 10:41

Before the update, I ran: gpg --recv-keys 0x6855E493B5B2DF96E319BB6D16E2E1ACC6F51242

Unable to update due to invalid key: SiriKali-1.3.3.tar.xz ... FAILED (invalid public key E3AF84691424AD00E099003502FC64E8DEBF43A8) ==> ERROR: One or more PGP signatures could not be verified!

mhogomchungu commented on 2018-02-24 09:15

A new key that uses sha2 can be imported with the following command:

gpg --recv-keys 0x6855E493B5B2DF96E319BB6D16E2E1ACC6F51242

The new signature is named "SiriKali-1.3.3.tar.xz.sha2.asc" and is located at:

ConorIA commented on 2018-02-23 19:03

@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 ( 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

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.



ConorIA commented on 2018-02-22 21:42

@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:

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

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?

beliy commented on 2018-01-16 10:17

Hi, please help fix segfault on my laptop -

mhogomchungu commented on 2017-08-17 20:16

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


"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


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.