[ANNOUNCE] Apache Geronimo OpenAPI 1.0.14 released
The Apache Geronimo team is happy to announce the Apache Geronimo OpenAPI 1.0.14 release. It brings several fixes like supporting @BeanParam but also enabling the reuse jsonschema generator and openapi model without jaxrs. You can learn more on Apache Geronimo OpenAPI and more generally the Microprofile ecosystem at Geronimo at http://geronimo .apache.org/microprofile/. Apache Geronimo team
[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=17243842#comment-17243842 ] Richard Zowalla commented on GERONIMO-6793: --- > If we have time we should probably review most mail provider to ensure they >all work by default and tuning is only needed for custom company mail servers >for example. Yup, I agree with that. At least, a tuning option should be possible instead of an allow-all policy. Overall, mail servers are known to be outdated or implementing TLS in a sloopy way :) For that reason: If we get the most common providers (gmail, proton, etc.) to work and allow a custom way to adjust the cyphers, I would be happy. Problem is, that cyphers do change with the time, so we would need to monitor this changes and reflect it in the code base. Maybe [~b.eckenfels] also has some thoughts on this? :) > 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=17243834#comment-17243834 ] Romain Manni-Bucau commented on GERONIMO-6793: -- IMHO we can't align JVM defaults since they will often be for http clients and not mails so we must pick some. So question is: which one to select? If we have time we should probably review most mail provider to ensure they all work by default and tuning is only needed for custom company mail servers for example. What do you think? > 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)
Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?
Hi, I filled a JIRA [1] to address the issues related to cypher suites. Yes, the original PR changes are related to STARTLS code, but I think, that we are fine (at least for now). Gruss Richard [1] https://issues.apache.org/jira/browse/GERONIMO-6793 Am Donnerstag, den 03.12.2020, 20:55 + schrieb Bernd Eckenfels: > Hello, > > Yes I agree, the ciphers would be its own (security) issue. > > and it might be not so simple to fix as Mail servers are notoriously > outdated and TLS-sloppy. Luckily JDK has already some provisions for > demoting old/deprecated ciphers and also disable most of the not > useable insecure ones in the supported list (but still this weakening > of the JDK defaults should be opt-in). > > BTW i haven’t checked all of the code, if you are requesting TLS > context, there might be another point to look out for protocol names > (very unfortunate API design I must say). I imagine this might be > needed for STARTLS code? > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > > > Von: Zowalla, Richard > Gesendet: Donnerstag, Dezember 3, 2020 1:48 PM > An: dev@geronimo.apache.org > Betreff: Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / > 1.3 Support? > > > Hi Bernd, > > @1: I think the original intention of the code (before the PR) was to > disallow the use of sslv2 or sslv3 for the tls handling code thus the > hard-coding to tlsv1 as ssl is handled in another part of the class. > But I agree, that we could remove the "else" and consequently all > kind > of hard-coded TLS config. In this way, we would trust in the jdk > defaults. > > @2: I think, that the aspect related to cyphers would be a separate > issue / PR. I agree, that enabling all available cyphers (L602/L603) > is > not a good idea in general, but this code hasn't changed in the > proposed PR :) > > > wdyt? > > Best > Richard > > Am Donnerstag, den 03.12.2020, 12:11 + schrieb Bernd Eckenfels: > > Hello, > > > > Allowing protocols to be configured is good, but I am not sure why > > you fall back to a hand selected list of no configuration is given, > > why not simply use the JDK defaults, they are frequently adjusted > > (just recently the older TLS versions get removed). > > > > Along this line, why enable all supported ciphers? There is a good > > reason why the JDK disables many. I would stick to the default > > ciphers (and protocols). > > > > Gruss > > Bernd > > -- > > http://bernd.eckenfels.net > > > > Von: Zowalla, Richard > > Gesendet: Mittwoch, Dezember 2, 2020 4:57 PM > > An: dev@geronimo.apache.org > > Betreff: Re: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / > > 1.3 Support? > > > > Should be fixed now. > > > > Am Mittwoch, den 02.12.2020, 15:32 + schrieb Zowalla, Richard: > > > It is indeed > > > > > > mail..ssl.socketFactory.class > > > > > > (see line 88, MailConnection#MAIL_SSL_FACTORY_CLASS -> uses > > > reflection to create an instance of the specified factory. > > > > > > or > > > > > > mail..ssl.socketFactory > > > > > > (which requires adding a pre-configured and instantiated factory > > > instance into the properties of the mail session) > > > > > > To be complete, I will add this way to the README as well. > > > > > > Am Mittwoch, den 02.12.2020, 16:24 +0100 schrieb Romain Manni- > > Bucau: > > > > Isnt the property mail..ssl.socketFactory ? > > > > > > > > Romain Manni-Bucau > > > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book > > > > > > > > > > > > Le mer. 2 déc. 2020 à 16:09, Zowalla, Richard < > > > > richard.zowa...@hs-heilbronn.de> a écrit : > > > > > Okay. Thanks for the feedback - today, I learned a lot about > > the > > > > > insides of Javamail :) > > > > > > > > > > I have updated my PR: > > > > > > > > > > - Updated README.txt to contain some documentation about > > setting > > > > > a > > > > > custom ssl socket factory > > > > > - Dropped TLSv1 in the fallback protocols (if no custom set > > > > > properties > > > > > are present) > > > > > > > > > > Thanks, > > > > > Richard > > > > > > > > > > > > > > > Am Mittwoch, den 02.12.2020, 15:29 +0100 schrieb Romain > Manni- > > > > > Bucau: > > > > > > Guess you can just create a readme in the geronimo-javamail > > > > > root > > > > > > project, will be sufficient as a first step. > > > > > > Abou he default I wonder if dropping tlsv1 cant be good > since > > > > > it will > > > > > > be dropped soon? > > > > > > Otherwise just adding the missing "o" in protocols i'm fine > > > > > with your > > > > > > proposal. > > > > > > > > > > > > We need to refine if we do a javamail subsite or a generic > > spec > > > > > > subsite sill :s. > > > > > > > > > > > > Romain Manni-Bucau > > > > > > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book > > > > > > > > > > > > > > > > > > Le mer. 2 déc. 2020 à 15:26, Zowalla, Richard < > > > > > > richard.zowa...@hs-heilbronn.de> a écrit : > > > > > > > I updated the diff (cf. v2) to (hopefully) address the
[jira] [Created] (GERONIMO-6793) Do not auto-enable all available Cyphers in TLS/SSL protocol handling in MailConnection
Richard Zowalla created GERONIMO-6793: - Summary: 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 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)
