similar to: Server shutting down

Appears some change between 2.2.6 and 2.2.7 altered the response codes for LMTP user verification probes. Dovecot 2.2.6: Nov 2 15:50:48 spectre postfix/qmgr[627]: 3dBjr80wMgz1s: from=<double-bounce at spectre.leuxner.net>, size=271, nrcpt=1 (queue active) Nov 2 15:50:48 spectre postfix/cleanup[6226]: 3dBjr80xbYz1w: message-id=<20131102145047.2D3C6824147 at sam.dfn-cert.de> Nov 2

Since updating to the latest HG these errors occur. Nothing else changed in the config: $ dovecot --version 2.2.beta1 (62a930eb22b5) ==> /var/log/dovecot/dovecot.log <== Feb 18 09:47:32 spectre dovecot: lmtp(14340): Connect from local Feb 18 09:47:32 spectre dovecot: lmtp(14340, tlx at leuxner.net): Error: mkdir_parents(/var/vmail/domains/leuxner.net/tlx/mdbox) failed: File exists Feb 18

Hi, converted my personal mailbox from 'maildir' to 'mdbox' for testing today: # dsync convert -u user at domain mdbox:~/mdbox Set mail location to mdbox in 'mail.conf' and restarted server: mail_location = mdbox:~/mdbox Dovecot panicked instantly upon login with different clients. Tried to disable several plugins to no avail: Feb 28 14:43:02 spectre dovecot:

