-----BEGIN PGP SIGNED MESSAGE----- Jim McCoy responds:

In addition to this, the code really sucks as far as modularity goes. The next big version of PGP, which is supposed to include library hooks, etc., will probably not be out for five or six months. I do know of some people who are interested in working on a PGP compatible library of crypto code, but I am not quite sure what the status of that project is at this time...

This is really a shame, because at the current time one of the most lacking aspects of most crypto software is the key management interface. Encrypting and decrypting pgp format messages is easily accomplished in an acceptable manner using the actual pgp binary. However, writing a decent key-management interface is practically impossible when your only interaction with the PGP key-management code is via the system() function call. Of course, shelling out to the PGP binary isn't the only solution. It's not impossible to create a simple library for encrypting and decrypting pgp format messages (there's PGPTools, and you can roll your own). But you are doubly screwed because the PGP development team has made it clear that the keyring file format will change in 3.0. Who wants to spend time writing a key management API (which, I admit, is NOT trivial...) which is guaranteed not to work in the next version of PGP? Why spend the effort to write a decent PGP front-end, which would necessarily include a key-management interface, when 1) Any effort expended in writing your own library or sprucing up PGPTools is supposedly being duplicated by the PGP team as we speak, and 2) your code is going to break anyway... ? PGP front-ends aren't the only application type whose progress is being slowed by this situation. IMHO, any app that uses PK-crypto should support PGPformat keys, even if it's output isn't designed to be fed into PGP. Don't get me wrong. I understand how difficult it is to do this and I am not ragging on the PGP developers for being slow or lazy or anything like that (I know they are underpaid). BUT, somebody must write a PGP library if we are to see major advancement in the penetration of crypto software into the mainstream. The question is, who is writing it? It almost seems as if PGP development is now happening in secret, and nobody really knows what the statusis on pgp 3.0 and the rumored library. There are people on this list who know, but nobody is telling. If the PGP people really are making progress on a PGP library, we need to know. We can probably help. If not, we also need to know so we can write one. Phase (yes you too can have a pseudonym) -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLu9kW5Ot8/1bCL+9AQGHaQP/dEaZ+3h/o8AB/gu0VLOjs14F8cgUwkm2 zpqgqFmh6Bna3GzANxSqf7R6Idmwp+y6hzk9YbDiItCE+r0inv9tp0pAE7JlPLg1 bWxM2Nd8r+ZpKhLExepNftJ9iiBewCtWNg9ylxs78VR3QjeKLBWlpcPODeIa2C0S kZlqVBwUBKY= =s1Nh -----END PGP SIGNATURE----- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAy7vWyUAAAEEALwtONPeyYZ6jAYbFWgq8zTqttIclI/1wTjuFC3EkDzsjJM2 kkojkebMTwcJwLUgAL2+2EouAuM+MpyqAs+8/uMW42eP8kCS5XbLzSk5pisZpH/B kflaSeQ6lS6fr66nDHpR33wxQ+0lJWf94rJbaSWZGP2iN1W1jJOt8/1bCL+9AAUR tDlQaGFzZSBKaXR0ZXIgPGFsdC5zZWN1cml0eS5wZ3A+IG9yIDxjeXBoZXJwdW5r c0B0b2FkLmNvbT6JAJUDBRAu71tLk63z/VsIv70BAQkbA/9UUtJpfeTzi+OcNxQn QQEsP+xeusQWaJnS91sEYmjtzDJTqHOZ02Lh2tya0YZVl7ra8WJ6fbTzLR96s+vQ q+qYOwUUq+1OB6L4gdssK5ofRD/4M4dkWJlilY3eHI7Kch8KL/b2L1RG+r0rnEnG 6mH5XaHu7Lebf8wjtexJmKoWXQ== =mpBD -----END PGP PUBLIC KEY BLOCK-----