- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Sep 8 2023
Sep 7 2023
this works now:
I think using a static const char * is better than using a macro. In fact, using a static constexpr std::string may be even better because we avoid calculating the string length during runtime again and again. (I'm not sure the compiler is clever enough to precalculate the string length of a static const char *.)
Tested at first with GnuPG-VS-Desktop-3.2.0.0-beta178 from 2023-08-29
@ebo: I just a did a test build: gnupg-vs-desktop-3.2.0-beta178-x86_64.AppImage in my directory
This has been well tested during development and is thus ready for a release.
Sep 6 2023
That should be easy on Unix but on Windows we have the nul nul: and iirc also /dev/nul.
ack
In T5960#175317, @ikloecker wrote:The previous two changes will hopefully fix the error output of export to server. I'm not entirely sure about the missing line breaks.
In T6556#175399, @werner wrote:@iklocker: Which gpg bug to you mean?
Then gettext_use_utf8 doesn't seem to be working as intended.
We have a fix for now and thus I lower the priority. Given that EasyPG mimics the GPGME API we should here also use another pipe to convey the passphrase (e.g. for symmetric encryption).
I don't see a value to do this for 2.2 and introduce a regression with that.
@iklocker: Which gpg bug to you mean?
Seems to be solved in the current version (vsd 3.2.0-beta178).
In T5960#175318, @ikloecker wrote:Also, please retest T5960#172860 with the latest build.
I misunderstood the issue. When I created the GnuPG VS-Desktop package I did not wrote a qt.conf file which thanks to our patch https://dev.gnupg.org/source/gpg4win/browse/master/patches/qtbase/0001-Gpg4win-qstandardpaths-patch.patch caused all config files for Gpg4win to be placed under %APPDATA%\kleopatra. This was by accident since it uses NSIS FileWrite and FileWrite is not supported in our NSIS to MSI packaging.
Another customer case with "always show security-dialog" on (-> external resolver):
It might actually be useful to have an random number API in gpgme. When we do that we can also add a way t search for random numbers with an upper limit in each octet.
Bugs goes back to 2002 where we stopped checking trust for keys without any signature. This was really useful but has this strange behaviour.
Hopefully, we will soon have a Windows CI to catch such errors.
/home/aheinecke/dev/main/src/gpg4win/src/playground/build/libkleo-202309061056/src/utils/gnupg.cpp: In function 'QString Kleo::stringFromGpgOutput(const QByteArray&)': /home/aheinecke/dev/main/src/gpg4win/src/playground/build/libkleo-202309061056/src/utils/gnupg.cpp:573:53: error: passing 'const QByteArray' as 'this' argument discards qualifiers [-fpermissive] 573 | const auto s = fromEncoding(cpno, ba.replace("\r\n", "\n").constData()); | ~~~~~~~~~~^~~~~~~~~~~~~~ In file included from /home/aheinecke/dev/main/src/gpg4win/src/playground/install/include/QtCore/qstring.h:50, from /home/aheinecke/dev/main/src/gpg4win/src/playground/install/include/QtCore/qhashfunctions.h:44, from /home/aheinecke/dev/main/src/gpg4win/src/playground/install/include/QtCore/qlist.h:47, from /home/aheinecke/dev/main/src/gpg4win/src/playground/install/include/QtCore/qstringlist.h:41, from /home/aheinecke/dev/main/src/gpg4win/src/playground/install/include/QtCore/QStringList:1, from /home/aheinecke/dev/main/src/gpg4win/src/playground/build/libkleo-202309061056/src/utils/gnupg.h:16, from /home/aheinecke/dev/main/src/gpg4win/src/playground/build/libkleo-202309061056/src/utils/gnupg.cpp:18: /home/aheinecke/dev/main/src/gpg4win/src/playground/install/include/QtCore/qbytearray.h:738:20: note: in call to 'QByteArray& QByteArray::replace(const char*, const char*)' 738 | inline QByteArray &QByteArray::replace(const char *before, const char *after)
BTW, with one of the recent gpgme fixes we now get
$~/b/gpgme/tests/run-keylist --extern --verbose foo run-keylist: file /home/wk/s/gpgme/tests/run-keylist.c line 414: <Dirmngr> No keyserver available
which is what users (and kleopatra) expects.
Note that for vsd we also need to change our default configuration file. The new "none" value provides a better error message than the old default of assuming that the AD carries the keyserver (which it does not in practise).
Thank you.
Backported to 2.2 branch.