[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: new "kmail with PGP" error
From:       Don Sanders <dsanders () cch ! com ! au>
Date:       2000-03-06 9:18:45
[Download RAW message or body]

On Fri, 03 Mar 2000, Andreas Gungl wrote:
> Hi,
>
> after a longer period of time I had a look at the current kmail
> sources, especially pgp support. Just for remindness I want to bring
> up three problems again.
> I would consider the second one as solved - is somebody able to
> commit the patch? The first and third problem have not much to do
> with kpgp code, I think they are problems of the mail parsing /
> displaying algorithm.
>
> Would be nice, if somebody else could have a look at it. Iīll also
> try to find the reasons for this problems, but I canīt spend much time
> on it and Iīll have to read a lot of code first (I think).
> Unfortunatly Iīm not familiar with the kmail files except the kpgp*
> files.

I'm quite familiar with most of the code, (the PGP stuff and stuff closely 
related to MIMELIB I'm not so familiar with). I might start to write some 
high level documentation I think the code base is becoming quite stable now.

> BTW, the extended settings and the experimental pop account are
> great.

I'm glad experimental pop worked for a couple of people. It's really good to 
have that confirmed.

> It seems as if kmail is currently one of the best KDE2 programs
> (most of them are pretty unstable at the moment, when I look at the
> latest snapshots).

It is actually getting more difficult to think of new features to add that 
will be useful to the majority of KMail users. After the addressbook, search 
dialog, IMAP and threading of messages I'm going to be feeling pretty 
satisfied.

I guess after that we might start trying to break some new ground. Actually 
I'm very impressed with the smart quoting Waldo implemented, I wonder what 
other email clients support that?

> Itīs a pity that the improvements cannot simply get
> included in an improved version for KDE1. I know a lot of people who
> are waiting for the new features.

If someone really wants to update KMail 1.0.28 they can probably get a CVS 
account and do it.

> Andreas
>
> Am Mit, 09 Feb 2000 schrieb Andreas Gungl:
> >Hi,
> >
> >testing PGP support in kmail 1.1.33 (cvs 08.02.2000) I found the
> >following problem:
> >
> >You write a message and you choose to sign or encrypt it. When the
> >last line in the message is containing text (i.e. you donīt press
> >ENTER at the end of the last line with some text in it) this line
> >seems to be getting lost in the signing / encryption process.

Do you think we should just terminate all mail with a carriage return then? 
Actually I thought this had already been done?

> >Really the following is happening:
> >The message becomes signed / encrypted, and it is still
> >containing the whole message. Decryption is also working correctly.
> >But the ouput has no trailing newline character. This seems to lead to
> >problems when the output is displayed in kmail (enveloped by the
> >texts for "message is signed by..." and so on).
> >
> >If somebody (who knows the display process better than me) could
> >have a look on it - it would be nice.
> >(BTW, the problem doesnīt exist in kmail 1.0.28.)

Right, I must have not ported forwarded a fix. I remember Sven making one 
related to this.

> >         Another topic:
> >
> >Some time ago George has reported about a problem, when he had typed
> >in his passphrase to sign a message and pressed ESC to abort. Since
> >the passphrase was correct, kmail signed his message and sent it.
> >
> >I'ld suggest the following correction in kpgp.cpp:
> >
> >QString
> >KpgpPass::getPassphrase(QWidget *parent)
> >{
> >  KpgpPass kpgppass(parent, i18n("OpenPGP Security Check"));
> >  if (kpgppass.exec())
> >    return kpgppass.getPhrase().copy();
> >  else
> >    return QString::null;
> >}
> >
> >OLD:
> >  kpgppass.exec();
> >  return kpgppass.getPhrase().copy();
> >
> >NEW:
> >  if (kpgppass.exec())
> >    return kpgppass.getPhrase().copy();
> >  else
> >    return QString::null;

Ok, I'm offline right now but I should commit that fairly shortly.

> >So the phrase wonīt become returned, when a user hits ESC in the
> >dialog. The result should be a "wrong" (invalid) phrase and kmail
> >will wait for a new user action - without processing of the message,
> >which will remain in the composer window.
> >
> >Although Iīve tested this code, it would be nice if somebody else
> >could do so. And since I didnīt prepare cvs acces, could someboy
> >apply this patch, after it is verified?
> >
> >Thank you.
> >
> >Andreas
> >--
> >    ~
> >  ' v '
> > //   \\
> >/(     )\  Powered by Penguin.
> >  ^ ' ^
> >
> >
> >Hi,
> >
> >just I got a message, which was encrypted by pgp. It was a multipart
> >message, containing the info as plain text and html formatted.
> >
> >I guess, the default to display the message in kmail is to use the
> >html formatted part. So kmail doesnīt realize, that the message is
> >encrypted, since the "--- BEGIN PGP MESSAGE ---" is between html
> >tags.
> >
> >I donīt know, at the moment, if pgp would handle the decryption of
> >the html formatted message. And I donīt want to discuss about the
> >sence of encrypted mails in multipart format.
> >
> >But I think, the parsing should become improved in kmail, so that the
> >plain text part is determined as an encrypted messsage and is passed
> >to kmail (and its result displayed in kmail).
> >
> >Any comments to this?

kmreaderwin.cpp ...
void KMReaderWin::parseMsg(KMMessage* aMsg) ...
    for (i=0; i<numParts; i++) ...
          if (stricmp(subtype, "html")==0)
          { 
            //DECODING NEEDED HERE
	...
            mViewer->write(str); //writes raw html
          }
          else writeBodyStr(str); 

void KMReaderWin::writeBodyStr(const QString aStr)
{
  QString line, sig, htmlStr = "";
  Kpgp* pgp = Kpgp::getKpgp();
  assert(pgp != NULL);
  //  assert(!aStr.isNull());
  bool pgpMessage = false;

  if (pgp->setMessage(aStr)) // message is pgp encrypted of signed
  {
   ...

To fix this it would be necessary to handling decoding (like it is done in 
writeBodyStr) at the place marked //DECODING NEEDED HERE. Or at least I think 
that's the case.

BFN,
Don.

[prev in list] [next in list] [prev in thread] [next in thread]