1
0
mirror of git://git.gnupg.org/gnupg.git synced 2024-11-04 20:38:50 +01:00
gnupg/TODO

117 lines
4.2 KiB
Plaintext
Raw Normal View History

1998-10-18 17:21:22 +02:00
2000-12-19 13:38:53 +01:00
* Can we output things like the preferences?
* Add Dave's UTS patches
2000-11-24 14:44:56 +01:00
* Fix revoked subkey problem - see key 621cc013
** Check whether the use of -u and --clearsign created 2 signatures.
removed dups from the skclist.
* Replace mkinstalldir etc. with nnewer copies.
* We need another special packet at the end of a clearsign message to mark
it's end and allow for multiple signature for one message.
* option to set the signature expiration time for key sigs.
* Option to warn when a non MDC message is decrypted?
* If there is no secure memory, allocate more memory for the secure
2000-10-17 15:30:26 +02:00
memory block or do it in all cases.
* List all UserID with GOODSIG?
* add a way to set expiration time for key signatures.
* add some minor things vor VMS.
* Don't get the ultimately trusted keys from the secring but store
it permanently in the trustdb. This way we don't need a secring at all.
[ Solved by re-introducing --trusted-key ]
* Use DSA keys with the test suite.
* g10/trustdb.c (make_sig_records): fix the fixme.
* at least an option to prefer DSA keys over RSA when selecting the key to
use. Depending on creation time would be nice too. I think this is
already done for the subkeys - check it.
* No TCP support yet for W32? arggg - should go into a separate program
anyway.
* Replace Valid/Invalid by Known/Unknown?
* Fix the bug in the mips assembler code
Scheduled for 1.1
-----------------
* David C Niemi pointed out that the code for --no-default-keyring does not
work as expected, because in g10/g10.c sec_nring will be set in the option
switch but later checked to see whether there are any keyrings.
* export by user-IDs does only export the first matching name which leads
to a problem in cases where there are 2 keys with identically user-IDs.
* Rework the whole key selection stuff: Compile a list of valid
candidates for a keyblock first and the select one from it.
The current code is too ugly (getkey.c).
* With option -i prompt before adding a key to the keyring and show some
info what we are about to add.
* Speed up calculation of key validation.
* print a warning when a revoked/expired _secret_ key is used.
* --disable-asm should still assemble _udiv_qrnnd when needed
* Skip RO keyrings when importing a key.
* Use the newest encryption key if only the main key has been given.
[already in the gpg 1.1 codebase]
* replace the keyserver stuff either by a call to a specialized
utility and SOCKSify this utility.
* Check the beginning of file to detect already compressed files (gzip,
bzip2, xdelta and some picture formats)
* Delay the read of the passphrase-fd after a NEED_PASSPHRASE. But this
may break some scripts.
2000-12-19 13:38:53 +01:00
* Get new assembler stuff from gmp 3.1
Nice to have
------------
* use DEL and ^H for erasing the previous character (util/ttyio.c).
or better readline.
* Print a warning if the directory mode is wrong.
* Do a real fix for bug #7 or document that it is a PGP 5 error.
* preferences of hash algorithms are not yet used.
* Replace the SIGUSR1 stuff by semaphores to avoid loss of a signal.
or use POSIX.4 realtime signals. Overhaul the interface and the
test program. Use it with the test suite?
* add test cases for invalid data (scrambled armor or other random data)
* add checking of armor trailers
* Burn the buffers used by fopen(), or use read(2). Does this
really make sense? And while we are at it: implement a secure deletion
stuff?
* the pubkey encrypt functions should do some sanity checks.
* dynload: implement the hint stuff.
* "gpg filename.tar.gz.asc" should work like --verify (-sab).
* for messages created with "-t", it might make sense to append the
verification status of the message to the output (i.e. write something to
the --output file and not only to stderr.
* configure option where to find zlib
* Display more validity information about the user IDs at certain places.
We need a more general function to extract such kind of info from the
trustdb.
* Evaluate whether it make sense to replace the namehashs either by
using the user ID directly or by using pointers into the trustdb.