2005-11-17 Marcus Brinkmann <marcus@g10code.de>
[gpgme.git] / TODO
diff --git a/TODO b/TODO
index d9f5118..e74c5ab 100644 (file)
--- a/TODO
+++ b/TODO
 Hey Emacs, this is -*- outline -*- mode!
 
+* Before release:
+** 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.
+** External key listing for OpenPGP.
+   This probably requires changes at gpg.
+
+
 * ABI's to break:
-** string representation of non-secret keys and ATTR_IS_SECRET is NULL,
-   which can not be differentiated from the case that it is not
-   representable.
+** 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.
+** Compatibility interfaces that can be removed in future versions:
+*** gpgme_data_new_from_filepart
+*** gpgme_data_new_from_file
+*** gpgme_data_new_with_read_cb
+*** gpgme_data_rewind
+*** gpgme_op_import_ext
+*** gpgme_get_sig_key
+*** gpgme_get_sig_ulong_attr
+*** gpgme_get_sig_string_attr
+*** GPGME_SIG_STAT_*
+*** gpgme_get_sig_status
+*** gpgme_trust_item_release
+*** gpgme_trust_item_get_string_attr
+*** gpgme_trust_item_get_ulong_attr
+*** gpgme_attr_t
+*** All Gpgme* typedefs.
+
 
 * Thread support:
-** Build thread modules for static linking (which just suck in the
-   desired symbols the hard way). !!
+** When GNU Pth supports sendmsg/recvmsg, wrap them properly.
+** Without timegm (3) support our ISO time parser is not thread safe.
+   There is a configure time warning, though.
 
-* cleanup the namespace - we use log_* assuan_* ascii_*.
-  But those are only used internally.  Some linker tricks should make
-  it possible to hide them from the user (didn't work last time, try
-  again). !!
+* New features:
+** Extended notation support.  When gpg supports arbitrary binary
+   notation data, provide a user interface for that.
+** notification system
+   We need a simple notification system, probably a simple callback
+   with a string and some optional arguments.  This is for example
+   required to notify an application of a changed smartcard, The
+   application can then do whatever is required.  There are other
+   usages too.  This notfication system should be independent of any
+   contextes of course.
+** --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.
+** 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 return time stamps in ISO format
+  This allows us to handle years later than 2037 properly.  With the
+  time_t interface they are all mapped to 2037-12-31
+** New features requested by our dear users, but rejected or left for
+   later consideration:
+*** Allow to export secret keys.
+    Rejected because this is conceptually flawed.  Secret keys on a
+    smart card can not be exported, for example.
+*** 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
+    worked around in a different way
+*** Selecting the symmetric cipher.
+*** Exchanging keys with key servers.
 
 * Documentation
-** Add note about GPGME clearing out pointer return values.
-** validity/trust
+** Document validity and trust issues.
+** In gpgme.texi: Register callbacks under the right letter in the index.
 
 * Engines
+** Do not create/destroy engines, but create engine and then reset it.
+   Internally the reset operation still spawns a new engine process,
+   but this can be replaced with a reset later.  Also, be very sure to
+   release everything properly at a reset and at an error.  Think hard
+   about where to guarantee what (ie, what happens if start fails, are
+   the fds unregistered immediately - i think so?)
+** 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.
 ** engine operations can return General Error on unknown protocol
    (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).
-** GnuPG
-*** For pipemode, make sure to release the pipemode callback data object.
+   release all resources on error (for example to free assuan_cmd).
 
 * Operations
-** Passphrase callback should not copy password. !!!
-** Export status handler need much more work.
+** If an operation failed, make sure that the result functions don't return
+   corrupt partial information. !!!
+   NOTE: The EOF status handler is not called in this case !!!
+** Verify must not fail on NODATA premature if auto-key-retrieval failed.
+   It should not fail silently if it knows there is an error. !!!
+** All operations: Better error reporting. !!
+** Export status handler need much more work. !!!
 ** Import should return a useful error when one happened.
+*** Import does not take notice of NODATA status report.
+*** When GPGSM does issue IMPORT_OK status reports, make sure to check for
+    them in tests/gpgs m/t-import.c.
+** Verify can include info about version/algo/class, but currently
+   this is only available for gpg, not gpgsm.
+** Return ENC_TO output in verify result.  Again, this is not available
+   for gpgsm.
 ** Genkey should return something more useful than General_Error.
-** Factor out common code in _op_*_start functions.
-** Add ATTR to return the number of subkeys or uids.
-** "When returning a GpgmeKey GPGME_ATTR_COMMENT attribute, characters  
-   like ":" are not un-escaped, they are returned as \x3a" Bug
-   reported by Stephane Corthesy.
+** If possible, use --file-setsize to set the file size for proper progress
+   callback handling.  Write data interface for file size.
+** Optimize the file descriptor list, so the number of open fds is
+   always known easily.
+** Encryption: It should be verified that the behaviour for partially untrusted
+   recipients is correct.
+** When GPG issues INV_something for invalid signers, catch them.
 
 * Error Values
 ** Map ASSUAN/GpgSM ERR error values in a better way than is done now. !!
-** Verify (and document) if Read_Error, Write_Error, Pipe_Error set errno.
+** Some error values should identify the source more correctly (mostly error
+   values derived from status messages).
 
 * Tests
 ** Write a fake gpg-agent so that we can supply known passphrases to
@@ -49,8 +127,10 @@ Hey Emacs, this is -*- outline -*- mode!
    clever idea. !
 ** t-data
 *** Test gpgme_data_release_and_get_mem.
-*** Test gpgme_data_rewind for invalid types.
-*** Test gpgme_data_read's readable feature.
+*** Test gpgme_data_seek for invalid types.
+** t-keylist
+   Write a test for ext_keylist.
+** Test reading key signatures.
 
 * Debug
 ** Handle malloc and vasprintf errors.  But decide first if they should be
@@ -58,17 +138,22 @@ Hey Emacs, this is -*- outline -*- mode!
 
 * Build suite
 ** Make sure everything is cleaned correctly (esp. test area).
+** Enable AC_CONFIG_MACRO_DIR and bump up autoconf version requirement.
+   (To fix "./autogen.sh; ./configure --enable-maintainer-mode; touch
+   configure.ac; make").  Currently worked around with ACLOCAL_AMFLAGS???
+
+* Error checking 
+** engine-gpgsm, with-validation
+   Add error checking some time after releasing a new gpgsm.
+
 
-Bugs reported by Stephane Corthesy:
-> BTW, here's another bug: it it not possible to retrieve fingerprints  
-> for subkeys
+Copyright 2004, 2005 g10 Code GmbH
 
-> In GpgmeRecipients, would it be possible to provide a function which  
-> would return the validity assigned to a name contained in the  
-> GpgmeRecipients instance?
+This file is free software; as a special exception the author gives
+unlimited permission to copy and/or distribute it, with or without
+modifications, as long as this notice is preserved.
 
-> 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.
+This file is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
+implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
+PURPOSE.