blob: 2dada0a64bdb3a16558b6af1f9e72bb235f0bbaa (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
|
* Implement posix-sema.c
* Allow to use GTK's main loop instead of the select stuff in
wait.c
* add locking to the key cache?
* Should --delete silently delete secret keys or is there a need for
another flag or a callback?
* GpgmeKey misses GPGME_ATTR_EXPIRE attribute
* Add ATTR to return the number of subkeys or uids.
* Return GPGME_Canceled when appropriate
* Factor out common code in _op_*_start functions.
* Move code common to all engines up from gpg to engine.
* Tests
** t-data
*** Test gpgme_data_release_and_get_mem.
*** Test gpgme_data_rewind for invalid types.
*** Test gpgme_data_read's readable feature.
* Build suite
** Make sure everything is cleaned correctly (esp. test area).
Bugs reported by Stephane Corthesy:
> - When returning a GpgmeKey GPGME_ATTR_COMMENT attribute, characters
> like ":" are not un-escaped, they are returned as \x3a
> BTW, here's another bug: it it not possible to retrieve fingerprints
> for subkeys
> In GpgmeRecipients, would it be possible to provide a function which
> would return the validity assigned to a name contained in the
> GpgmeRecipients instance?
> - There is an inconsistent behaviour: if we pass three times an
> invalid (but non empty) passphrase, return code is GPGME_No_Data, but
> if we pass three times an empty (and invalid) passphrase, we get
> GPGME_No_Passphrase.
> passphrase callback. If I use the same GpgmeContext as the one which
> is currently asking for a passphrase, my app crashes: the r_hd in
> the
> callback has become invalid; if I use a brand new one, the callback
> is called recursively, when I ask to enumerate keys.
|
