shit.  the attachment was dropped.  shit.  trying again.  sorry about
the clutter.

On 10/10/05, Ken Manheimer <ken.manheimer@gmail.com> wrote:
> for those of you following the developments at home (:-), here's an
> incremental patch on top of what i sent out a few days ago.  i fixed a
> small stack of bugs in pgg-gpg.el that settles my complaint about
> prompting with the secret key identity, and also filled in a small
> oversight in the changes i sent out a few days ago.
>
> while this could be the last pgg patch, i'm still developing, hence
> the incremental.  i plan to send out a full patch when i've finished
> transitioning allout to pgg, at which point i expect my mucking with
> pgg to be settled.  so, repository maintainers may want to wait for
> that, while i'm hoping those actively involved (eg, sascha) will
> scrutinize and, ideally, exercise these patches.
>
> we'll see if the attached patch makes it through this time.  (i
> haven't re-attached it, which i think was the problem last time.)  if
> not, look forward to a followup...
>
> thanks.
> ken
> ken.manheimer@gmail.com
>
> On 10/8/05, Ken Manheimer <ken.manheimer@gmail.com> wrote:
> > On 10/8/05, Sascha Wilde <wilde@sha-bang.de> wrote:
> > > On Sat, Oct 08, 2005 at 10:48:27AM +0200, Simon Josefsson wrote:
> > > > It seems you are making some progress here.  For simplicity, could you
> > > > post the complete patch (preferably in unified diff format) against
> > > > Emacs CVS you want to have installed?  Unless somebody else has
> > > > already taken care of this...
> > >
> > > I attached the complete patch against the latest cvs checkout.
> >
> > i've got another take on the cumulative patch, with the addition of
> > some refinements i would like to add.
> >
> > the patch is against the gnu.org repository, and incorporates recent
> > checkins there as of a few minutes ago.
> >
> > here are the details of my further refinements, which are included in
> > this patch.   their purpose is to enable external management of the
> > passphrases, including prompting and caching, while still using the
> > pgg encryption and cache mechanisms.  the changes have two thrusts:
> >
> >   - extend the (generic pgg and gpg scheme) encryption and decryption
> >     routines to take an optional passphrase argument, and when provided,
> >     use its value instead of prompting for the passphrase
> >
> >   - extend the passphrase caching and prompting routines to take an optional
> >     'notruncate' argument, to enable caching of passphrases for keys besides
> >     those that have the format of the short pgp packet key id.
> >
> > i think that these, together, will enable me to do the passphrase
> > handling and extend it to symmetric keys, while still leveraging the
> > features of the pgg mechanism (in particular, passphrase expiration).
> > i am pretty sure it's all backwards compatible - all the additional
> > functionality hinges on using the new optional arguments, there should
> > be no operational changes if you don't use them.
> >
> > (i am very puzzled about why the passphrase cache was restricted to
> > the length of the short pgp packet key ids.  seems like you want to
> > couple the passphrases with the user identity for which the message is
> > being encoded, in the case of key-pair ciphers, or some arbitrary
> > string for symmetric ciphers - eg, file name is what i want to use for
> > symmetric keys in allout, since the symmetric keys are associated with
> > the files.  but once again i don't know the pgp territory well enough
> > to wade in, and want to minimize the chance of inadvertantly breaking
> > anything.
> >
> > if this approach is deemed to be fine, i can easily provide an
> > additional patch to adjust the pgg-pgp and pgg-pgp5 modules similarly.
>