similar to: Configuring TLS 1.2

Hi, I tracked down a tricky bug in dovecot that can cause the imap-login and pop3-login processes to crash on handshake failures. This can be tested by disabling SSLv3 in the dovecot config (ssl_protocols = !SSLv2 !SSLv3) and trying to connect with openssl and forced sslv3 (openssl s_client -ssl3 -connect localhost:995). This would cause a crash. What was going on is this: In

On 24/04/2015 22:17, Hanno B?ck wrote: Hello, > I tracked down a tricky bug in dovecot that can cause the imap-login > and pop3-login processes to crash on handshake failures. > This can be tested by disabling SSLv3 in the dovecot config > (ssl_protocols = !SSLv2 !SSLv3) and trying to connect with openssl and > forced sslv3 (openssl s_client -ssl3 -connect localhost:995). This

Hi all, I think I've found a small bug in how Dovecot logs SSL/TLS info. Basically, if I connect to the server using TLS, the logs have a lot of entries saying I used SSLv3 (which is not allowed). Here's my system info: OSX Yosemite (x86_64, HFS+) Dovecot 2.2.15 (via Homebrew) OpenSSL 0.9.8zd The configuration (see below) disallows SSLv3, and if I try and connect with OpenSSL to test

On 04/25/2015 11:55 AM, James wrote: > On 24/04/2015 22:17, Hanno B?ck wrote: > > Hello, > >> I tracked down a tricky bug in dovecot that can cause the imap-login >> and pop3-login processes to crash on handshake failures. >> This can be tested by disabling SSLv3 in the dovecot config >> (ssl_protocols = !SSLv2 !SSLv3) and trying to connect with openssl and

Goos morning all, I compiled Samba 3.0.14a with OpenLDAP 2.1.22-0 directory. I then enabled TLS between Samba and OpenLDAP. The following tests succeeded: s_server to s_client --> OK slapd to s_client --> OK slapd to OPenLDAP client commands (ldapsearch..) --> OK The problem is the following: when I start Samba (service smb start), slapd output returns: TLS trace:

Am 13.11.19 um 17:21 schrieb Ralph Seichter via dovecot: > * Thomas G?ttler via dovecot: > >> Is there a way to access mails in dovecot via https? > > Why on earth would that be beneficial? > > "The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) > allows a client to access and manipulate electronic mail messages > on a server."

Hi llvm-dev We believe we have completed enough of the agreed pre-upstreaming changes to start talking about merging F18 into LLVM. The live status is tracked at [1]. There are a few details that we have not managed to hammer out and we propose to tackle inside the LLVM monorepo. I have put a summary of these at the bottom of this mail. Does anyone have any objections to flang being merged into

Hi Mehdi, I can't replicate those failures at my end, could you let me know what OS, compiler and CMake flags you're using so I can try and reproduce? Thanks! David Truby ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> Sent: 07 April 2020 06:44 To: Richard Barton

Hi, everyone, As you may know, NVIDIA has developed an open-source Fortran frontend for LLVM (http://flang-compiler.org), which consists of the flang frontend itself along with the corresponding Fortran runtime library. The existing frontend's code is mostly written in C, and while a production-quality implementation, does not follow modern software-engineering practices. Our long-standing

Attached is the log. I'm building with: clang version 10.0.0 (https://github.com/llvm/llvm-project/ 3a6da1122b990386edeba0987d0d1fdc9c8dc53d) Target: x86_64-unknown-linux-gnu Thread model: posix On some Ubuntu-like distribution. I also ran with ASAN once and it found a bunch of leaks in bin/tco. Best, -- Mehdi On Tue, Apr 7, 2020 at 4:36 AM Richard Barton <Richard.Barton at

Hi All, The flang project (a Fortran compiler) is getting ready to join the monorepo. We intend to preserve the existing history by rewriting the existing commits as a linear series of commits on top of llvm-project. I understand the flang community would like to do this before the LLVM 10 branch in due in mid January, so please speak up soon if you see anything needing fixing in what I

Hi llvm-dev It's been a few weeks since I last gave an update on F18 and our progress on readying it for inclusion into the monorepo. Last time we discussed this the community challenged us to make the F18 source code look more like an LLVM project and to come up with a plan and schedule for completing this work (http://lists.llvm.org/pipermail/llvm-dev/2020-January/137989.html) The full

Hello, This is regarding recent/ongoing discussions about F18 being merged in LLVM. I was going through these threads, and I found few important points which were possibly left unanswered (or I might have missed few threads). URL: http://lists.llvm.org/pipermail/flang-dev/2019-December/000120.html Point: Is (3) AST -> FIR -> MLIR LLVM-IR -> LLVM-IR) in a shape where we can

Following up on my earlier email. If there is a commitment to checking in f18 already, feel free to disregard it. I went and took a little bit closer look at the sources and want to share some of the findings in case if anyone is interested. Disclosure: I contribute to Fort <http://fort-compiler.org/> (fort-compiler.org), which is the fork of the front-end David Greene mentioned. From

On Mon, Feb 25, 2019 at 5:46 PM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 25, 2019 at 10:06 AM Stephen Scalpone via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> * The current f18 code will be committed to the new LLVM subproject. The >> f18 code is a set of libraries that implements the Fortran compiler. >>

Hi all F18 merging has finished so commit access should be back to normal. Thanks Rich > -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Richard > Barton via llvm-dev > Sent: 9 April, 2020 16:08 > To: llvm-dev at lists.llvm.org > Subject: [llvm-dev] F18 upstreaming Now! > > Hi all > > We are about to merge F18

Hi Eric, Renato Thanks again for the engagement and challenge on this, it is really useful feedback to know what we need to do to get F18 into the project in a way that everyone is happy with. I have tried to give timelines on the points addressed below where I can today. Clearly we need to do some work on points 8-11, but are the above plans/answers to points 1-7 sufficient at this stage and

Can you elaborate on this? - to move the std::string/string_view/StringRef changes to pre-merge unless you're going to have someone dedicated to handling them post-merge (rather than "time permits"). The C vs C++ ism here is fairly strong and I'd like to get the C-style string handling out fairly quickly. I understood this item to be looking into replacing uses of std::string

On Mon, Feb 25, 2019 at 2:45 PM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Feb 25, 2019 at 10:06 AM Stephen Scalpone via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> * The current f18 code will be committed to the new LLVM subproject. The >> f18 code is a set of libraries that implements the Fortran compiler. >>

Hi Eric, Old flang certainly uses C-style strings but f18 uses std::string with few exceptions. Most of the instances in f18 of “char *” aren’t really strings in the C sense – they’re not null terminated and are really just pointers into raw or cooked source files/streams. I can’t think of an instance where the compiler dynamically allocates an array of characters and uses it as a C string. -