Summary: | GPG encryption could not be enabled | ||
---|---|---|---|
Product: | [Applications] kmymoney | Reporter: | Ralf Habacker <ralf.habacker> |
Component: | file | Assignee: | KMyMoney Devel Mailing List <kmymoney-devel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 4.8.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Microsoft Windows | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Bug Depends on: | |||
Bug Blocks: | 381786 |
Description
Ralf Habacker
2017-07-10 21:09:22 UTC
To me, this seems like one of a whole set of related issues due to how KDE on Windows works. On Linux, you can just have KMM depend on GnuPG. On Windows, with the move to a single installer for a single application, I see no way to deal with dependencies like this. I don't know if the Windows build of KMM could be made to include GnuPG, or if it would really be appropriate even if it could. I suspect that depending on a native Windows GnuPG would be even harder and less KDE like. (In reply to Jack from comment #1) > On Linux, you can just have KMM depend on GnuPG. > On Windows, with the move to a single installer for a single application, > I see no way to deal with dependencies like this. yes, with setup.exe installers all stuff need to be bundled into the installer or portable packag. There are components possible in the installer to let user install only a subset. Windows installers build with opensuse build system are snaphots of installed packages including all their dependencies. See https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:kmymoney/mingw32-kmymoney-installer/mingw32-kmymoney-installer.spec?expand=1 where the following list specifies the packages to be included into the installer or portable packages. BuildRequires: mingw32-filesystem BuildRequires: mingw32-gpg2 BuildRequires: mingw32-gpgme BuildRequires: mingw32-kdebase4-runtime BuildRequires: mingw32-kdelibs4-lang BuildRequires: mingw32-khelpcenter-online BuildRequires: mingw32-kmymoney BuildRequires: mingw32-libqt4-tools-dbus BuildRequires: mingw32-dbus-1 >= 1.10.6 BuildRequires: mingw32-libqt4-sql BuildRequires: mingw32-libqt4-sql-sqlite BuildRequires: mingw32-libqt4-sql-mysql # for debug package BuildRequires: mingw32-aqbanking-debug BuildRequires: mingw32-gpgme-debug BuildRequires: mingw32-gwenhywfar-debug BuildRequires: mingw32-kdebase4-runtime-debug BuildRequires: mingw32-kdepimlibs4-debug BuildRequires: mingw32-khelpcenter-online-debug BuildRequires: mingw32-kmymoney-debug BuildRequires: mingw32-ktoblzcheck-debug BuildRequires: mingw32-libalkimia-debug BuildRequires: mingw32-libical-debug BuildRequires: mingw32-libiconv-debug BuildRequires: mingw32-libofx-debug BuildRequires: mingw32-opensp-debug OBS currently provides about 380 packages see https://build.opensuse.org/project/monitor/windows:mingw:win32 > I don't know if the Windows build of KMM could be made to include GnuPG Thanks to the presence of mingw32-gpg2 package it could. > or if it would really be appropriate even if it could. There is still some work required to finish this support. As an example gnupg requires pinentry to provide passphrase dialogs which has not been ported to mingw on obs. There are already compiled executables provided by the windows gnupg port which could be used at first, but in the long run. Additional I recognized that users are required to generate a public/private key pair by hand (by running gpg2 --gen-key) or install an available key pair. Without kmymoney does not allow to enable gpg support. > I suspect that depending on a native Windows GnuPG would be even harder and less KDE like. yes, but is not required as mentioned above. (In reply to Ralf Habacker from comment #2) > There is still some work required to finish this support. As an example > gnupg requires pinentry to provide passphrase dialogs which has not been > ported to mingw on obs. This will be available tomorrow by the mingw32|64-pinentry package. (In reply to Ralf Habacker from comment #2) > Additional I recognized that users are required to generate a public/private > key pair by hand (by running gpg2 --gen-key) or install an available key > pair. Without kmymoney does not allow to enable gpg support. This is common kmymoney behaviour also on linux, so nothing required to fix here. Ralf Habacker from comment #3) > This will be available tomorrow by the mingw32|64-pinentry package. Recent 32bit and 64 bit windows snapshots have working support for gpg encrypted kmymoney files. There may be a documentation update with: Create new key ============== 1. open command shell in kmymoney bin dir 2. run gpg2 --gen-key Import key ========== 1. open command shell in kmymoney bin dir 2. run gpg2 --import <keyfile> Where do you propose to put this documentation? I'll find where it should go in the 4.8.1 manual, but is there any way for KMM to point the user to that if he tries to use encryption but doesn't have a key? What happens if the user already has gnupg installed (either native windows or other KDE for windows version) ? Hopefully just ignore them and use ours? The documentation should also say how to use an existing key, and for that reason, I'm not sure that the kmymoney bin dir is the right place to generate the key (or is that just to find gpg2 and gen-key always puts it in the user's .gnupg dir?) (It's been years since I have generated a key.) (In reply to Jack from comment #6) > Where do you propose to put this documentation? I'll find where it should > go in the 4.8.1 manual, but is there any way for KMM to point the user to > that if he tries to use encryption but doesn't have a key? For the users I guess an extension of the encryption settings dialog to let users create a new key or import an available key would be nice. For example: 1. if gpg has been found make "Use GPG encryption" selectable 2. if users enable gpg and no key has been found, a dialog pops up and let the user create a new key or import a present key. > What happens if the user already has gnupg installed (either native windows or other KDE for windows version) gpg4win and gpg bundled with kmymoney shares C:/Users/xxxx/AppData/Roaming/gnupg/pubring.gpg as key store location. Other installers/package bundling pgp will use the same store location and can share the keys. > ? Hopefully just ignore them and use ours? The keys are shared, the binaries are ignored. > The documentation should also say how to use an existing key, and for that > reason, I'm not sure that the kmymoney bin dir is the right place to > generate the key the bin dir is the directory where the executable lives, not the keys > or is that just to find gpg2 and gen-key always puts it in the user's .gnupg dir?) yes, for the exact path see above |