-Hey Emacs, this is -*- outline -*- mode!
+Hey Emacs, this is -*- org -*- mode!
+
+* Document all the new stuff.
+* Fix the remaining UI Server problems:
+** VERIFY --silent support.
+** ENCRYPT/DECRYPT/VERIFY/SIGN reset the engine, shouldn't be done with UISERVER?
+
+* IMPORTANT
+** When using descriptor passing, we need to set the fd to blocking before
+ issueing simple commands, because we are mixing synchronous
+ commands into potentially asynchronous operations.
+** Might want to implement nonblock for w32 native backend! Right now,
+ we block reading the next line with assuan.
* Before release:
** Some gpg tests fail with gpg 1.3.4-cvs (gpg/t-keylist-sig)
and parse SUBPACKET status lines.
* ABI's to break:
+** Old opassuan interface.
+** Implementation: Remove support for old style error codes in
+ conversion.c::_gpgme_map_gnupg_error.
** gpgme_edit_cb_t: Add "processed" return argument
(see edit.c::command_handler).
** I/O and User Data could be made extensible. But this can be done
without breaking the ABI hopefully.
-* All enums that should be enums need to have a maximum value to ensure
- a certain minimum width for extensibility.
+** All enums should be replaced by ints and simple macros for
+ maximum compatibility.
** Compatibility interfaces that can be removed in future versions:
*** gpgme_data_new_from_filepart
*** gpgme_data_new_from_file
There is a configure time warning, though.
* New features:
+** Flow control for data objects.
+ Currently, gpgme_data_t objects are assumed to be blocking. To
+ break this assumption, we need either (A) a way for an user I/O
+ callback to store the current operation in a continuation that can
+ be resumed later. While the continuation exists, file descriptors
+ associated with this operation must be removed from their
+ respective event loop. or (B) a way for gpgme data objects to be
+ associated with a waitable object, that can be registered with the
+ user event loop. Neither is particularly simple.
** Extended notation support. When gpg supports arbitrary binary
notation data, provide a user interface for that.
** notification system
application can then do whatever is required. There are other
usages too. This notfication system should be independent of any
contextes of course.
+
+ Not sure whether this is still required. GPGME_PROTOCOL_ASSUAN is
+ sufficient for this.
+
** --learn-code support
This might be integrated with import. we still need to work out how
- to learn a card when gpg and gpgsm have support for smartcards.
+ to learn a card when gpg and gpgsm have support for smartcards. In
+ GPA we currently invoke gpg directly.
+
** Might need a stat() for data objects and use it for length param to gpg.
** Implement support for photo ids.
** Allow selection of subkeys
*** Allow to export secret keys.
Rejected because this is conceptually flawed. Secret keys on a
smart card can not be exported, for example.
+ May eventually e supproted with a keywrapping system.
*** Selecting the key ring, setting the version or comment in output.
Rejected because the naive implementation is engine specific, the
configuration is part of the engine's configuration or readily
about where to guarantee what (ie, what happens if start fails, are
the fds unregistered immediately - i think so?)
Note that we need support in gpgsm to set include-certs to default
- as RESET does not reset it.
-** Optimize the case where a data object has 0an underlying fd we can pass
+ as RESET does not reset it, also for no_encrypt_to and probably
+ other options.
+** Optimize the case where a data object has an underlying fd we can pass
directly to the engine. This will be automatic with socket I/O and
descriptor passing.
** Move code common to all engines up from gpg to engine.
(it's an internal error, as select_protocol checks already).
** When server mode is implemented properly, more care has to be taken to
release all resources on error (for example to free assuan_cmd).
+** op_import_keys and op_export_keys have a limit ion the number of keys.
+ This is because we pass them in gpg via the command line and gpgsm
+ via an assuan control line. We should pipe them instead and maybe
+ change gpg/gpgsm to not put them in memory.
+
* GPG breakage:
** gpg 1.4.2 lacks error reporting if sign/encrypt with revoked key.
** gpg 1.4.2 does crappy error reporting (namely none at all) when
** Map ASSUAN/GpgSM ERR error values in a better way than is done now. !!
** Some error values should identify the source more correctly (mostly error
values derived from status messages).
+** In rungpg.c we need to check the version of the engine
+ This requires a way to get the cached version number from the
+ engine layer.
+
* Tests
** Write a fake gpg-agent so that we can supply known passphrases to
projects / gpgme.git / blobdiff