[ksmtp] [Bug 394770] STARTTLS is restricted to TLS 1.0

2018-05-28 Thread Juri Vitali
https://bugs.kde.org/show_bug.cgi?id=394770

--- Comment #3 from Juri Vitali  ---
Poking around the code a bit more, I think a sane default would be to use
KTcpSocket::SecureProtocols, which is equal to QSsl::SecureProtocols, which in
turn is defined to be by the official docs "The default option, using protocols
known to be secure; currently behaves similar to TlsV1Ssl3 except denying SSLv3
connections that does not upgrade to TLS." [1].

Other than that, a switch could be given to the user to use a specific - more
secure - protocol, but beyond that an update to KIO would be required, as
KTcpSocket seems to be supporting only a limited subset of the Qt's TLS
protocols. [2]

[1]: https://doc.qt.io/qt-5/qssl.html#SslProtocol-enum
[2]: https://api.kde.org/frameworks/kio/html/ktcpsocket_8h_source.html

-- 
You are receiving this mail because:
You are the assignee for the bug.

[ksmtp] [Bug 394770] STARTTLS is restricted to TLS 1.0

2018-05-28 Thread Juri Vitali
https://bugs.kde.org/show_bug.cgi?id=394770

--- Comment #2 from Juri Vitali  ---
Created attachment 112935
  --> https://bugs.kde.org/attachment.cgi?id=112935=edit
Workaround: TLS v1 -> TLS v1.2

-- 
You are receiving this mail because:
You are the assignee for the bug.

[ksmtp] [Bug 394770] STARTTLS is restricted to TLS 1.0

2018-05-28 Thread Juri Vitali
https://bugs.kde.org/show_bug.cgi?id=394770

--- Comment #1 from Juri Vitali  ---
Confirmed here too (latest Archlinux version, 18.04.1).
I would guess this is a leftover from KDE4, as the relevant version of the
library involved does not mention any protocol higher than TLS v1.0 [1], while
the newer Frameworks library does (and TLSV1_0 becomes an alias of TLSV1) [2].

Fow now, a quick and dirty substitution of all instances of TlsV1 to TlsV1_2
works correctly (see patch), but obviously would break any situation where the
server does not support that version.

[1]:
https://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/classKTcpSocket.html
[2]: https://api.kde.org/frameworks/kio/html/ktcpsocket_8h_source.html

-- 
You are receiving this mail because:
You are the assignee for the bug.

[ksmtp] [Bug 394770] STARTTLS is restricted to TLS 1.0

2018-05-28 Thread Juri Vitali
https://bugs.kde.org/show_bug.cgi?id=394770

Juri Vitali  changed:

   What|Removed |Added

 CC||j...@dbzero.it
 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 379467] Display "Date:" header in sender's local timezone

2017-06-15 Thread Juri Vitali
https://bugs.kde.org/show_bug.cgi?id=379467

--- Comment #4 from Juri Vitali <j...@dbzero.it> ---
I'm using the default theme, that should be the 'Intelligent' one for the
message list, and 'KMail 5.2' for the headers, if that's what you mean.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 379467] Display "Date:" header in sender's local timezone

2017-06-14 Thread Juri Vitali
https://bugs.kde.org/show_bug.cgi?id=379467

--- Comment #2 from Juri Vitali <j...@dbzero.it> ---
I'm using the latest version on Arch Linux repositories. Currently it is at
5.5.2, but it was the same on previous versions too.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 379467] Display "Date:" header in sender's local timezone

2017-05-03 Thread Juri Vitali
https://bugs.kde.org/show_bug.cgi?id=379467

Juri Vitali <j...@dbzero.it> changed:

   What|Removed |Added

 CC||j...@dbzero.it

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 379467] New: Display "Date:" header in sender's local timezone

2017-05-03 Thread Juri Vitali
https://bugs.kde.org/show_bug.cgi?id=379467

Bug ID: 379467
   Summary: Display "Date:" header in sender's local timezone
   Product: kmail2
   Version: unspecified
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: UI
  Assignee: kdepim-bugs@kde.org
  Reporter: j...@dbzero.it
  Target Milestone: ---

In the message view the "Date:" header is always shown in user's local
timezone, with no reference to sender's original one, so the only possible way
to find out the original time is to manually inspect the raw message, and look
at the Date: header.
It would be useful to give the user the choice to choose whether to display the
message date in his own or in the sender's timezone, maybe keeping the local
timezone in the message list and the original one in the headers view, so to
facilitate the message sorting while avoiding the need to manually inspect the
message.

Example (my timezone is UTC+2):
(header)Date: Thu, 27 Apr 2017 14:19:49 -0400 
(message view)  27/04/17 20:19
(message list)  giovedì 20:19

-- 
You are receiving this mail because:
You are the assignee for the bug.