Aug 13 2021
Jan 11 2021
We discussed this, the proper solution will be for gpgtar to accept unicode arguments on windows.
The problem is not with creation, that works. The problem is also not with files contained in the archive, they also work. The problem is the archive name. And that also seems to be correct in the way gpgtar extracts it as gpgtar successfully extracts the archive, but the created folder name has the broken character.
Jan 8 2021
I can't replicate this on the command line. Anyway option -T is only valid with --create. Further the archive format is specified to carry utf8 filenames; thus --utf8-strings won't have an effect on --extract. Are you sure that Kleopatra runs
gpgtar --create --utf-strings -T -
and you pass utf-8 encoded filenames on stdin?
Nov 25 2020
Works, I've tested with Kleopatra.
Sep 15 2020
Using a not yet existing directory is a security feature. The directory is created at a time the signature has not yet been verified and thus it would be too easy to trick a user into overwriting important data.
Sep 7 2020
Sep 5 2020
I will consider a -p option for gpgtar.
Aug 27 2020
Aug 24 2020
What is the current encoding? OEMCP ?
So if gnupg version >= 2.2.22 Kleopatra needs to convert the passed filenames to UTF-8 and pass them with the --utf8-strings option to gpgtar. This needs to be changed in Kleo. -> Assigned to me.
Aug 22 2020
Excellent! thanks for having considered this.
Done for master and 2.2.22 - libgpg-error 1.39 (not yet released) is required for the actual fix.
Aug 20 2020
The options now work as documented. More tests on Window are required and eventually we need to handle non-ascii characters in file names.
Aug 18 2020
It is indeed a limitation. We added these options to support the Kleopatra GUI. To avoid problems with filenames with embedded newlines etc. Kleoptra uses a binary nuls to delimit filenames. And that is what we only support.
Dec 16 2019
Jun 4 2019
I did forget to mention that the key I'm using is 4096 bit long
I was creating a tar archive with 7-Zip on my Windows 10 machine. After the creating was completed I was encrypting the archive like so:
Just to clarify, you were able to decrypt and extract it without error? Which tool did you use to extract the tar archive?
I did encrypt the file myself with the version mentioned above.
Jun 3 2019
Maybe the file was encrypted with a version of gpg4win-3.1.5? We had a serious bug there that sometimes files were corrupted. See: T4332
Mar 6 2019
Jan 14 2019
Jul 17 2018
Mar 13 2018
(BTW, --create is not an option - you meant --encrypt)
That is not easy to fix in a shell script. I would prefer to get rid of gpg-zip or make it a simple wrapper around gpgtar like
Nov 15 2017
FWIW, I added a gpgtar.1
Pushed to 2.2
You could use the --directory option. However< I agree that your suggested changes is less surprising then the current behaviour. Thus I would consider this a bug fix. Can you please apply to 2.2?
Nov 14 2017
Jul 27 2017
To remain compatible with PGP6 we are limited to ustar. If you want to support other archive types, archive first and then encrypt/sign the archive.
Mar 30 2017
Sep 19 2016
@werner, if I understand the description at
then ustar would also be able to read "posix" archives.
ustar is the format introduced by PGP 6; also for Windows. This is the only
reason we use it. PGP users demanded that we support that "pgpzip". We can't
Sep 15 2016
What I meant by "KArchive" is that we already have all that nice archiving code
in Kleopatra already: https://api.kde.org/frameworks/karchive/html/index.html
To work with standard formats like tar / zip / 7zip etc.
This would get us the included platform abstraction through Qt for stuff like
filenames etc. and we wouldn't have to maintain our own implementations for
these archive formats.
Can you create a new issue with the data "loss" part?
As for the default format:
I think we should use and propose a default format that is mostly compatible
over platforms (and robust in the future). tar "posix" seems to be
such a format. Am not sure how this evaluates for karchive or 7zip.
https://www.gnu.org/software/tar/manual/html_section/tar_68.html gives a good
So yes raising the file name length limit could be problematic with
compatibility and we might have to change more in our implementation to create
formats of a different spec.
From the discussion in the forum it looks like the error was silently discarded
when used in Kleopatra. We need error handling in that case. So I think this is
an Urgent bug as silent discard of archive contents can lead to data loss. So
for me this part is an urgent bug. Actually handling longer filenames is another
As a sidenote:
Kleopatra already links KArchive for svgz handling so it already contains a good
API for ZIP file creation. I'd like to add that to Kleopatra and make it default
so that the default is not our own error prone tar implementation. (Other tar
implementations also are problematic for windows). In that case we could also
drop the extraction as zip file support is native in the windows file explorer.
And as suggested in the forum entry we should probably also document how to add
7zip support to kleopatra or check for this at runtime and add some 7zip archive
options if it is available.
This should be doable by editing libkleopatrarc but I'd have to check the syntax
myself in the code as its not documented afaik.