[jira] [Closed] (JAMES-3646) Review of file based components
[ https://issues.apache.org/jira/browse/JAMES-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Tellier closed JAMES-3646. - Resolution: Fixed > Review of file based components > --- > > Key: JAMES-3646 > URL: https://issues.apache.org/jira/browse/JAMES-3646 > Project: James Server > Issue Type: Improvement > Components: mailbox, MailStore & MailRepository, Queue, sieve >Affects Versions: master, 3.6.0 >Reporter: Benoit Tellier >Priority: Major > Fix For: 3.7.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Running a quick audit, I realise none of James file based components > validates the underlying file names. One could inject relative path to write > files / read files on any location. > The affected components are: > - The file mail queue > - Maildir mailbox implementation > - Sieve file storage > - and FileMail repository > Regarding the fix: > - Enforce Sieve files to belong to the Sieve root > - Validate that created FileRepositories belong to the James root > - Drop the long deprecated FileMailQueue rather than fixing it... > - I also proposes to drop the maildir implementation - unless someone else > devote himself to fix it! > Regards, > Benoit -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3674) Support password salting and hash scheme upgrading
[
https://issues.apache.org/jira/browse/JAMES-3674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17452790#comment-17452790
]
Benoit Tellier commented on JAMES-3674:
---
https://github.com/linagora/james-project-private/issues/280 provides PBKDF2
hashing (based on username)
> bcrypt and friends usually encode all necessary parameters in the password
> field itself
brcrypt do not have a default implementation in Java and I am reluctant to add
a dependency.
> Support password salting and hash scheme upgrading
> --
>
> Key: JAMES-3674
> URL: https://issues.apache.org/jira/browse/JAMES-3674
> Project: James Server
> Issue Type: Improvement
> Components: UsersStore & UsersRepository
>Affects Versions: master
>Reporter: Karsten Otto
>Priority: Major
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Currently, James does not use salt during password hashing, so its password
> database is vulnerable to rainbow table cracking if someone ever manages to
> steal it. Furthermore, there is no mechanism to upgrade user passwords to
> stronger/different hashing once they are created (cf. legacy hashing mode).
> This is a problem for any installation that does not employ an external LDAP
> user database.
> A simple solution is to include the user name as salt in the password hash.
> For this purpose, the {{hashingMode}} choices in {{usersrepository.xml}}
> should include an new mode "salted" in addition to "legacy" and "default".
> Additionally, the database should include an explicit column in the user
> table, which specifies the {{hashingMode}} of the stored password, and is
> used during verification. However, when a user changes the password, the
> configured {{algorithm}} and {{hashingMode}} from {{usersrepository.xml}}
> will be used instead. This way, the database gradually upgrades over time to
> the preferred setting.
> T-Shirt size L.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-3487) Configure MimeMessageInputStreamSource THRESHOLD
[ https://issues.apache.org/jira/browse/JAMES-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Tellier closed JAMES-3487. - Resolution: Fixed > Configure MimeMessageInputStreamSource THRESHOLD > > > Key: JAMES-3487 > URL: https://issues.apache.org/jira/browse/JAMES-3487 > Project: James Server > Issue Type: Improvement > Components: James Core >Reporter: Benoit Tellier >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > > This represents the point at which we should switch from a memory storage > into a file storage. > Defaults is 100 Kb. > Obviously this parameter is important: > - Higher values will operate mostly in-memory thus will have low latencies > but will trash the heap and might trigger a GC hell. > - Lower values will defensively operate on files. Higher latencies but > predictable throughtput. Modern SSDs and FS cache should enable to keep up > with high rates. > Optimally we should have some bench showing the impact of this parameter. > Related to JAMES-3477. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Call for vote: Apache James 3.6.1
+1, Rene. On 03/12/2021 08:29, btell...@apache.org wrote: Hi, I would like to propose a new vote for 3.6.1 release of the Apache James server. You can find: - The maven release staged in repository.apache.org as the artifact #1056: https://repository.apache.org/content/repositories/orgapachejames-1056/ - The changelog for 3.6.1: https://github.com/chibenwa/james-project/blob/changelog-3.6.1/CHANGELOG.md (to be merged on master) - The compatibility instructions/upgrade recommendation: https://github.com/chibenwa/james-project/blob/changelog-3.6.1/upgrade-instructions.md#361-version This release is only comprised of bug fixes. Voting rules: - This is a majority approval: this release may not be vetoed. - A quorum of 3 binding votes is required - The vote starts at Friday 3rd of December 2021, 8am30 UTC+7 - The vote ends at Friday 10th of December 2021, 8am30 UTC+7 You can answer to it just with +1 and -1. Down-votes may be motivated. 3 binding votes are expected move forward on this release. Cheers, PMC member name - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Authentication in James: Enable/require/disable OpenID for JMAP, IMAP and SMTP
+1, Rene. On 02/12/2021 11:56, btell...@linagora.com wrote: Hopefully rendered correctly in plain text... - Hello Jamers! As part of my work at Linagora, we are looking toward - better integrating James within our product suite and for us this means support "Single Sign On" and "Single Log Out" for JMAP following the OpenId connect standard [0]. - Improving security standards used to opperate James. (We have a growing activity within the health care market, sensible to security arguments) Regarding security standards we should ideally: - Be able to NOT advertise AUTH / LOGIN capabilities of unencrypted channels (Correspond to IMAP plainAuthDissallowed but generalized to other protocols) - Be able to require OAUTH/OIDC authentication for all protocols (IMAP, SMTP, JMAP) - this is what some of the health care providers we spoke to desired to do. - For our collaborative suite usage, while OIDC only for JMAP makes sense, we still wish to maintain PLAIN AUTH for IMAP and SMTP. - Of course settings for regular users not interested in OIDC should not change (no breaking changes, OIDC adoption is opt-in only). As such we propose ourselves to: - Contribute IMAP and SMTP SASL OAUTH extension described in [RFC-7628] - Modularize JMAP authentication mechanisms (letting the admin choose which one she wishes to use) - Enable authentication through a header mechanism eg `X-USER: btell...@apache.org`, which can be used to delegate OIDC authentication through a third party API gateway. We have Krackend [1] in mind. - Share documentation and a docker-compose of OIDC setup for IMAP, SMTP and JMAP in https://github.com/apache/james-project/tree/master/examples/oidc. This would include: - A LDAP still used by James UsersRepository. Provisionned with a testing user. - A pre-configured Keycloack [2] OpenID connect provider. - A pre-configured Krakend API gateway proxying JMAP - And finally a James server configured to only accept OIDC as an authentication mechanism for IMAP, SMTP and JMAP. - Unit tests for existing IMAP `plainAuthDissallowed` configuration parameter. Finally this is a good opportunity to restructure authentication related settings in imapserver.xml and smtpserver.xml file. Here are proposals for both files: [imapserver.xml] imapserver-ssl 0.0.0.0:993 file://conf/private.key file://conf/certs.self-signed.csr true|false file://conf/imapJWT.pub https://example.com/.well-known/openid-config mailAddress [smtpserver.xml] smtpserver-ssl 0.0.0.0:465 file://conf/private.key file://conf/certs.self-signed.csr true|false true|false file://conf/imapJWT.pub https://example.com/.well-known/openid-config mailAddress You can see that: - The `plainAuthDissallowed` parameter is proposed to be renamed to `auth.requireSSL`. (of course we should support fallback NOT to have a breaking change) - `auth.plainAuthEnabled` enable turning on/off plain auth, which allows having OIDC only mechanism. - `auth.requireSSL` will be generalized to SMTP. - In SMTP `requireAuth` setting is very misleading as it rather is `requireAuthForRelay`. I propose we rename this configuration option (of course we should support fallback NOT to have a breaking change). Here is the implementation strategies we would follow: - For JMAP have Krakend doing all the hard job for us, and use a dedicated header to carry the information over to James. - Our code contributions aims at easing such a setup (that would only require configuration) - Provide an informative example using krakend. We understand that this choice is ours, yet sharing it could allow reuse or similar setup - If some people wishes to write an OIDC authentication strategy directly in James then they perfectly can! (Reusing the modularization of JMAP authentication strategies we would provide). - For IMAP and SMTP then we proposes to check the bearer payload against a statically configured public key for these protocols. (Sadly there is no API gateway for those protocols) - Drawbacks includes no revocation of access tokens (once it's signed it is always valid), revocation do not shut down existing connections authenticated with the revocated token, and key rotation would require reconfiguration and reboot. - One alternative would be to systematically ask the OpenID server to validate the bearer. This might be acceptable as IMAP and SMTP are long lived protocols that do not often establish new connections. While this do not change anything
Call for vote: Apache James 3.6.1
Hi, I would like to propose a new vote for 3.6.1 release of the Apache James server. You can find: - The maven release staged in repository.apache.org as the artifact #1056: https://repository.apache.org/content/repositories/orgapachejames-1056/ - The changelog for 3.6.1: https://github.com/chibenwa/james-project/blob/changelog-3.6.1/CHANGELOG.md (to be merged on master) - The compatibility instructions/upgrade recommendation: https://github.com/chibenwa/james-project/blob/changelog-3.6.1/upgrade-instructions.md#361-version This release is only comprised of bug fixes. Voting rules: - This is a majority approval: this release may not be vetoed. - A quorum of 3 binding votes is required - The vote starts at Friday 3rd of December 2021, 8am30 UTC+7 - The vote ends at Friday 10th of December 2021, 8am30 UTC+7 You can answer to it just with +1 and -1. Down-votes may be motivated. 3 binding votes are expected move forward on this release. Cheers, PMC member name - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Authentication in James: Enable/require/disable OpenID for JMAP, IMAP and SMTP
+1 On Thu, Dec 2, 2021 at 5:57 AM btell...@linagora.com wrote: > Hopefully rendered correctly in plain text... > > - > > Hello Jamers! > > As part of my work at Linagora, we are looking toward > - better integrating James within our product suite and for us this > means support "Single Sign On" and "Single Log Out" for JMAP following > the OpenId connect standard [0]. > - Improving security standards used to opperate James. (We have a > growing activity within the health care market, sensible to security > arguments) > > Regarding security standards we should ideally: > - Be able to NOT advertise AUTH / LOGIN capabilities of unencrypted > channels (Correspond to IMAP plainAuthDissallowed but generalized to > other protocols) > - Be able to require OAUTH/OIDC authentication for all protocols (IMAP, > SMTP, JMAP) - this is what some of the health care providers we spoke to > desired to do. > - For our collaborative suite usage, while OIDC only for JMAP makes > sense, we still wish to maintain PLAIN AUTH for IMAP and SMTP. > - Of course settings for regular users not interested in OIDC should > not change (no breaking changes, OIDC adoption is opt-in only). > > As such we propose ourselves to: > - Contribute IMAP and SMTP SASL OAUTH extension described in [RFC-7628] > - Modularize JMAP authentication mechanisms (letting the admin choose > which one she wishes to use) > - Enable authentication through a header mechanism eg `X-USER: > btell...@apache.org`, which can be used to delegate OIDC authentication > through a third party API gateway. We have Krackend [1] in mind. > - Share documentation and a docker-compose of OIDC setup for IMAP, SMTP > and JMAP in > https://github.com/apache/james-project/tree/master/examples/oidc. This > would include: > - A LDAP still used by James UsersRepository. Provisionned with a > testing user. > - A pre-configured Keycloack [2] OpenID connect provider. > - A pre-configured Krakend API gateway proxying JMAP > - And finally a James server configured to only accept OIDC as an > authentication mechanism for IMAP, SMTP and JMAP. > - Unit tests for existing IMAP `plainAuthDissallowed` configuration > parameter. > > Finally this is a good opportunity to restructure authentication related > settings in imapserver.xml and smtpserver.xml file. > > Here are proposals for both files: > > [imapserver.xml] > > > imapserver-ssl > 0.0.0.0:993 > > file://conf/private.key > file://conf/certs.self-signed.csr > > > > true|false > > file://conf/imapJWT.pub > > https://example.com/.well-known/openid-config > > mailAddress > > > > > > [smtpserver.xml] > > > smtpserver-ssl > 0.0.0.0:465 > > file://conf/private.key > file://conf/certs.self-signed.csr > > > true|false > > true|false > > file://conf/imapJWT.pub > > https://example.com/.well-known/openid-config > > mailAddress > > > > > > You can see that: > - The `plainAuthDissallowed` parameter is proposed to be renamed to > `auth.requireSSL`. (of course we should support fallback NOT to have a > breaking change) > - `auth.plainAuthEnabled` enable turning on/off plain auth, which > allows having OIDC only mechanism. > - `auth.requireSSL` will be generalized to SMTP. > - In SMTP `requireAuth` setting is very misleading as it rather is > `requireAuthForRelay`. I propose we rename this configuration option (of > course we should support fallback NOT to have a breaking change). > > Here is the implementation strategies we would follow: > > - For JMAP have Krakend doing all the hard job for us, and use a > dedicated header to carry the information over to James. >- Our code contributions aims at easing such a setup (that would only > require configuration) >- Provide an informative example using krakend. We understand that > this choice is ours, yet sharing it could allow reuse or similar setup >- If some people wishes to write an OIDC authentication strategy > directly in James then they perfectly can! (Reusing the modularization > of JMAP authentication strategies we would provide). > > - For IMAP and SMTP then we proposes to check the bearer payload > against a statically configured public key for these protocols. (Sadly > there is no API gateway for those protocols) >- Drawbacks includes no revocation of access tokens (once it's signed > it is always valid), revocation do not shut down existing connections > authenticated with the revocated token, and key rotation would require > reconfiguration and reboot. >- One alternative would be to systematically ask the OpenID server to > validate the bearer. T
[BUILD-FAILURE]: Job 'james/ApacheJames/master [master] [368]'
BUILD-FAILURE: Job 'james/ApacheJames/master [master] [368]': Check console output at "https://ci-builds.apache.org/job/james/job/ApacheJames/job/master/368/";>james/ApacheJames/master [master] [368]" - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
