net-libs/c-client fails to connect to servers (or accept connection from) which require TLS version > 1.0 Reproducible: Always Steps to Reproduce: 1. net-misc/asterisk with imap voicemail storage fails to connect to dovecot 2.3.18 imap server because dovecot's default setting is ssl_min_protocol = TLSv1.2 now. 2. 3. net-libs/c-client-2007f patch attached.
Created attachment 767820 [details, diff] patch
Happy to onboard this, but I don't use this myself. A few notes however: 1. net-libs/c-client is the only provider for virtual/imap-c-client 2. HOMEPAGE no longer seems correct. 3. SRC_URI points to non-existent server. Are there alternatives out there that is up to date? asterisk has two alternative include paths for imap/* vs c-client/* or simply with no leading path, the problem is I suspect they're just different locations for the same headers. Looks like this package comes from 2007! If asterisk still depends on this, and upstream is completely gone (which it looks like), that's a highly problematic situation. In the meantime I think we need to: 1. Ensure that we don't lose this from the mirrors. 2. Apply the patch. @Sam - is there a sensible way to mark HOMEPAGE and SRC_URI as "dead upstream", or do I put a copy of these files on my infrastructure nad point SRC_URI there (ideally with some page somewhere)? Alterantively I can put this last copy on github, import patches there and tag a new version? But what I know of IMAP internals is scary to say the least, definitely not the right person for working on the code (not to mention time is a luxury of which I have too little at the moment).
Asterisk is not the only c-client consumer. PHP wants it too to build imap extension.
Sergey, I missed that one. This isn't high priority for me personally.
Sorry, bad UI, just wanted to select Petr's email address for adding as CC. Petr, I note you submitted the patches for fixing the clang issues. Do you have other interest in this package? It looks like there is no working upstream, my own use for this is as a dependency for asterisk, for a function I don't use myself (Thus the low priority). I know lots of changes has happened in OpenSSL over the last few years. My questions are: Do we sensibly have any choice but to fork this? I don't mind this living on my github, but I believe it's probably better to put this under the gentoo profile rather if we do end up doing this. What are other PHP distributions doing about this? Simply not installing the imap library, or just ignoring the fact that TLS servers are a problem here?
(In reply to Jaco Kroon from comment #5) > Petr, I note you submitted the patches for fixing the clang issues. Do you > have other interest in this package? It looks like there is no working > upstream, my own use for this is as a dependency for asterisk, for a > function I don't use myself (Thus the low priority). No, I don't have any interest in this package, I only wanted to fix the clang issue. Btw, Archlinux for example uses this https://github.com/uw-imap/imap instead but it does not seem to be active. Gentoo used to have net-mail/uw-imap package which was removed 3 years ago, I am not sure how it differed from net-libs/c-client, they look pretty same to me. I find bug 678606, comment 8 interesting, maybe it would make sense to switch and use bundled (but somehow maintained) version from mail-client/alpine.
upstream dead? asterisk at least seems to have an embedded c-client I can switch to, but I don't feel like that's the right solution. Has PHP perhaps dealt with this yet somehow?
