With caching, did you have something like this in mind?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
Sat, May 18
Actually we are using gpgme already for 64 bit Windows; but statically linked.
Fri, May 17
In T7036#186290, @ebo wrote:Tested with VS-Desktop-3.2.93.391-Beta:
Tested with VS-Desktop-3.2.93.391-Beta:
Thu, May 16
Hopefully fixed by disabling the DeviceInfoWatcher on Windows again.
Fri, May 10
Ah, I see what's up with the man page. It's documenting the Glibc getdents64() wrapper interface, so that's why it uses the Glibc types. But gpgme isn't using that wrapper, it's doing the syscall directly, so it should use the types the kernel uses, which as you've noticed are just generic unsigned and signed 64-bit integers, matching what my patch does.
Wed, May 8
/include/linux/dirent.h defines
struct linux_dirent64 { u64 d_ino; s64 d_off; unsigned short d_reclen; unsigned char d_type; char d_name[]; };
In D600#6448, @ikloecker wrote:$ man getdents64
getdents64() The original Linux getdents() system call did not handle large filesystems and large file offsets. Consequently, Linux 2.4 added getdents64(), with wider types for the d_ino and d_off fields. In addition, getdents64() supports an explicit d_type field. The getdents64() system call is like getdents(), except that its second argument is a pointer to a buffer containing struc‐ tures of the following type: struct linux_dirent64 { ino64_t d_ino; /* 64-bit inode number */ off64_t d_off; /* 64-bit offset to next structure */ unsigned short d_reclen; /* Size of this dirent */ unsigned char d_type; /* File type */ char d_name[]; /* Filename (null-terminated) */ };
$ man getdents64
getdents64() The original Linux getdents() system call did not handle large filesystems and large file offsets. Consequently, Linux 2.4 added getdents64(), with wider types for the d_ino and d_off fields. In addition, getdents64() supports an explicit d_type field.
If it is intentional change by musl (requiring some changes by an application), we can use __ino64_t_defined and __off64_t_defined macro to see if those types are defined or not.
Fixed in gpgme 1.21.0.
If it is intentional change by musl (requiring some changes by an application), we can use __ino64_t_defined and __off64_t_defined macro to see if those types are defined or not.
Tue, May 7
Mon, May 6
Meanwhile version 1.32.2 builds. Greatest change is Python 3.12 instead of 3.11…
off64_t mat not the same as int64_t
Breaks them how?
This breaks existing 32 bit systems with the 64 bit types. Thus a test for off64_t is required which redefines it to int64_t if it does not exist.
Fri, May 3
Tue, Apr 30
Mon, Apr 29
Sorry, I meant they do *not* arrive at the web interface, they are not visible to me.
It seems my eMails to gnupg-devel@gnupg.org do reach the list …
Apr 17 2024
Of course, it should be possible to toggle "disabled" in Kleopatra.
A (context) menu entry "disable certificate" (or "enable certificate") should be sufficient.
Apr 16 2024
Apr 11 2024
Apr 5 2024
Oops. I closed the task accidentally.
Fixed (for GnuPG 2.4). I hope 2.2 prints the same status messages.
The General Error happens also when the PIN is blocked and no Pinentry opens.
As in this case, where the indicated "Generate New Keys" button was used on a blocked card.
Mar 28 2024
Trying to reach Ralph Seichter via the eMail address he is using failed – Osterferien?
Mar 25 2024
strcasecmp is pretty standard on Unix. However, in GnuPG we test for it and mostly use our own ascii_strcasecmp to avoid fun with locales. Ralph Seichter is providing macOS builds for GnuPG (https://sourceforge.net/p/gpgosx/docu/Download/) . Maybe it is worth to contact him via the gnugp-devel mailing list and ask him whether he has experience with your toochain.
By adding "-Wl,-t" to the arguments g++ reported:
Libtool invocation has "--tag=CXX --mode=link /opt/local/bin/g++-mp-7 -std=c++11 -pipe -Os -std=c++17 -D_GLIBCXX_USE_CXX11_ABI=0", but g++ then has no -lstdc++ – in C -lc is automatically used because there all C library functions can be taken from… (same for mathematical functions and -lm)
It seems libtool fails to add the standard C and C++ libraries to the link command line. On Linux I have "[...] -lstdc++ -lm -lc [...]" in the libtool link command line. Looks like a bug in the tooling (macports or libtool).
Mar 24 2024
Mar 23 2024
Thanks, that patch works for me.
Mar 18 2024
Mar 15 2024
We have discussed this yesterday. The idea/plan is to release the core library and the bindings as separate tarballs (created from the same repo) in the future.
Mar 11 2024
This can be tested with Kleopatra by configuring an invalid keyserver and then updating an OpenPGP certificate.
Mar 1 2024
In 2.4 we have rG1383aa475 which does
Pushed the change in: rGf50c543326c2: agent: Allow simple KEYINFO command when restricted.
Feb 29 2024
No, thank you both for the speedy responses :)
Thanks a lot for your quick testing.
The commit rGff42ed0d69bb: gpg: Enhance agent_probe_secret_key to return bigger value. of GnuPG 2.2 introduced this bug.
Ah, thanks Werner, I'll keep that in mind.
Feb 28 2024
Although I don't think this is the case here one should be aware that tests mail fail due to global configuration of GnuPG (/etc/gnupg/*.conf). There is no easy way so solve this except for running a per-test local installation of GnuPG using the gpgconf.ctl feature.
You can get more information by applying a patch below (and also tests/json/Makefile.in):
diff --git a/tests/json/Makefile.am b/tests/json/Makefile.am index 90fba79e..7523bb6b 100644 --- a/tests/json/Makefile.am +++ b/tests/json/Makefile.am @@ -106,6 +106,8 @@ gpg-agent.conf: # a key from a smartcard reader (error might be: Unusable secret key) echo pinentry-program $(abs_srcdir)/../gpg/pinentry > ./gpg-agent.conf echo disable-scdaemon >> ./gpg-agent.conf + echo debug-all >> ./gpg-agent.conf + echo log-file /tmp/gpg-agent-logfile.log >> ./gpg-agent.conf
T4820 is not related (it's a failure of t-keylist-secret in t-json), while this is failure of t-decrypt.
Feb 27 2024
Arghh, a GPGME_DEBUG=3 which shows basic I/O preparation does not exhibit the bug.
Fixing gpg is easy but there is some bug lingering in gpgme which might be a recent regression. An strace shows
Feb 23 2024
Feb 20 2024
gpg --list-packets shows this:
In T6977#183049, @Karam wrote:Uploaded the corrupted file.
Uploaded the corrupted file.
Feb 16 2024
Can you make this corrupted file available to us?
Hello,
So after testing on gpgme-1.17.1, with run-verify under tests as you mentioned, with corrupted file it hangs forever.
Now we can say it's a bug in gpgme_op_verify.
Feb 15 2024
Feb 8 2024
We provide the examples for a reason. Actually, two reasons: To test our changes ourselves. And to provide working examples for others. If your code doesn't work then you'll have to figure out where the example and your code differ. If the example doesn't work then we'll have a look.
@Karam, please test as suggested by @ikloecker.
@werner I 'm not passing nullptr to gpgme_data_release.
@ikloecker Honestly I didn't test it.
Is there anything wrong with code ? have anyone encountered such behavior ?
I was trying adding a timeout as a workaround for gpgme_op_verify to avoid hanging but it depends on the file size and how much it will take to verify it signature...
Feb 7 2024
Oh well, it does not use the c++ binding .
Yes that probably gets lost along the way, where we communicate with scdaemon to generate the key. Needs to be tracked down. Such things can be very confusing to users. Especially if that increases the PIN Retry counter!
Jan 31 2024
Jan 24 2024
Just a reminder, this is important for 384 bit keys (see T6379).