On Friday, 19 May 2006 01:43, Matt Rogers wrote: > On Thursday 18 May 2006 13:09, Olivier Goffart wrote: > > Usually, when there is a new contributor, or when we want to review a > > patch, we send the pactch dirrectly to the list. (the result of svn > > diff) and we don't create branch. > > > > Once the patch has been approved, it may be commited into the main > > branch.
Thanks, I'll remember that in the future. > > But never mind, i know how to make a diff between branches :-) > > > > I haven't tested your patch, but it looks good. > > > > few notes: > > > > - NULL is C , in kopete we use 0L for null pointers > > - Having a null pointer for KopeteMessage::from is dangerous, even for > > internal messages. i would use myself() Agreed. > > - The options to change the color should be disabled if the "append > > notice" is not checked Why? It still changes the color of the message. That way you could have the crypted messages shown in other colors without the notice. Granted, the sender could forge the colors and entice you into believing that unencrypted message is in fact encrypted. But then again, one can forge the notice, too. > > - I fear that if you crypt your message, and not your contact (or the > > opposite) the "entering encrypted mode" way will not work fine That's true, but more often than not both directions are encrypted. The notice approach also has the added benefit of being impossible to forge. All in all, such OOB information should be presented in OOB way, otherwise forging is always a possibility (and that's especially important when privacy is of concern). > > I don't know if new string still can be included in the 0.12 branch. > > (mattr?) > > > > Related link: http://bugs.kde.org/show_bug.cgi?id=77486 Thanks! Frankly, I haven't searched the bugzilla (my bad), just went ahead and fixed this annoying problem of hardcoded messages staying in the history. I can see that approach proposed in that bug could be better, but it needs more work and probably modifying styles and/or style engine. > > I hope you can fix theses issues, your changes looks good. > > 0.12 is essentially frozen except for bugfixes. this should go into kde4 I think that in KDE4 there should be a significant change in handling encryption notification, possibly along the lines of the patch in the bug (so that the styles can present the fact that the message is encrypted in their own way), so that info about the message being encrypted or not is correctly shown in clearly out-of-band way, so that forging becomes impossible. In the meantime, I'd try and argue that removing these hardcoded messages (which have the awful problem of staying in the history and deterring many people from using encryption or even kopete altogether, just see the votes; and also there is a possible privacy problem with the sender forging encryption notice inside the message itself) should be considered bugfix. The question remains whether the changes I've proposed aren't too extensive to be considered just bugfix. I maintain that they are pretty minimal; but then, there remains the question of user strings. I take it that they are frozen now? My changes introduce 6 new strings IIRC. (I've reused 3 further strings.) -- Rafał Rzepecki
pgp7cxs0ug32J.pgp
Description: PGP signature
_______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