On 6 February 2018 at 20:09, David Newall <openssh at davidnewall.com> wrote: > Do we need to do anything? It's not clear to me how SSH is vulnerable to > Spectre -- that is, how SSH can be used to execute a Spectre attack? I am more concerned with it being the target of a Spectre style attack. There's some long lived private data (host keys in the case of sshd, session keys

Suppose this one breaks it: http://hg.dovecot.org/dovecot-2.2/rev/c4a85c9df948 ==> /var/log/mail.log <== Jun 1 14:01:30 spectre postfix/lmtp[456]: 3bN0qP5kwFzSy: to=<tlx at leuxner.net>, relay=spectre.leuxner.net[private/dovecot-lmtp], delay=1481, delays=1481/0/0.01/0.01, dsn=4.3.0, status=deferred (host spectre.leuxner.net[private/dovecot-lmtp] said: 451 4.3.0 <tlx at

Hi, We don't normally do X.Y.2 releases, but there has been some interest in getting a 5.0.2 release out with the Spectre mitigations included, so I am proposing the following schedule for a 5.0.2 release: LLVM 5.0.2 -rc1 Mon Mar 19 -final Mon Mar 26 To keep things easy for testers, 5.0.2 will be for Spectre related fixes only and won't be opened up for general bugs. And here is

Hi Johnny, Thank you for your reply. It seems to me that my message may have came around as offensive but that was not my intend. I have basic understanding how things work and when I said CentOS I actually meant Red Hat and all its derivatives. I asked CentOS community because that's the community I'm member of. Not to say that CentOS is not secure or anything like that. Anyway,

Hi. Both GCC and clang are adding mitigations for Spectre variant 2 although neither have yet made a release and neither are on by default. After trolling through and building release candidate branches for both I believe this is what is required for the ssh programs (although all the dependent libraries will also need to be built with mitigations, and I suspect libcrypto is a more likely

Let me say this is a rather cosmetic issue, but it appears with the latest commits (around 2.2.5 release) the scheme of 'Received' headers has changed for LMTP: 1) Inet socket: Return-Path: <dfn-adv-bounces at dfn-cert.de> Delivered-To: <tlx at leuxner.net> Received: from spectre.leuxner.net ([188.138.0.199]) by spectre.leuxner.net (Dovecot) with LMTP id

Hi all! I'm running an up-to-date Centos-7 on an AMD Vishera 6300, 6 core CPU. I note that when I run the redhat script to test for spectre & meltdown I get this result for variant 2: Variant #2 (Spectre): Vulnerable CVE-2017-5715 - speculative execution branch target injection - Kernel with mitigation patches: OK - HW support / updated microcode: NO - IBRS: Not disabled on

I have a clean install, fully updated CentOS 6 32-bit. When I run the Red Hat detection script: https://access.redhat.com/sites/default/files/spectre-meltdown--a79614b.sh it finds that the system is vulnerable. Is this false positive or there is no patches for CentOS 6 32-bit systems? Thank you, -- Peter

By now, we're sure most everyone have heard of the Meltdown and Spectre attacks. If not, head over to https://meltdownattack.com/ and get an overview. Additional technical details are available from Google Project Zero. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The FreeBSD Security Team was notified of the issue in late December and received a

By now, we're sure most everyone have heard of the Meltdown and Spectre attacks. If not, head over to https://meltdownattack.com/ and get an overview. Additional technical details are available from Google Project Zero. https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The FreeBSD Security Team was notified of the issue in late December and received a

Hi, unfortunately no core was dumped. Let me know if you need more info to debug. ==> /var/log/dovecot.log <== Mar 27 08:13:38 spectre dovecot: lmtp(8362): Connect from local Mar 27 08:13:38 spectre dovecot: lmtp(8362): Panic: file settings-parser.c: line 1501 (settings_link_get_new): assertion failed: (diff + sizeof(*old_link->array) <= old_link->parent->info->struct_size)

Hi, latest Mercurial seems to have problems with the Config Module unloads: May 5 19:18:16 spectre dovecot: master: Dovecot v2.0.beta4 (5d76f5b13883) starting up May 5 19:18:34 spectre dovecot: managesieve: Error: fd_read() partial input (54/88) May 5 19:18:34 spectre dovecot: imap-login: Fatal: Error reading configuration: read(/var/run/dovecot/config) failed: EOF May 5 19:18:34 spectre

Patch http://hg.dovecot.org/dovecot-2.1/rev/3d8a25a4394d breaks auth May 5 09:01:52 spectre dovecot: lmtp(24442): Connect from local May 5 09:01:52 spectre dovecot: lmtp(24442): Error: userdb lookup(tlx at leuxner.net): Disconnected unexpectedly May 5 09:01:52 spectre dovecot: auth: Fatal: master: service(auth): child 24443 killed with signal 11 (core not dumped) May 5 09:01:52 spectre

==> /var/log/dovecot/dovecot.log <== Jan 30 19:57:51 spectre dovecot: master: Warning: SIGHUP received - reloading configuration Jan 30 19:58:48 spectre dovecot: imap-login: Login: user=<tlx at leuxner.net>, method=PLAIN, rip=1.2.3.4, lip=5.6.7.8, mpid=15572, TLS, session=<o4WxGYbUsQBeT5Qc> Jan 30 19:58:48 spectre dovecot: imap(tlx at leuxner.netuid=5000): Error: user tlx at

> Look at: > > https://t.co/6fT61xgtGH > > Get the latest microcode.dat file from here: > > https://t.co/zPwagbeJFY > > See how to update the microcode from the links at the bottom of this page: > > https://t.co/EOgclWdHCw > > An before anyone asks .. I have no idea why Red Hat chose this path, > they did. It doesn't matter if I (or anyone else)

Dear All, An update just brought on my CenOS 6 boxes updated microcode.dat files: /lib/firmware/microcode.dat Does anybody know off hand what (how critical) is that, as, if it is related to most famous these days trouble with CPU hardware, I will need to reboot relevant boxes to have new microcode loaded. But if it is not that critical, it can wait till next reboot. Thanks a lot and

Hi, I am very sorry to do this on short notice, but obviously Meltdown and Spectre are a lot more than anyone was really expecting to come down the pipeline. Xen 4.4 has been EOL upstream for about a year now and I have personally been reviewing and backporting patches based on the 4.5 versions made available upstream. Given that 4.5 is now also reaching EOL, backporting to 4.4 will become