-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:
-** Figure out if _gpgme_io_pipe should pre-create reader/writer and if we
- then can use !start_it in most invocations. Note that gpgme_io_dup
- probably should always use !start_it, because currently it will
- always create reader/writer if they don't exist(!?).
** Some gpg tests fail with gpg 1.3.4-cvs (gpg/t-keylist-sig)
The test is currently disabled there and in gpg/t-import.
** When gpg supports it, write binary subpackets directly,
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
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
projects / gpgme.git / blobdiff