[GitHub] [geronimo-javamail] rmannibucau commented on pull request #1: GERONIMO-6780 added Oauth2 support for geronimo Java Mail Provider
rmannibucau commented on pull request #1: URL: https://github.com/apache/geronimo-javamail/pull/1#issuecomment-850155113 @fpapon sure but I don't have this karma it seems -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [geronimo-javamail] fpapon commented on pull request #1: GERONIMO-6780 added Oauth2 support for geronimo Java Mail Provider
fpapon commented on pull request #1: URL: https://github.com/apache/geronimo-javamail/pull/1#issuecomment-850140738 @rmannibucau this one was merged in svn so we can close it -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (GERONIMO-6793) Do not auto-enable all available Cyphers in TLS/SSL protocol handling in MailConnection
[ https://issues.apache.org/jira/browse/GERONIMO-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352677#comment-17352677 ] Romain Manni-Bucau commented on GERONIMO-6793: -- [~fredrikj] for me it is the same, global for mail rarely works well until you only send mail to one provider (and don't use any other network related stuff). If using the jvm by default I would make the property o mail.protocol.ssl.xxx configurable with aliases more easily (= gmail for example) since this is what is hard to do from the common feedback we got by the past. Also maybe logging it better that it inherits from the JVM can help? > Do not auto-enable all available Cyphers in TLS/SSL protocol handling in > MailConnection > --- > > Key: GERONIMO-6793 > URL: https://issues.apache.org/jira/browse/GERONIMO-6793 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: mail >Reporter: Richard Zowalla >Priority: Major > > Check and discuss, if it is a good idea to enable all cyphers in TLS/SSL > protocol handling in MailConnection.java > Some cyphers are deprecated for good reasons and shouldn't be used. > This enhancement might possibily include > * Allow users to specifiy cyphers via properties (custom factory is already > possible) > * If we have no user defined cyphers available, fallback to the JVMs default > cyphers. > > This is a follow up issue raised from the discussion on the dev mailing list, > see > http://mail-archives.apache.org/mod_mbox/geronimo-dev/202012.mbox/%3C096fbb867eda8e090eddf80fbd81cf787ac87945.camel%40hs-heilbronn.de%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GERONIMO-6793) Do not auto-enable all available Cyphers in TLS/SSL protocol handling in MailConnection
[ https://issues.apache.org/jira/browse/GERONIMO-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352668#comment-17352668 ] Fredrik Jonson commented on GERONIMO-6793: -- The current geronimo-javamail implementation _already_ aligns with and relies on the jvm defaults today, only it is currently using all the jvm's _supported_ ciphers instead of only its_enabled_ ciphers. So, surely geronimo-javamail _can continue to align_ with the jvm defaults, changing it only to use the set of _enabled_ jvm ciphers for tls sockets by default instead. That follows the principle of least surprise, and general knowledge of TLS configuration for the jvm. And if someone for some reason do not want to use the same default enabled ciphers for their smtp client in geronimo-javamail as for their other jvm TLS socket clients, they will be able override it with the "mail.smtp.ssl.ciphersuites" property when that is implemented. That would also be consistent with the proposed patch in GERONIMO-6792, which also uses the _jvm default protocols_ if nothing else is specified by javamail property mail.smtp.ssl.protocols. BTW, in OpenJDK the jvm http client has a specific flag "https.cipherSuites" which affects only http clients. So if you have specific needs for http, you do not have to modify the general "jdk.tls.client.cipherSuites" which applies to all client TLS sockets. > Do not auto-enable all available Cyphers in TLS/SSL protocol handling in > MailConnection > --- > > Key: GERONIMO-6793 > URL: https://issues.apache.org/jira/browse/GERONIMO-6793 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: mail >Reporter: Richard Zowalla >Priority: Major > > Check and discuss, if it is a good idea to enable all cyphers in TLS/SSL > protocol handling in MailConnection.java > Some cyphers are deprecated for good reasons and shouldn't be used. > This enhancement might possibily include > * Allow users to specifiy cyphers via properties (custom factory is already > possible) > * If we have no user defined cyphers available, fallback to the JVMs default > cyphers. > > This is a follow up issue raised from the discussion on the dev mailing list, > see > http://mail-archives.apache.org/mod_mbox/geronimo-dev/202012.mbox/%3C096fbb867eda8e090eddf80fbd81cf787ac87945.camel%40hs-heilbronn.de%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GERONIMO-6793) Do not auto-enable all available Cyphers in TLS/SSL protocol handling in MailConnection
[ https://issues.apache.org/jira/browse/GERONIMO-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352566#comment-17352566 ] Romain Manni-Bucau commented on GERONIMO-6793: -- [~fredrikj] > IMHO we can't align JVM defaults since they will often be for http clients >and not mails so we must pick some. Guess we need to review the most common providers (there are ~12) and to just use what they support by default. The other issue is that even if defaults are okish, they can be tuned on the JVM - often for http clients as mentionned in my first comment - which would break the mail client. So best is to not rely on any global JVM setting IMHO. > Do not auto-enable all available Cyphers in TLS/SSL protocol handling in > MailConnection > --- > > Key: GERONIMO-6793 > URL: https://issues.apache.org/jira/browse/GERONIMO-6793 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: mail >Reporter: Richard Zowalla >Priority: Major > > Check and discuss, if it is a good idea to enable all cyphers in TLS/SSL > protocol handling in MailConnection.java > Some cyphers are deprecated for good reasons and shouldn't be used. > This enhancement might possibily include > * Allow users to specifiy cyphers via properties (custom factory is already > possible) > * If we have no user defined cyphers available, fallback to the JVMs default > cyphers. > > This is a follow up issue raised from the discussion on the dev mailing list, > see > http://mail-archives.apache.org/mod_mbox/geronimo-dev/202012.mbox/%3C096fbb867eda8e090eddf80fbd81cf787ac87945.camel%40hs-heilbronn.de%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GERONIMO-6793) Do not auto-enable all available Cyphers in TLS/SSL protocol handling in MailConnection
[
https://issues.apache.org/jira/browse/GERONIMO-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352563#comment-17352563
]
Fredrik Jonson commented on GERONIMO-6793:
--
[~romain.manni-bucau] I'm curious, why would it be a bad idea to default to
aligning with the ciphers _enabled by default_ by the JVM? I.e
SSLSocket.getEnabledCipherSuites().
I would prefer if the implementation defaulted to the jvm's enabled ciphers. At
least as long as a explicit list of ciphers isn't provided via the
"mail.smtp.ssl.ciphersuites" property. Selecting by hand and hard coding a list
of ciphers in geronimo-javamail risk becoming a maintenance burden, and a
source of obscure runtime errors as seen in GERONIMO-6792.
BTW, looking at the code, AFAIU, the current implementation explicitly
overrides the jvm's default selection (getEnabledCipherSuites()) and instead
enables all supported cipher suites. This seems intentional, but I cannot find
any reason for it in svn version history or jira. Anyone know why? Are there
really jvms that does not provide a list of enabled ciphers at all by default?
https://svn.apache.org/viewvc?view=revision=1641706
https://svn.apache.org/viewvc/geronimo/javamail/tags/geronimo-javamail_1.6-1.0.0/geronimo-javamail_1.6_provider/src/main/java/org/apache/geronimo/javamail/util/MailConnection.java?view=markup#l595
Below is the output from comparing jvm cipher suits of Openjdk 1.7, 8 and 11,
comparing supported vs enabled ciphers. The notable difference is that that a
small number of known weak ciphers are not included in the list of enabled
ciphers. It seems a small and good first step is to move from using supported
to using enabled ciphers by default.
{{
= OpenJDK 11 =
Supported ciphers [TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Disabled ciphers []
= OpenJDK 1.8 =
Supported ciphers [TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
[jira] [Commented] (GERONIMO-6792) Fix hard-coded TLSv1 version in MailConnection.java for Java Mail 1.6
[ https://issues.apache.org/jira/browse/GERONIMO-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352486#comment-17352486 ] Francois Papon commented on GERONIMO-6792: -- Hi, The migration from svn to gitbox of this repo is on track and I will release soon. > Fix hard-coded TLSv1 version in MailConnection.java for Java Mail 1.6 > - > > Key: GERONIMO-6792 > URL: https://issues.apache.org/jira/browse/GERONIMO-6792 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: mail >Reporter: Richard Zowalla >Priority: Major > Attachments: GERONIMO-6792-v4-no-hardcoding.diff, > GERONIMO-6792-v4.diff > > > Hi, > I encountered some issues when using Geronimo Java Mail 1.6 (1.0.0) bundled > with TomEE 8.0.5. The related thread [1] can be found on the > [us...@tomee.apache.org|mailto:us...@tomee.apache.org] Mailing-List. > In short: > * Our mail server does only support TLS 1.2 or TLS 1.3 > * Geronimo Java Mail 1.6 in version 1.0.0 has TLS 1.0 hard-coded in the > source and does not use the default protocols or the specified ones via > *mail.smtp.ssl.protocols* for a TLS connection. > I have attached a patch created via SVN DIFF. > [1] [https://www.mail-archive.com/users@tomee.apache.org/msg17544.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GERONIMO-6792) Fix hard-coded TLSv1 version in MailConnection.java for Java Mail 1.6
[ https://issues.apache.org/jira/browse/GERONIMO-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352445#comment-17352445 ] Fredrik Jonson edited comment on GERONIMO-6792 at 5/27/21, 12:43 PM: - After RFC 8996 - Deprecating TLS 1.0 and TLS 1.1 - was published in march 2021, I have noticed that some mail providers indeed now disallow TSLv1.0. This obviously makes the current release of geronimo-javamail fail delivery to such RFC-compliant servers. I have locally built and manually tested the patch GERONIMO-6792-v4-no-hardcoding.diff. I can confirm that it by default selects the default TLS protocols of the JVM, which is a great default behaviour btw. I have also tested using the mail.smtp.ssl.protocols flag, with various protocol versions, and it appears to also work as intended. Is there anything else a non-committer can do to help nudge this into a proper (1.0.1?) release sometime soon? PS. A big _Thank you_ to Richard Z for finding the bug, and proposing a patch! was (Author: fredrikj): After RFC 8996 - Deprecating TLS 1.0 and TLS 1.1 - was published in march 2021, I have noticed that some mail providers indeed now disallow TSLv1.0. This obviously makes the current release of geronimo-javamail fail delivery to such RFC-compliant servers. I have locally built and manually tested the patch GERONIMO-6792-v4-no-hardcoding.diff. I can confirm that it by default selects the default TLS protocols of the JVM, which is a great default behaviour btw. I have also tested using the mail.smtp.ssl.protocols flag, with various protocol versions, and it appears to also work as intended. Is there anything else a non-committer can do to help nudge this into a proper (1.0.1?) release sometime soon? PS. A big _Thank you_ to Richard W for finding the bug, and proposing a patch! > Fix hard-coded TLSv1 version in MailConnection.java for Java Mail 1.6 > - > > Key: GERONIMO-6792 > URL: https://issues.apache.org/jira/browse/GERONIMO-6792 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: mail >Reporter: Richard Zowalla >Priority: Major > Attachments: GERONIMO-6792-v4-no-hardcoding.diff, > GERONIMO-6792-v4.diff > > > Hi, > I encountered some issues when using Geronimo Java Mail 1.6 (1.0.0) bundled > with TomEE 8.0.5. The related thread [1] can be found on the > [us...@tomee.apache.org|mailto:us...@tomee.apache.org] Mailing-List. > In short: > * Our mail server does only support TLS 1.2 or TLS 1.3 > * Geronimo Java Mail 1.6 in version 1.0.0 has TLS 1.0 hard-coded in the > source and does not use the default protocols or the specified ones via > *mail.smtp.ssl.protocols* for a TLS connection. > I have attached a patch created via SVN DIFF. > [1] [https://www.mail-archive.com/users@tomee.apache.org/msg17544.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GERONIMO-6792) Fix hard-coded TLSv1 version in MailConnection.java for Java Mail 1.6
[ https://issues.apache.org/jira/browse/GERONIMO-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352445#comment-17352445 ] Fredrik Jonson commented on GERONIMO-6792: -- After RFC 8996 - Deprecating TLS 1.0 and TLS 1.1 - was published in march 2021, I have noticed that some mail providers indeed now disallow TSLv1.0. This obviously makes the current release of geronimo-javamail fail delivery to such RFC-compliant servers. I have locally built and manually tested the patch GERONIMO-6792-v4-no-hardcoding.diff. I can confirm that it by default selects the default TLS protocols of the JVM, which is a great default behaviour btw. I have also tested using the mail.smtp.ssl.protocols flag, with various protocol versions, and it appears to also work as intended. Is there anything else a non-committer can do to help nudge this into a proper (1.0.1?) release sometime soon? PS. A big _Thank you_ to Richard W for finding the bug, and proposing a patch! > Fix hard-coded TLSv1 version in MailConnection.java for Java Mail 1.6 > - > > Key: GERONIMO-6792 > URL: https://issues.apache.org/jira/browse/GERONIMO-6792 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: mail >Reporter: Richard Zowalla >Priority: Major > Attachments: GERONIMO-6792-v4-no-hardcoding.diff, > GERONIMO-6792-v4.diff > > > Hi, > I encountered some issues when using Geronimo Java Mail 1.6 (1.0.0) bundled > with TomEE 8.0.5. The related thread [1] can be found on the > [us...@tomee.apache.org|mailto:us...@tomee.apache.org] Mailing-List. > In short: > * Our mail server does only support TLS 1.2 or TLS 1.3 > * Geronimo Java Mail 1.6 in version 1.0.0 has TLS 1.0 hard-coded in the > source and does not use the default protocols or the specified ones via > *mail.smtp.ssl.protocols* for a TLS connection. > I have attached a patch created via SVN DIFF. > [1] [https://www.mail-archive.com/users@tomee.apache.org/msg17544.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
