+1
Le 03/12/2020 à 09:08, [email protected] (OpenPaaS) a écrit :
Nice to see we are on the same wave length!
Regarding the upgrade path, I'm in favor of requiring an empty mailQueue.
Rationals: if there is any sort of retro-compatibility, then an attacker
controlling ie the JMS solution would still be able to control the
deserialized payload (and trigger all sort of not funny stuff!)
To achieve that, downtime on the SMTP service + MailQueue flush.
Would it be resonable to people around here?
Cheers,
Benoit
Le 03/12/2020 à 14:58, Matthieu Baechler a écrit :
Hi Benoit,
On Thu, 2020-12-03 at 11:54 +0700, Benoit Tellier wrote:
While working on https://issues.apache.org/jira/browse/JAMES-3431 I
discovered that JMS & File mailqueue do still rely on serialization.
This is what motivates to re-open this ticket:
https://issues.apache.org/jira/browse/JAMES-2578
Please kindly note that all of the MailRepository implementation no
longer uses Java serialization.
Our AttributeValue adoption is partial; I would like to finish the
job.
Here are the options we have:
Accept DSN feature do not work on tese implementations (not my
prefered at all!)
Re-implement DSNParameters attribute mapping to not use
collection
attributeValues. This work around the main issue for this specific
use
case of attribute values. (I feel okay with that)
Try to fix collection attributeValue java serialization is likely
hard to do, but also keeps java serialization around for longer in
the
code base. Likely a dead-end.
No longer rely on Java serialization for "JMS" & "File" mail
queues.
This means either smart fallback code, or at worst an upgrade path
with
an empty mail queue. That is by far my preferred option, and I will
start community discussions in that direction.
Do we got consensus around this topic?
This Java serialization compat has been crippling our developpements
for too long. I'm in favor of complete removal and a migration
strategy.
Cheers,
-- Matthieu
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
