[trojita] Some weird Qt5 crashes
Hi,
Trying to build pure Qt5 version of trojita led me to some very weird
crashes from within libQtCore.so.4. (maybe Qt4 and Qt5 cannot coexist
within one elf?)
Here's a patch for CMake that remove any linking to Qt4 libraries when
WITH_QT5 option is passed to CMake.
BR,
Bartekcommit cda12524621595d4c2a958471505c6f2166547d1
Author: Bartosz Taczala
Date: Thu Oct 17 12:19:54 2013 +0200
Fixing build for Qt5
When building with WITH_QT5=On, some Qt4 libraries also were linked,
this caused runtime errors (libc)
So don't link agaist Qt4 when Qt5 build is set up.
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 33bb61f..c9b4e89 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -515,11 +515,19 @@ set_source_files_properties(${version_files}
add_library(Common ${libCommon_SOURCES})
add_dependencies(Common version)
-target_link_libraries(Common ${QT_QTGUI_LIBRARY} ${QT_QTCORE_LIBRARY})
+if(WITH_QT5)
+qt5_use_modules(Common Core Gui)
+else()
+target_link_libraries(Common ${QT_QTGUI_LIBRARY} ${QT_QTCORE_LIBRARY})
+endif()
add_library(AppVersion ${libAppVersion_SOURCES})
add_dependencies(AppVersion version)
-target_link_libraries(AppVersion Common ${QT_QTCORE_LIBRARY})
+if(WITH_QT5)
+qt5_use_modules(AppVersion Core)
+else()
+target_link_libraries(AppVersion Common ${QT_QTCORE_LIBRARY})
+endif()
if(WITH_SHARED_PLUGINS)
add_library(Plugins SHARED ${libPlugins_SOURCES})
@@ -535,25 +543,51 @@ else()
endif()
add_library(Streams ${libStreams_SOURCES})
-target_link_libraries(Streams ${QT_QTNETWORK_LIBRARY} ${QT_QTCORE_LIBRARY})
+if(WITH_QT5)
+qt5_use_modules(Streams Core Network)
+else()
+target_link_libraries(Streams ${QT_QTNETWORK_LIBRARY} ${QT_QTCORE_LIBRARY})
+endif()
+
if(WITH_ZLIB)
target_link_libraries(Streams ${ZLIB_LIBRARIES})
endif()
add_library(qwwsmtpclient ${libqwwsmtpclient_SOURCES})
-target_link_libraries(qwwsmtpclient ${QT_QTNETWORK_LIBRARY}
${QT_QTCORE_LIBRARY})
+if(WITH_QT5)
+qt5_use_modules(qwwsmtpclient Network Core)
+else()
+target_link_libraries(qwwsmtpclient ${QT_QTNETWORK_LIBRARY}
${QT_QTCORE_LIBRARY})
+endif()
add_library(MSA ${libMSA_SOURCES})
-target_link_libraries(MSA Imap Streams qwwsmtpclient ${QT_QTCORE_LIBRARY})
+if(WITH_QT5)
+qt5_use_modules(MSA Core)
+else()
+target_link_libraries(MSA ${QT_QTCORE_LIBRARY})
+endif()
+target_link_libraries(MSA Imap Streams qwwsmtpclient)
add_library(Composer ${libComposer_SOURCES})
-target_link_libraries(Composer Common MSA Streams qwwsmtpclient
${QT_QTGUI_LIBRARY} ${QT_QTCORE_LIBRARY})
+if(WITH_QT5)
+qt5_use_modules(Composer Core Gui)
+else()
+target_link_libraries(Composer ${QT_QTGUI_LIBRARY} ${QT_QTCORE_LIBRARY})
+endif()
+target_link_libraries(Composer Common MSA Streams qwwsmtpclient)
+
if(NOT WITH_QT5)
target_link_libraries(Composer MimetypesQt4)
endif()
add_library(Imap ${libImap_SOURCES})
-target_link_libraries(Imap Common Streams ${QT_QTNETWORK_LIBRARY}
${QT_QTSQL_LIBRARY} ${QT_QTGUI_LIBRARY} ${QT_QTCORE_LIBRARY})
+if(WITH_QT5)
+qt5_use_modules(MSA Core Network Sql Gui)
+else()
+target_link_libraries(Imap Common Streams ${QT_QTNETWORK_LIBRARY}
${QT_QTSQL_LIBRARY} ${QT_QTGUI_LIBRARY} ${QT_QTCORE_LIBRARY})
+endif()
+target_link_libraries(Imap Common Streams)
+
if(WITH_ZLIB)
target_link_libraries(Imap ${ZLIB_LIBRARIES})
endif()
@@ -587,7 +621,11 @@ if(WITH_DESKTOP)
endif()
add_library(AbookAddressbook ${libAbookAddressbook_SOURCES}
${libAbookAddressbook_UI_OUT})
-target_link_libraries(AbookAddressbook ${QT_QTGUI_LIBRARY}
${QT_QTCORE_LIBRARY})
+if(WITH_QT5)
+qt5_use_modules(AbookAddressbook Core Gui)
+else()
+target_link_libraries(AbookAddressbook ${QT_QTGUI_LIBRARY}
${QT_QTCORE_LIBRARY})
+endif()
add_library(DesktopGui ${libDesktopGui_SOURCES} ${libDesktopGui_UI_OUT}
${libDesktopGui_RESOURCES_OUT})
# The following is needed for the LineEdit widget within the .ui files.
@@ -595,12 +633,22 @@ if(WITH_DESKTOP)
if(SUPPORTS_TARGET_INCLUDES)
set_property(TARGET DesktopGui APPEND PROPERTY INCLUDE_DIRECTORIES
${path_DesktopGui})
endif()
-target_link_libraries(DesktopGui Common Composer Imap MSA Plugins Streams
qwwsmtpclient AbookAddressbook ${QT_QTWEBKIT_LIBRARY} ${QT_QTGUI_LIBRARY}
${QT_QTCORE_LIBRARY})
+if(WITH_QT5)
+qt5_use_modules(DesktopGui WebKit Core Gui)
+else()
+target_link_libraries(DesktopGui ${QT_QTWEBKIT_LIBRARY}
${QT_QTGUI_LIBRARY} ${QT_QTCORE_LIBRARY})
+endif()
+target_link_libraries(DesktopGui Common Composer Imap MSA Plugins Streams
qwwsmtpclient AbookAddressbook)
# On Windows build a real Win32 GUI application without console window
# On other platforms WIN32 flag is ignored
add_executable(trojita WIN32 ${trojita_desktop_SOURCES} ${trojita_QM})
-target_link_libraries(trojita AppVersion Common DesktopGui
${STATIC_PLUGINS} ${QT_QTMAIN_LIBRARY} ${QT_QTGU
[trojita] GnuPG-Support
Hi folks, for those interested, I started working on GnuPG-Support for trojitá a few days ago. The current development can be found on gitorious (http://gitorious.org/trojita/paalsteeks-trojita/source/gpg). Currently I have implemented rudimentary signature verification and it's far from stable. Please note that caching breaks the verifiaction. At this point I want to thank Jan Kundrát for helping me out a few times when I was stuck. I appreciate the constructive comments. Greetings, paalsteek
Re: [trojita] Some weird Qt5 crashes
On Thursday, 17 October 2013 12:29:48 CEST, Bartek Taczala wrote:
Hi, Trying to build pure Qt5 version of trojita led me to some
very weird crashes from within libQtCore.so.4. (maybe Qt4 and
Qt5 cannot coexist within one elf?)
Hi Bartek, that's correct; one indeed cannot link with both Qt4 and Qt5 at
the same time.
Here's a patch for CMake
that remove any linking to Qt4 libraries when WITH_QT5 option is
passed to CMake.
This is rather strange; I have been building the Qt5 version for ages and
have never seen a binary linked with both Qt4 and Qt5. What platform are
you on? What version of Qt5?
The patch appears to be doing other things as well, though. In particular,
the Qt5 version would no longer link the individual sub-libraries with
their dependencies -- e.g.:
-target_link_libraries(AppVersion Common ${QT_QTCORE_LIBRARY})
+if(WITH_QT5)
+qt5_use_modules(AppVersion Core)
+else()
+target_link_libraries(AppVersion Common ${QT_QTCORE_LIBRARY})
+endif()
This results in libAppVersion.a no longer linking with libCommon.a. That's
a problem for some of the platforms we support.
I do like the qt5_use_modules() approach; Trojita should switch to that.
Anyway, before I merge this, let's find out why is QT_QTCORE_LIBRARY
actually pointing to Qt4. The build system is supposed to *completely*
ignore Qt4 if configured to use Qt5. Have you tried to do something crazy
like switching the existing build tree from Qt4 to Qt5? I.e. have you ever
run `cmake` without the -DWITH_QT5=ON option? Could you please post your
CMakeCache.txt? Could you nuke your build dir and try to build from
scratch, this time making sure you use -DWITH_QT5 from the very beginning?
With kind regards,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: [trojita] GnuPG-Support
* on the Thu, Oct 17, 2013 at 01:37:36PM +0200, Stephan Platz wrote: > for those interested, I started working on GnuPG-Support for trojitá a few > days ago. The current development can be found on gitorious > (http://gitorious.org/trojita/paalsteeks-trojita/source/gpg). > > Currently I have implemented rudimentary signature verification and it's > far from stable. Please note that caching breaks the verifiaction. Awesome! This is what I've been waiting for. If you want to create the best PGP support in any existing email client, please consider the following: 1.) Support both PGP/MIME and also Inline PGP for both incoming and outgoing mail 2.) When composing a message, allow the user to toggle between using PGP/MIME or inline. Intelligently choose which to default to per message, by taking the following into consideration: a.) A user specified default from the preferences b.) What has been previously used when contacting that recipient c.) What the recipient previously used when contacting the user d.) A preference that was explicitly specified by the recipient using the signature/cert "preferred-email-encoding" notation. For example, my preference for receiving PGP/MIME encoded email over Inline, is encoded within the signature of this message. See GnuPG's "show-notations" argument to the --verify-options option. 3.) When composing a message, if a Draft is going to be saved in an IMAP folder. Allow the user to choose between several different options on how to deal with this situation: a.) Save to a local Drafts folder rather than to the IMAP server b.) Encrypt before saving to the Drafts folder c.) Don't save a Draft 4.) When sending an email to somebody who doesn't have a PGP key, we can't encrypt. This is less than ideal, from a privacy perspective. However, that doesn't mean we also have to save the "Sent Items" version unencrypted. An option to encrypt anything that gets added to the "Sent Items" folder with the users own public key, would be great. 5.) An option for making Trojita automatically and transparently replace any unencrypted email on the server with an encrypted version. If you don't understand why I want number 4 or number 5, please read the following blog post I wrote a couple of years ago, and its follow up: https://grepular.com/Automatically_Encrypting_all_Incoming_Email https://grepular.com/Automatically_Encrypting_all_Incoming_Email_Part_2 6.) When encrypting an outgoing mail, automatically encrypt with the users own public key as well. 7.) A setting which can be toggled to automatically sign all outgoing mail 8.) A setting which can be toggled to automatically encrypt all outgoing mail for which we have the public key. 9.) A warning if we try to send an unencrypted email in response to an encrypted email. And *also* a warning if we receive an unencrypted email that was in reply to an encrypted email, so we notice if some information we didn't expect to be leaked was leaked. 10.) Don't restrict encrypting ability to the UIDs in the key. For example this email will be sent from troj...@lists.grepular.com, but will be signed using a key which doesn't have a troj...@lists.grepular.com UID 11.) Expect to see keys with multiple signing subkeys and multiple encrypting subkeys. Some of which may have been revoked or expired. Expect to see keys with UIDs that have been revoked. 12.) If there is a photo attached to a public key, display it within the trojita GUI, along with the message. 13.) Take advantage of PKA records. For example, you can automatically look up what the corresponding PGP key for my personal email address is without talking to any key servers: mike@glue:~$ dig +short txt mike.cardwell._pka.grepular.com "v=pka1\;fpr=35BCAF1D3AA21F843DC3B0CF70A5F5120018461F\;uri=http://grepular.com/0018461F.pub.asc"; mike@glue:~$ 14.) Support PGP at any layer of MIME depth. For example, you might have an ascii armored inline pgp signed message that is an attachment within a PGP/MIME encrypted email. You might also have a single part email which contains some unencrypted and unsigned text, followed by some ascii armored signed or encrypted text, followed by some other non encrypted/signed text. I can probably think of a tonne of other features. But at least these should give you some ideas and things to think about. I'm looking forward to testing and breaking your implementation ;) Regards, Mike -- Mike Cardwell https://grepular.com/ http://cardwellit.com/ OpenPGP Key35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 signature.asc Description: Digital signature
[trojita] (fwd) Re: Windows XP SSL
- Forwarded message from Christian Degenkolb - From: Christian Degenkolb Subject: Re: Windows XP SSL To: david.scott@gmail.com Date: Thu, 17 Oct 2013 14:35:04 +0200 Hi David Am 17.10.2013 00:19, schrieb david.scott@gmail.com: > Thanks for your help. > > I did not see your request to be CC'd until after I replied to your > response. > > In short, the SSL libraries in the Trojita directory worked. No problem. Jan also forwarded your mail from the list. Good to hear the problem was solved. I will add the DLLs to the installer today. So starting tonight the nightly build installer should run also on XP without this problem. > Now my next obstacle is that the external graphics are not loading when > requested. The "wait" circle shows up, but no graphics every show. I just tested this problem and I see the same result. Unfortunately I can't help you there since I'm not that familiar with the code. Maybe Jan has a solution. with regards Christian - End forwarded message -
[trojita] view-source bug
I tried sending myself an email using https://emailprivacytester.com/ and viewing it in Trojita. When I viewed it, an animated "Fetching Message" icon appeared over the top of the email content and it stayed there, with seemingly no way of getting rid of it. I ran Trojita from the command line with the hope that it would display some useful debug information. Here is what it displayed: mike@Mike-PC:~$ trojita Forbidden per policy: QUrl( "view-source:https://emailprivacytester.com/cb/21cc0ee267da08ef/view_source"; ) QWidget::setMinimumSize: (/Gui::SimplePartWidget) The largest allowed size is (16777215,16777215) QWidget::setMinimumSize: (/Gui::SimplePartWidget) The largest allowed size is (16777215,16777215) QWidget::setMinimumSize: (/Gui::SimplePartWidget) The largest allowed size is (16777215,16777215) QWidget::setMinimumSize: (/Gui::SimplePartWidget) The largest allowed size is (16777215,16777215) The system this is running on: Debian Jessie paalsteeks-trojita repo, commit id: 41e25fc28527aa528336039fa27fa89ef3d7e32c You should be able to replicate this yourselves using https://emailprivacytester.com/ -- Mike Cardwell https://grepular.com/ http://cardwellit.com/ OpenPGP Key35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 signature.asc Description: Digital signature
Re: [trojita] GnuPG-Support
Hi Mike, thanks for a long and detailed mail with plenty of valuable suggestions. I have a couple of comments and questions to some of them. 1.) Support both PGP/MIME and also Inline PGP for both incoming and outgoing mail It's 2013 already. The specification for PGP/MIME has been around since 1996 (RFC 2015, since updated by 3156). What is the reason on why would anyone bother with inline signatures today? I've read some random blog posts about Outlook Express not displaying these messages at all. Frankly, the same happens when one sends a mail with an unrecognized X.509 certificate. Users normally work around this brokeness by not encrypting messages going to such recipients at all. I'm not convinced that supporting the inline hack is worth any effort. It might be interesting to produce the messages like this, however: 1 multipart/alternative 1.1 text/plain for outlook 1.2 multipart/signed 1.2.1 text/plain 1.2.2 the signature Do you happen to know whether this works? Is the state of "work/doesn't work in OE" depending on the order of 1.1 and 1.2? What's the OE's market share today, i.e. do we have to cater for it at all? 3.) When composing a message, if a Draft is going to be saved in an IMAP folder. Note that Trojita does not support drafts stored in an IMAP folder yet :). 4.) When sending an email to somebody who doesn't have a PGP key, we can't encrypt. This is less than ideal, from a privacy perspective. However, that doesn't mean we also have to save the "Sent Items" version unencrypted. An option to encrypt anything that gets added to the "Sent Items" folder with the users own public key, would be great. This unfortunately completely breaks any efficient sending method like BURL. 5.) An option for making Trojita automatically and transparently replace any unencrypted email on the server with an encrypted version. I don't think this is a job for a MUA. If you do not trust your IMAP server, an after-fact opportunistic encryption wouldn't help you anyway. Even if you are willing to accept that risk, I would suggest simply running a separate agent responsible for this transformation. You might want to write one based on Trojita, sure. Also keep in mind that this approach has rather wide ranging implications on efficiency, in particular on any server-side operation. Trojita relies on these a lot, and will happily use them more in future. You might or might not get some increased level of security, but you'll definitely get a slowdown in the speed of operation, pay the price of higher latency and consumer more bandwidth. I'm sure you know this, but it's good to make sure people are aware of the drawbacks before they jump into the "let's encrypt everything" stage. 9.) A warning if we try to send an unencrypted email in response to an encrypted email. And *also* a warning if we receive an unencrypted email that was in reply to an encrypted email, so we notice if some information we didn't expect to be leaked was leaked. Now this is clearly interesting from the user's point of view. However, how do you propose to track this relation, technically? Where shall Trojita keep the mapping about mails and responses to them? I'm of course aware of Message-Id/In-Reply-To/References, but this index maintenance cannot be offloaded to the server anymore (you don't trust it after all), which means a TON of transferred data. 10.) Don't restrict encrypting ability to the UIDs in the key. For example this email will be sent from troj...@lists.grepular.com, but will be signed using a key which doesn't have a troj...@lists.grepular.com UID I was under impression that the signer identity is checked against the From header, not against the actual sender. Note that the ML messages are From: you, not From: trojita-ml, so there is no issue here AFAIK. 12.) If there is a photo attached to a public key, display it within the trojita GUI, along with the message. Plenty of arguments against this on the net center around an argument that this feature provides a false sense of security. I don't have much of an opinion here. 13.) Take advantage of PKA records. For example, you can automatically look up what the corresponding PGP key for my personal email address is without talking to any key servers: How is this supposed to be integrated with DNSSEC? How do I validate the DNSSEC responses from a Qt application? 14.) Support PGP at any layer of MIME depth. For example, you might have an ascii armored inline pgp signed message that is an attachment within a PGP/MIME encrypted email. You might also have a single part email which contains some unencrypted and unsigned text, followed by some ascii armored signed or encrypted text, followed by some other non encrypted/signed text. You will actually get this one for free due to the way how Trojita's MIME rendering wo
Re: [trojita] GnuPG-Support
* on the Thu, Oct 17, 2013 at 05:15:47PM +0200, Jan Kundr?t wrote: > Hi Mike, thanks for a long and detailed mail with plenty of valuable > suggestions. I have a couple of comments and questions to some of them. > >> 1.) Support both PGP/MIME and also Inline PGP for both incoming >> and outgoing mail > > It's 2013 already. The specification for PGP/MIME has been around since > 1996 (RFC 2015, since updated by 3156). What is the reason on why would > anyone bother with inline signatures today? I also wish Inline PGP would die. The trouble is, other people still use it and I want to be able to decrypt and verify their emails. A feature to compose using Inline PGP is less important than one to read it though yes. > It might be interesting to produce the messages like this, however: > > 1 multipart/alternative > 1.1 text/plain for outlook > 1.2 multipart/signed > 1.2.1 text/plain > 1.2.2 the signature > > Do you happen to know whether this works? Is the state of "work/doesn't > work in OE" depending on the order of 1.1 and 1.2? What's the OE's market > share today, i.e. do we have to cater for it at all? God only knows. I've never used Outlook Express and I don't think it's worth catering for any more. I'm a web developer and I certainly don't cater for IE6 anymore. I imagine having a multipart/alternative at the root rather than a multipart/signed or multipart/encrypted will stop PGP working with proper email clients though. >> 3.) When composing a message, if a Draft is going to be saved >> in an IMAP folder. > > Note that Trojita does not support drafts stored in an IMAP folder yet :). Ah, I didn't know this; It's been a while since I played with Trojita. I've been waiting for somebody to announce develpment of PGP support first ;) >> 4.) When sending an email to somebody who doesn't have a PGP key, we >> can't encrypt. This is less than ideal, from a privacy perspective. >> However, that doesn't mean we also have to save the "Sent Items" >> version unencrypted. An option to encrypt anything that gets added to >> the "Sent Items" folder with the users own public key, would be great. > > This unfortunately completely breaks any efficient sending method like > BURL. I'm not familiar with BURL. I was suggesting the encrypted Sent Items as an optional feature, so they could still both operate along side each other couldn't they? If the user wants encrypted Sent Items, and they've sent an unencrypted mail, then use IMAP APPEND, otherwise fall back to using BURL. >> 5.) An option for making Trojita automatically and transparently replace >> any unencrypted email on the server with an encrypted version. > > I don't think this is a job for a MUA. If you do not trust your IMAP > server, an after-fact opportunistic encryption wouldn't help you anyway. > Even if you are willing to accept that risk, I would suggest simply running > a separate agent responsible for this transformation. You might want to > write one based on Trojita, sure. > > Also keep in mind that this approach has rather wide ranging implications > on efficiency, in particular on any server-side operation. Trojita relies > on these a lot, and will happily use them more in future. You might or > might not get some increased level of security, but you'll definitely get a > slowdown in the speed of operation, pay the price of higher latency and > consumer more bandwidth. I'm sure you know this, but it's good to make sure > people are aware of the drawbacks before they jump into the "let's encrypt > everything" stage. I'll agree that it *should* be done server side if anywhere. Client side is the second best option. However, I'll admit that I never expected you to agree to this one. I thought I'd throw it in there just in case. >> 9.) A warning if we try to send an unencrypted email in response to an >> encrypted email. And *also* a warning if we receive an unencrypted >> email that was in reply to an encrypted email, so we notice if >> some information we didn't expect to be leaked was leaked. > > Now this is clearly interesting from the user's point of view. However, how > do you propose to track this relation, technically? Where shall Trojita > keep the mapping about mails and responses to them? I'm of course aware of > Message-Id/In-Reply-To/References, but this index maintenance cannot be > offloaded to the server anymore (you don't trust it after all), which means > a TON of transferred data. Confused at what the problem is here. Trojita has a "Show Messages in Threads" option, so it clearly knows which messages are in reply to which other messages. When composing a message or viewing a message Trojita should be able to see if it is in reply to another message and therefore should know if that other message was encrypted? Perhaps you mean, if the other message was deleted? The feature could be opportunistic: If Trojita knows that there is a problem, warn about it. If it do
Re: [trojita] view-source bug
On Thursday, 17 October 2013 16:56:46 CEST, Mike Cardwell wrote: I tried sending myself an email using https://emailprivacytester.com/ and viewing it in Trojita. When I viewed it, an animated "Fetching Message" icon appeared over the top of the email content and it stayed there, with seemingly no way of getting rid of it. Thanks, looks like either your HTML confuses WebKit a bit, or my understanding of QWebView::loadStarted and QWebView::loadFinished being emitted exactly the same number of times is not correct. Either way, patch under review at https://git.reviewboard.kde.org/r/113308/ . Works fine here. Forbidden per policy: QUrl( "view-source:https://emailprivacytester.com/cb/21cc0ee267da08ef/view_source"; ) This is expected -- the view-source: scheme is not allowed. QWidget::setMinimumSize: (/Gui::SimplePartWidget) The largest allowed size is (16777215,16777215) I have no idea why this happens, whether it's because your HTML code attempts to do something malicious, or whether it's some bug in EmbeddedWebView's sizing hints. Do you have a situation where this is actually a problem so that we can follow up? Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: [trojita] GnuPG-Support
On Thursday, 17 October 2013 18:00:37 CEST, Mike Cardwell wrote: God only knows. I've never used Outlook Express and I don't think it's worth catering for any more. I'm a web developer and I certainly don't cater for IE6 anymore. I imagine having a multipart/alternative at the root rather than a multipart/signed or multipart/encrypted will stop PGP working with proper email clients though. Personally, I wouldn't call such clients "proper", but I'm clearly biased here :). Confused at what the problem is here. Trojita has a "Show Messages in Threads" option, so it clearly knows which messages are in reply to which other messages. This only works on a single mailbox and relies on a server's functionality. It's common to have sent mail in some other mailbox -> the mapping cannot be done without fully reconstructing it on the client side, and that needs fetching fetching a subset of headers from each and every message. That's expensive. Sure, it's doable, but it's another feature with a very real performance tax. Not sure if you misunderstood me here. The email I sent had a "From" header of "troj...@lists.grepular.com" which is my own email address (not the lists), yet my public key has no knowledge of "troj...@lists.grepular.com", and that is perfectly valid. I just want to make sure you don't add such a restriction. Ah, my bad -- I assumed you were talking about the Sender and From fields. Cool. Then just make sure it handles the case where different keys are used to sign/encrypt different parts of an email ;) I expect that any widget showing the encryption state to the user will have to precisely indicate what parts are signed and with what key, yes. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: [trojita] GnuPG-Support
On Donnerstag, 2013-10-17, 18:38:37, Jan Kundrát wrote: > On Thursday, 17 October 2013 18:00:37 CEST, Mike Cardwell wrote: > > IE6 anymore. I imagine having a multipart/alternative at the > > root rather than > > a multipart/signed or multipart/encrypted will stop PGP working with > > proper > > email clients though. > > Personally, I wouldn't call such clients "proper", but I'm clearly biased > here :). It's not just you :) I would even go further and day that a program that can't deal with multipart MIME messages is not an email client at all! > > Confused at what the problem is here. Trojita has a "Show Messages in > > Threads" option, so it clearly knows which messages are in reply to > > which other messages. > > This only works on a single mailbox and relies on a server's functionality. > It's common to have sent mail in some other mailbox -> the mapping cannot > be done without fully reconstructing it on the client side, and that needs > fetching fetching a subset of headers from each and every message. That's > expensive. Or using local header caches which leads to trolls claiming the program is "bloated". Just a general remark: good crypto support is hard to do and is ideally part of the design [1]. Adding it after the initial design can make lots of code very complicated. Ask any KMail developers about ObjectTreeParser if you think otherwise ;) Cheers, Kevin [1] the MIIME tree parser needs to be designed in a way that it allows asynchronous completion of parts, because decryption might incur user interaction (typing passphrase), keyserver communication, etc. -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
[trojita] Cannot load remote images on WIndows XP
On Thursday, 17 October 2013 15:57:14 CEST, david.scott@gmail.com wrote: I just tested this problem and I see the same result. Unfortunately I can't help you there since I'm not that familiar with the code. Maybe Jan has a solution. I cannot help here, sorry. I don't see anything obvious or windows-version-depending within the WebKit sources, either. Does it work on some more recent versions of Windows? Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: [trojita] GnuPG-Support
On Thursday, 17 October 2013 19:02:21 CEST, Kevin Krammer wrote: It's common to have sent mail in some other mailbox -> the mapping cannot be done without fully reconstructing it on the client side, and that needs fetching fetching a subset of headers from each and every message. That's expensive. Or using local header caches which leads to trolls claiming the program is "bloated". Trojita already caches these headers locally; that's not a problem. The key difference is that Trojita does not have to load them *at all* for most of the messages now. If a mailbox has, say, 50k messages, Trojita will *not* load their headers or envelopes or anything [1]; these data are only loaded for the messages which are visible on screen [2]. This works extremely well in practice, but it also has a major drawback: we cannot thread when the server doesn't support the THREAD extension, so there's no threading on GMail. They have their own proprietary extension and we might add support for it at some point in future, but it's not here just yet. In my book, the speed difference wins big time -- just try opening a huge mailbox in Trojita and in your favorite mail client of choice and see the difference. the MIIME tree parser needs to be designed in a way that it allows asynchronous completion of parts, because decryption might incur user interaction (typing passphrase), keyserver communication, etc. Is the KDE's MIME parser reasonably Qt-only, or does it depend on KDE's utility classes? So far, Trojita relied on the server-side IMAP parsing, so adding support for GPG is not "just" a matter of throwing a validator in. I don't mind designing and implementing the auxiliary structure myself, but having a standalone MIME parser would reduce the effort quite a bit. To me, the adaptor between $whatever-data-are-returned-by-the-parser and the MVC API expected by Trojita looks much simpler than a full-blown MIME parser. That said, I've always wanted to brush up my boost::spirit skills, so it might even be a fun project in the end. Cheers, Jan [1] Anything but UID and FLAGS, which are arguably needed for various reasons that I explained in my thesis. These are, of course, also cached, and on decent IMAP servers it means almost no traffic on each mailbox sync. [2] There's a configurable preload to make sure that we don't hit network on every mouse wheel move, etc. -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: [trojita] GnuPG-Support
On Donnerstag, 2013-10-17, 19:19:38, Jan Kundrát wrote: > Is the KDE's MIME parser reasonably Qt-only, or does it depend on KDE's > utility classes? So far, Trojita relied on the server-side IMAP parsing, so > adding support for GPG is not "just" a matter of throwing a validator in. I don't know. My guess is that is is reasonably separate, it doesn't need a lot of other things. It's CMakeLists.txt indicate it links kdecore, but I don't know what for. Could be something easily replacable, e.g. using qDebug() instead of kDebug() or similar. (kdepimlibs/kmime) Very likely one of the candidates of an early KDE PIM Frameworks 5 :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
[trojita] Re: Cannot load remote images on WIndows XP
On Donnerstag, 17. Oktober 2013 19:14:42 CEST, Jan Kundrát wrote: I cannot help here, sorry. I don't see anything obvious or windows-version-depending within the WebKit sources, either. Missing image codec plugin? Cheers, Thomas
[trojita] Re: view-source bug
On Donnerstag, 17. Oktober 2013 18:26:00 CEST, Jan Kundrát wrote: On Thursday, 17 October 2013 16:56:46 CEST, Mike Cardwell wrote: I tried sending myself an email using https://emailprivacytester.com/ and viewing it in Trojita. When I viewed it, an animated "Fetching Message" icon appeared over the top of the email content and it stayed there, with seemingly no way of getting rid of it. Thanks, looks like either your HTML confuses WebKit a bit, or my understanding of QWebView::loadStarted and QWebView::loadFinished being emitted exactly the same number of times is not correct. Either way, patch under review at https://git.reviewboard.kde.org/r/113308/ . Works fine here. Forbidden per policy: QUrl( "view-source:https://emailprivacytester.com/cb/21cc0ee267da08ef/view_source";; ) This is expected -- the view-source: scheme is not allowed. QWidget::setMinimumSize: (/Gui::SimplePartWidget) The largest allowed size is (16777215,16777215) I have no idea why this happens page()->mainFrame()->contentsSize() being out of bounds, i assume. (in "EmbeddedWebView::constrainSize()") We could clamp it - but 16.777.215 are really a *lot* of pixels (13.981 WUXGA heights... 14k!) in either direction, IOW this should rather not happen and much sounds a problem with the webpage content. Cheers, Thomas
Re: [trojita] view-source bug
* on the Thu, Oct 17, 2013 at 06:26:00PM +0200, Jan Kundr?t wrote: >> QWidget::setMinimumSize: (/Gui::SimplePartWidget) The largest >> allowed size is (16777215,16777215) > > I have no idea why this happens, whether it's because your HTML code > attempts to do something malicious, or whether it's some bug in > EmbeddedWebView's sizing hints. Do you have a situation where this is > actually a problem so that we can follow up? I do not have such a situation no. I've no idea what's causing it or if there is actually a problem which will show up in more ordinary email. -- Mike Cardwell https://grepular.com/ http://cardwellit.com/ OpenPGP Key35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 signature.asc Description: Digital signature
Re: [trojita] Re: view-source bug
* on the Thu, Oct 17, 2013 at 08:45:58PM +0200, Thomas L?bking wrote: > page()->mainFrame()->contentsSize() being out of bounds, i assume. > (in "EmbeddedWebView::constrainSize()") > > We could clamp it - but 16.777.215 are really a *lot* of pixels (13.981 WUXGA > heights... 14k!) in either direction, IOW this should rather not happen and > much sounds a problem with the webpage content. Well, the HTML part of the email is purposefully malicious by the nature of the web app, but there is nothing in it which I can think of which would purposefully try to create anything that large. Any element which has a width or a height is less than 100px by 100px and most of them are only 1px large. -- Mike Cardwell https://grepular.com/ http://cardwellit.com/ OpenPGP Key35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 signature.asc Description: Digital signature
Re: [trojita] Some weird Qt5 crashes
On Thursday, October 17, 2013 02:42:51 PM Jan Kundrát wrote:
> On Thursday, 17 October 2013 12:29:48 CEST, Bartek Taczala wrote:
> > Hi, Trying to build pure Qt5 version of trojita led me to some
> > very weird crashes from within libQtCore.so.4. (maybe Qt4 and
> > Qt5 cannot coexist within one elf?)
>
> Hi Bartek, that's correct; one indeed cannot link with both Qt4 and Qt5 at
> the same time.
>
> > Here's a patch for CMake
> > that remove any linking to Qt4 libraries when WITH_QT5 option is
> > passed to CMake.
>
> This is rather strange; I have been building the Qt5 version for ages and
> have never seen a binary linked with both Qt4 and Qt5. What platform are
> you on? What version of Qt5?
>
> The patch appears to be doing other things as well, though. In particular,
> the Qt5 version would no longer link the individual sub-libraries with
>
> their dependencies -- e.g.:
> > -target_link_libraries(AppVersion Common ${QT_QTCORE_LIBRARY})
> > +if(WITH_QT5)
> > +qt5_use_modules(AppVersion Core)
> > +else()
> > +target_link_libraries(AppVersion Common ${QT_QTCORE_LIBRARY})
> > +endif()
>
> This results in libAppVersion.a no longer linking with libCommon.a. That's
> a problem for some of the platforms we support.
>
> I do like the qt5_use_modules() approach; Trojita should switch to that.
>
> Anyway, before I merge this, let's find out why is QT_QTCORE_LIBRARY
> actually pointing to Qt4. The build system is supposed to *completely*
> ignore Qt4 if configured to use Qt5. Have you tried to do something crazy
> like switching the existing build tree from Qt4 to Qt5? I.e. have you ever
> run `cmake` without the -DWITH_QT5=ON option? Could you please post your
> CMakeCache.txt? Could you nuke your build dir and try to build from
> scratch, this time making sure you use -DWITH_QT5 from the very beginning?
>
> With kind regards,
> Jan
Ah what a noob am I. Of course I didn't rm CMakeCache.
Another patch (fixes AppVersion not linked to Common) attached.
Anyway finally a decent desktop mail client on *NIX.
BR,
Bartekif(WITH_QT5)
# The Qt5's qt5_use_modules is only available on 2.8.9 or later -- sweet, isn't it?
cmake_minimum_required(VERSION 2.8.9)
else()
cmake_minimum_required(VERSION 2.8.7)
endif()
project(trojita)
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake)
# POSITION_INDEPENDENT_CODE is only available on cmake 2.8.9 or later
# Add needed flags for supported compilers which simulate POSITION_INDEPENDENT_CODE property
if(CMAKE_VERSION VERSION_LESS "2.8.9")
if(CMAKE_COMPILER_IS_GNUCXX OR "${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
else()
message(FATAL_ERROR "Needs GNU or Clang C++ compiler or CMake 2.8.9 (or later)")
endif()
else()
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
endif()
include(FindCXXFeatures)
if(NOT CXXFeatures_auto_FOUND)
message(SEND_ERROR "Your compiler doesn't support C++11's auto")
endif()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CXX11_COMPILER_FLAGS}")
include(TrojitaOption)
trojita_option(WITH_DESKTOP "Build desktop version" ON)
trojita_option(WITH_HARMATTAN "Build MeeGo Harmattan version" OFF "NOT WITH_DESKTOP")
trojita_option(WITH_QT5 "Build with Qt5 library" OFF)
trojita_option(WITH_RAGEL "Build with Ragel library" AUTO)
trojita_option(WITH_ZLIB "Build with zlib library" AUTO)
trojita_option(WITH_SHARED_PLUGINS "Enable shared dynamic plugins" ON)
trojita_option(WITH_TESTS "Build tests" ON "NOT WITH_HARMATTAN")
if(WIN32)
trojita_option(WITH_NSIS "Build Windows NSIS installer" AUTO)
endif()
if(WITH_QT5)
message(STATUS "Building the Qt5 version")
find_package(Qt5Gui REQUIRED)
find_package(Qt5Network REQUIRED)
find_package(Qt5Sql REQUIRED)
find_package(Qt5WebKitWidgets REQUIRED)
find_package(Qt5Widgets REQUIRED)
find_package(Qt5LinguistTools)
if(WITH_TESTS)
find_package(Qt5Test REQUIRED)
endif()
if(Qt5LinguistTools_FOUND)
find_package(Qt5LinguistForTrojita)
endif()
else()
message(STATUS "Building the Qt4 version")
set(QT_USE_QTNETWORK 1)
set(QT_USE_QTSQL 1)
set(QT_USE_QTWEBKIT 1)
if(WITH_TESTS)
set(QT_USE_QTTEST 1)
endif()
if(WITH_HARMATTAN)
set(QT_USE_QTDECLARATIVE 1)
endif()
trojita_find_package(Qt4 4.6 "http://qt-project.org"; "Qt4" "Needed for building" REQUIRED)
include(${QT_USE_FILE})
trojita_check_qt4_module(QTCORE REQUIRED)
trojita_check_qt4_module(QTGUI REQUIRED)
trojita_check_qt4_module(QTNETWORK REQUIRED)
trojita_check_qt4_module(QTSQL REQUIRED)
trojita_check_qt4_module(QTWEBKIT REQUIRED)
trojita_check_qt4_module(QTTEST WITH_TESTS)
trojita_check_qt4_module(QTDECLARATIVE WITH_HARMATTAN)
trojita_find_package(LinguistForTrojita "" "" "" "")
endif()
trojita_find_package(Git "" "" "" "")
if(WIN32)
trojita_find_package(MakeNSIS "" "http://nsis.sourceforge.net"; "Nullsoft Scriptable Install System" "Needed for
Re: [trojita] Re: Cannot load remote images on WIndows XP
Hi On 17.10.2013 20:36, Thomas Lübking wrote: On Donnerstag, 17. Oktober 2013 19:14:42 CEST, Jan Kundrát wrote: I cannot help here, sorry. I don't see anything obvious or windows-version-depending within the WebKit sources, either. Missing image codec plugin? Well uhm yes. The plugins where in deed missing. I was under the assumption to have them built into the webkit dll. I'm sorry for the confusion. The latest nightly builds (2013-10-17) ship with the plugins in place. Please test them. with regards Christian
Re: [trojita] Re: Cannot load remote images on WIndows XP
On Fri, 18 Oct 2013, Christian Degenkolb wrote: > Hi > > On 17.10.2013 20:36, Thomas Lübking wrote: > > On Donnerstag, 17. Oktober 2013 19:14:42 CEST, Jan Kundrát wrote: > > > >> I cannot help here, sorry. I don't see anything obvious or > >> windows-version-depending within the WebKit sources, either. > > > > Missing image codec plugin? > > Well uhm yes. The plugins where in deed missing. I was under the > assumption to have them built into the webkit dll. > > I'm sorry for the confusion. The latest nightly builds (2013-10-17) ship > with the plugins in place. Please test them. > > with regards > Christian > Hi Christian! I tested the 17, October nightly build (for about 30 seconds) and this one seems to work correctly. Thanks so much for the help. Now I need to see if I can get Susan to tolerate the lack of little niceties like having to set the sort order on every running of the program and having to set the column widths, having to select the inbox on program startup, or having to ask that remote graphics be loaded for every viewing of every email. I have both Trojita and Thunderbird loaded on her machine and I fear she may want to use Thunderbird until Trojita is a little more user friendly. Thanks again for the help Christian (and you too Jan) I will continue to use Trojita for my graphical client (Mutt is my daily workhorse) so even if Susan doesn't elect to use it right now, I will have her look at it again when the user presentation is a little more friendly. Dave
