Re: [gentoo-user] 'Heartbleed' bug
What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins. adam@proxy ~ $ ldd /usr/sbin/sshd linux-vdso.so.1 (0x7fffb068e000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f68db1e6000) libpam.so.0 = /lib64/libpam.so.0 (0x7f68dafd8000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f68dabf5000) libutil.so.1 = /lib64/libutil.so.1 (0x7f68da9f2000) libz.so.1 = /lib64/libz.so.1 (0x7f68da7db000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f68da5a4000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68da387000) libc.so.6 = /lib64/libc.so.6 (0x7f68d9fd7000) libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x7f68d9dc) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d9bbc000) /lib64/ld-linux-x86-64.so.2 (0x7f68db3f1000) adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0 dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0) adam@proxy ~ $ So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after upgrading OpenSSL.
Re: [gentoo-user] Gentoo Snort handbook is out of date
On Wednesday 09 Apr 2014 09:49:40 I wrote: On Tuesday 08 Apr 2014 18:25:34 Tom Wijsman wrote: On Tue, 08 Apr 2014 15:25:31 +0100 Peter Humphrey pe...@prh.myzen.co.uk wrote: I just wanted to save some time and confusion for anyone wanting to dip a toe into the muddy snort waters. You can file a bug to have the page update or be marked as outdated. Done. https://bugs.gentoo.org/show_bug.cgi?id=507220 Now fixed and the amended doc is on-line. -- Regards Peter
Re: [gentoo-user] 'Heartbleed' bug
On 04/10/2014 05:03 PM, Adam Carter wrote: What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins. adam@proxy ~ $ ldd /usr/sbin/sshd linux-vdso.so.1 (0x7fffb068e000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f68db1e6000) libpam.so.0 = /lib64/libpam.so.0 (0x7f68dafd8000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f68dabf5000) libutil.so.1 = /lib64/libutil.so.1 (0x7f68da9f2000) libz.so.1 = /lib64/libz.so.1 (0x7f68da7db000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f68da5a4000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68da387000) libc.so.6 = /lib64/libc.so.6 (0x7f68d9fd7000) libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x7f68d9dc) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d9bbc000) /lib64/ld-linux-x86-64.so.2 (0x7f68db3f1000) adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0 dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0) adam@proxy ~ $ So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after upgrading OpenSSL. As far as I know, it doesn't use it for the communication itself, just some key generations, so it shouldn't be affected by this bug. But I guess better safe than sorry...
Re: [gentoo-user] 'Heartbleed' bug
Am Wed, 9 Apr 2014 18:06:35 -0600 schrieb Joseph syscon...@gmail.com: Is gentoo effected by this new 'Heartbleed' bug? The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library http://heartbleed.com/ Just FYI: security issues such as this get announced on the gentoo-announce ML (heartbleed was announced on the 8th of April). -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup signature.asc Description: PGP signature
Re: [gentoo-user] 'Heartbleed' bug
On Thu, Apr 10, 2014 at 05:53:44PM +0800, J?n Zahornadsk? wrote: On 04/10/2014 05:03 PM, Adam Carter wrote: What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins. adam@proxy ~ $ ldd /usr/sbin/sshd linux-vdso.so.1 (0x7fffb068e000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f68db1e6000) libpam.so.0 = /lib64/libpam.so.0 (0x7f68dafd8000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f68dabf5000) libutil.so.1 = /lib64/libutil.so.1 (0x7f68da9f2000) libz.so.1 = /lib64/libz.so.1 (0x7f68da7db000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f68da5a4000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68da387000) libc.so.6 = /lib64/libc.so.6 (0x7f68d9fd7000) libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x7f68d9dc) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d9bbc000) /lib64/ld-linux-x86-64.so.2 (0x7f68db3f1000) adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0 dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0) adam@proxy ~ $ So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after upgrading OpenSSL. As far as I know, it doesn't use it for the communication itself, just some key generations, so it shouldn't be affected by this bug. But I guess better safe than sorry... Right. heartbleed does not directly affect openssh, but openssh uses openssl and it's good practice to keep the shared libraries on-disk and the shared libraries in-memory in sync.
Re: [gentoo-user] 'Heartbleed' bug
On Thu, Apr 10, 2014 at 4:22 PM, Matthew Finkel matthew.fin...@gmail.com wrote: On Thu, Apr 10, 2014 at 05:53:44PM +0800, J?n Zahornadsk? wrote: On 04/10/2014 05:03 PM, Adam Carter wrote: What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins. adam@proxy ~ $ ldd /usr/sbin/sshd linux-vdso.so.1 (0x7fffb068e000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f68db1e6000) libpam.so.0 = /lib64/libpam.so.0 (0x7f68dafd8000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f68dabf5000) libutil.so.1 = /lib64/libutil.so.1 (0x7f68da9f2000) libz.so.1 = /lib64/libz.so.1 (0x7f68da7db000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f68da5a4000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68da387000) libc.so.6 = /lib64/libc.so.6 (0x7f68d9fd7000) libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x7f68d9dc) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d9bbc000) /lib64/ld-linux-x86-64.so.2 (0x7f68db3f1000) adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0 dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0) adam@proxy ~ $ So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after upgrading OpenSSL. As far as I know, it doesn't use it for the communication itself, just some key generations, so it shouldn't be affected by this bug. But I guess better safe than sorry... Right. heartbleed does not directly affect openssh, but openssh uses openssl and it's good practice to keep the shared libraries on-disk and the shared libraries in-memory in sync. How is OpenSSH not affected?
Re: [gentoo-user] 'Heartbleed' bug
The Heartbleed bug is in the Heartbeat function of TSL (a second keep alive). OpenSSL does not use TLS for transport security, it uses its own Protokoll for security. 2014-04-10 12:51 GMT+02:00 Nilesh Govindrajan m...@nileshgr.com: On Thu, Apr 10, 2014 at 4:22 PM, Matthew Finkel matthew.fin...@gmail.com wrote: On Thu, Apr 10, 2014 at 05:53:44PM +0800, J?n Zahornadsk? wrote: On 04/10/2014 05:03 PM, Adam Carter wrote: What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins. adam@proxy ~ $ ldd /usr/sbin/sshd linux-vdso.so.1 (0x7fffb068e000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f68db1e6000) libpam.so.0 = /lib64/libpam.so.0 (0x7f68dafd8000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f68dabf5000) libutil.so.1 = /lib64/libutil.so.1 (0x7f68da9f2000) libz.so.1 = /lib64/libz.so.1 (0x7f68da7db000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f68da5a4000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68da387000) libc.so.6 = /lib64/libc.so.6 (0x7f68d9fd7000) libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x7f68d9dc) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d9bbc000) /lib64/ld-linux-x86-64.so.2 (0x7f68db3f1000) adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0 dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0) adam@proxy ~ $ So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after upgrading OpenSSL. As far as I know, it doesn't use it for the communication itself, just some key generations, so it shouldn't be affected by this bug. But I guess better safe than sorry... Right. heartbleed does not directly affect openssh, but openssh uses openssl and it's good practice to keep the shared libraries on-disk and the shared libraries in-memory in sync. How is OpenSSH not affected? -- Mit freundlichen Grüßen / Best regards Randolph Maaßen
Re: [gentoo-user] 'Heartbleed' bug
Exactly, OpenSSH depends on OpenSSL, but should never use the buggy code. Some details in the answer here: http://superuser.com/questions/739349/does-heartbleed-affect-ssh-keys On 04/10/2014 07:00 PM, Randolph Maaßen wrote: The Heartbleed bug is in the Heartbeat function of TSL (a second keep alive). OpenSSL does not use TLS for transport security, it uses its own Protokoll for security. 2014-04-10 12:51 GMT+02:00 Nilesh Govindrajan m...@nileshgr.com: On Thu, Apr 10, 2014 at 4:22 PM, Matthew Finkel matthew.fin...@gmail.com wrote: On Thu, Apr 10, 2014 at 05:53:44PM +0800, J?n Zahornadsk? wrote: On 04/10/2014 05:03 PM, Adam Carter wrote: What surprises me here is OpenSSH. It's not supposed to use OpenSSL but Debian update process suggests to restart it after updating OpenSSL to a fixed version. Is it an overkill on their part? It might confuse admins. adam@proxy ~ $ ldd /usr/sbin/sshd linux-vdso.so.1 (0x7fffb068e000) libwrap.so.0 = /lib64/libwrap.so.0 (0x7f68db1e6000) libpam.so.0 = /lib64/libpam.so.0 (0x7f68dafd8000) libcrypto.so.1.0.0 = /usr/lib64/libcrypto.so.1.0.0 (0x7f68dabf5000) libutil.so.1 = /lib64/libutil.so.1 (0x7f68da9f2000) libz.so.1 = /lib64/libz.so.1 (0x7f68da7db000) libcrypt.so.1 = /lib64/libcrypt.so.1 (0x7f68da5a4000) libpthread.so.0 = /lib64/libpthread.so.0 (0x7f68da387000) libc.so.6 = /lib64/libc.so.6 (0x7f68d9fd7000) libgcc_s.so.1 = /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x7f68d9dc) libdl.so.2 = /lib64/libdl.so.2 (0x7f68d9bbc000) /lib64/ld-linux-x86-64.so.2 (0x7f68db3f1000) adam@proxy ~ $ qfile /usr/lib64/libcrypto.so.1.0.0 dev-libs/openssl (/usr/lib64/libcrypto.so.1.0.0) adam@proxy ~ $ So OpenSSH clearly IS using OpenSSL, and you need to restart sshd after upgrading OpenSSL. As far as I know, it doesn't use it for the communication itself, just some key generations, so it shouldn't be affected by this bug. But I guess better safe than sorry... Right. heartbleed does not directly affect openssh, but openssh uses openssl and it's good practice to keep the shared libraries on-disk and the shared libraries in-memory in sync. How is OpenSSH not affected?
Re: [gentoo-user] 'Heartbleed' bug
On Thu, 10 Apr 2014 10:52:21 +, Matthew Finkel wrote: Right. heartbleed does not directly affect openssh, but openssh uses openssl and it's good practice to keep the shared libraries on-disk and the shared libraries in-memory in sync. The easiest way to do that is with app-admin/checkrestart. -- Neil Bothwick Invertebrates make no bones about it. signature.asc Description: PGP signature
[gentoo-user] emerge ---p --depclean - check me...
Hi all, I rarely do this (I know, I should do it periodically at least), so I'd like someone to check these... These are the packages that would be unmerged: dev-python/python-exec selected: 1.1 1.2 protected: none omitted: none perl-core/ExtUtils-Command selected: 1.170.0 protected: none omitted: none perl-core/JSON-PP selected: 2.272.0 protected: none omitted: none perl-core/MIME-Base64 selected: 3.130.0 protected: none omitted: none perl-core/Perl-OSType selected: 1.2.0 protected: none omitted: none perl-core/Test-Simple selected: 0.980.0 protected: none omitted: none perl-core/Time-HiRes selected: 1.972.500 protected: none omitted: none perl-core/digest-base selected: 1.170.0 protected: none omitted: none sys-apps/pciutils selected: 3.2.0 protected: none omitted: none sys-devel/automake selected: 1.12.6 protected: none omitted: 1.11.6 1.13.4 sys-devel/libperl selected: 5.10.1 protected: none omitted: none sys-libs/gpm selected: 1.20.6 protected: none omitted: none virtual/init selected: 0 protected: none omitted: none Any obvious problems here? Thanks, Charles
Re: [gentoo-user] emerge ---p --depclean - check me...
On Apr 10, 2014 4:48 PM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, I rarely do this (I know, I should do it periodically at least), so I'd like someone to check these... These are the packages that would be unmerged: dev-python/python-exec selected: 1.1 1.2 protected: none omitted: none perl-core/ExtUtils-Command selected: 1.170.0 protected: none omitted: none perl-core/JSON-PP selected: 2.272.0 protected: none omitted: none perl-core/MIME-Base64 selected: 3.130.0 protected: none omitted: none perl-core/Perl-OSType selected: 1.2.0 protected: none omitted: none perl-core/Test-Simple selected: 0.980.0 protected: none omitted: none perl-core/Time-HiRes selected: 1.972.500 protected: none omitted: none perl-core/digest-base selected: 1.170.0 protected: none omitted: none sys-apps/pciutils selected: 3.2.0 protected: none omitted: none sys-devel/automake selected: 1.12.6 protected: none omitted: 1.11.6 1.13.4 sys-devel/libperl selected: 5.10.1 protected: none omitted: none sys-libs/gpm selected: 1.20.6 protected: none omitted: none virtual/init selected: 0 protected: none omitted: none Any obvious problems here? Thanks, Charles seems alright except virtual/init
Re: [gentoo-user] emerge ---p --depclean - check me...
On 10/04/2014 13:16, Tanstaafl wrote: Hi all, I rarely do this (I know, I should do it periodically at least), so I'd like someone to check these... These are the packages that would be unmerged: dev-python/python-exec selected: 1.1 1.2 protected: none omitted: none perl-core/ExtUtils-Command selected: 1.170.0 protected: none omitted: none perl-core/JSON-PP selected: 2.272.0 protected: none omitted: none perl-core/MIME-Base64 selected: 3.130.0 protected: none omitted: none perl-core/Perl-OSType selected: 1.2.0 protected: none omitted: none perl-core/Test-Simple selected: 0.980.0 protected: none omitted: none perl-core/Time-HiRes selected: 1.972.500 protected: none omitted: none perl-core/digest-base selected: 1.170.0 protected: none omitted: none sys-apps/pciutils selected: 3.2.0 protected: none omitted: none sys-devel/automake selected: 1.12.6 protected: none omitted: 1.11.6 1.13.4 sys-devel/libperl selected: 5.10.1 protected: none omitted: none sys-libs/gpm selected: 1.20.6 protected: none omitted: none virtual/init selected: 0 protected: none omitted: none Any obvious problems here? Thanks, Charles Nope, no problems there. A lot of ebuild shuffling has been going on with perl of late - modules moving in and out of core with virtuals coming and going. Let depclean do what it wants, then emerge -avuND world again just in case of the highly unlikely event something got nuked that shouldn't have. Everything else in that list is routine except maybe pciutils and gpm. Add them to world manually if you use those apps -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] emerge ---p --depclean - check me...
On Thu, 10 Apr 2014 16:51:39 +0530 Nilesh Govindrajan m...@nileshgr.com wrote: seems alright except virtual/init That is a virtual that is no longer used, it is thus safe to remove. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
Re: [gentoo-user] emerge ---p --depclean - check me...
On 4/10/2014 7:21 AM, Alan McKinnon alan.mckin...@gmail.com wrote: Everything else in that list is routine except maybe pciutils and gpm. Add them to world manually if you use those apps Thanks Alan/Tom... Hmmm... what is pciutils used for? From a little googling, it seems like it is a tool that I would manually have to use, not something required by the system itself for anything that happens automatically (ie, at boot time)? If so, I've never used it that I can recall, so I guess I can let depclean remove it? As for gpm... this is the 'general purpose mouse server'? If so, guess I don't need this either, since this is a VM without a gui? Thanks again, charles
Re: [gentoo-user] emerge ---p --depclean - check me...
On Thu, Apr 10, 2014 at 9:26 AM, Tanstaafl tansta...@libertytrek.org wrote: Hmmm... what is pciutils used for? From a little googling, it seems like it is a tool that I would manually have to use, not something required by the system itself for anything that happens automatically (ie, at boot time)? It provides the lspci utility, which is handy when you are trying to figure out what drivers to enable in your kernel. If so, I've never used it that I can recall, so I guess I can let depclean remove it? Yes. As for gpm... this is the 'general purpose mouse server'? If so, guess I don't need this either, since this is a VM without a gui? gpm allows you to use a mouse to copy/paste from the Linux text console. You need to start the daemon for that to work. It's not needed.
Re: [gentoo-user] emerge ---p --depclean - check me...
On 10/04/2014 15:26, Tanstaafl wrote: On 4/10/2014 7:21 AM, Alan McKinnon alan.mckin...@gmail.com wrote: Everything else in that list is routine except maybe pciutils and gpm. Add them to world manually if you use those apps Thanks Alan/Tom... Hmmm... what is pciutils used for? From a little googling, it seems like it is a tool that I would manually have to use, not something required by the system itself for anything that happens automatically (ie, at boot time)? pciutils provides lspci, I'm sure you've used that one lots :-) I'm assuming it was in the @system set since forever and has now been taken out - it's hugely useful but not 100% required to get a working Gentoo install so therefore doesn't really belong in @system I myself have a personal @tools set that I've used since forever and pciutils is in it so I always have lspci on every gentoo box. Hence why I have to assume what took place recently in the tree If so, I've never used it that I can recall, so I guess I can let depclean remove it? As for gpm... this is the 'general purpose mouse server'? If so, guess I don't need this either, since this is a VM without a gui? gpm lets you use your mouse in the console just like you use it in X. The pointer isn't an arrow, it's a flashing block cursor but you can highlight, copy and paste text just like in X. Useful if you've gotten to like it, completely redundant if you never used it and get along fine without it Thanks again, charles -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] What MTA to use to receiving mail for local users?
I use msmtp for outgoing mail, and plan to continue to do so. However, I need to temporarily set up an SMTP server to accept incoming mail from the Internet for local users. It is not going to handle sending of email, and I need it _not_ to install something as /usr/bin/sendmail (that's already taken by msmtp). It doesn't need to handle queueing, relaying, or anything other than acting as an SMTP server and delivering mail locally to mbox or maildir destinations. What's the easiest/simplest MTA to set up for that? sendmail? (No... just no.) qmail? (Seems a bit overly complex for my use case). postfix? exim? It's been a long time since I've used either postfix or exim, but I don't remember either of them being too complex to configure. I'm guessing that Portgage is going to object to installing both msmtp and postfix/exim, so I'll probably have to build the rx-only MTA from sources and install it in a non-standard location? Maybe I should just write a simple SMTP server in Python. [That's actually a lot easier than it sounds. Python's standard library has an smtpd class that's pretty simple to use.] -- Grant Edwards grant.b.edwardsYow! Remember, in 2039, at MOUSSE PASTA will gmail.combe available ONLY by prescription!!
Re: [gentoo-user] What MTA to use to receiving mail for local users?
Am 10.04.2014 17:32, schrieb Grant Edwards: I use msmtp for outgoing mail, and plan to continue to do so. However, I need to temporarily set up an SMTP server to accept incoming mail from the Internet for local users. It is not going to handle sending of email, and I need it _not_ to install something as /usr/bin/sendmail (that's already taken by msmtp). It doesn't need to handle queueing, relaying, or anything other than acting as an SMTP server and delivering mail locally to mbox or maildir destinations. What's the easiest/simplest MTA to set up for that? sendmail? (No... just no.) qmail? (Seems a bit overly complex for my use case). postfix? exim? It's been a long time since I've used either postfix or exim, but I don't remember either of them being too complex to configure. I'm guessing that Portgage is going to object to installing both msmtp and postfix/exim, so I'll probably have to build the rx-only MTA from sources and install it in a non-standard location? Maybe I should just write a simple SMTP server in Python. [That's actually a lot easier than it sounds. Python's standard library has an smtpd class that's pretty simple to use.] well, IMHO postfix is pretty easy to setup up. While sendmail is a complete nightmare. Eximqmail - never touched those.
Re: [gentoo-user] What MTA to use to receiving mail for local users?
On Thursday 10 Apr 2014 17:41:05 Volker Armin Hemmann wrote: well, IMHO postfix is pretty easy to setup up. While sendmail is a complete nightmare. I've just about got it set up here, so it can't be too hard. Eximqmail - never touched those. Are they even still maintained? -- Regards Peter
[gentoo-user] Re: What MTA to use to receiving mail for local users?
On 2014-04-10, Peter Humphrey pe...@prh.myzen.co.uk wrote: On Thursday 10 Apr 2014 17:41:05 Volker Armin Hemmann wrote: well, IMHO postfix is pretty easy to setup up. While sendmail is a complete nightmare. I've just about got it set up here, so it can't be too hard. Eximqmail - never touched those. Are they even still maintained? According to http://bugs.exim.org, bugs were still being resolved 9 days ago (though the most recent bug _fix_ was 5 weeks ago). qmail hasn't been touched since 2007, so it seems to be abandoned. -- Grant Edwards grant.b.edwardsYow! Nipples, dimples, at knuckles, NICKLES, gmail.comwrinkles, pimples!!
Re: [gentoo-user] Re: What MTA to use to receiving mail for local users?
Grant Edwards: On 2014-04-10, Peter Humphrey pe...@prh.myzen.co.uk wrote: On Thursday 10 Apr 2014 17:41:05 Volker Armin Hemmann wrote: well, IMHO postfix is pretty easy to setup up. While sendmail is a complete nightmare. I've just about got it set up here, so it can't be too hard. Eximqmail - never touched those. Are they even still maintained? According to http://bugs.exim.org, bugs were still being resolved 9 days ago (though the most recent bug _fix_ was 5 weeks ago). qmail hasn't been touched since 2007, so it seems to be abandoned. good to know it's still in stable arch... ugh
Re: [gentoo-user] Re: What MTA to use to receiving mail for local users?
On Thu, Apr 10, 2014 at 08:09:48PM +, Grant Edwards wrote: qmail hasn't been touched since 2007, so it seems to be abandoned. That's somewhat of an exaggeration. qmail has been public domain since 2007, and its core hadn't been touched for about a decade before that. Due to the way the project was shepherded, the normal way it developed was by circulating patches, and that's still the way things are. There's an active mailing list for qmail at qm...@list.cr.yp.to. I think the software is still being developed, but I couldn't cite the site. Certainly, qmail is still in use. I like it. -- Grant Edwards grant.b.edwardsYow! Nipples, dimples, at knuckles, NICKLES, gmail.comwrinkles, pimples!! -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] What MTA to use to receiving mail for local users?
On 10/04/2014 17:41, Volker Armin Hemmann wrote: Am 10.04.2014 17:32, schrieb Grant Edwards: I use msmtp for outgoing mail, and plan to continue to do so. However, I need to temporarily set up an SMTP server to accept incoming mail from the Internet for local users. It is not going to handle sending of email, and I need it _not_ to install something as /usr/bin/sendmail (that's already taken by msmtp). It doesn't need to handle queueing, relaying, or anything other than acting as an SMTP server and delivering mail locally to mbox or maildir destinations. What's the easiest/simplest MTA to set up for that? sendmail? (No... just no.) qmail? (Seems a bit overly complex for my use case). postfix? exim? It's been a long time since I've used either postfix or exim, but I don't remember either of them being too complex to configure. I'm guessing that Portgage is going to object to installing both msmtp and postfix/exim, so I'll probably have to build the rx-only MTA from sources and install it in a non-standard location? Maybe I should just write a simple SMTP server in Python. [That's actually a lot easier than it sounds. Python's standard library has an smtpd class that's pretty simple to use.] well, IMHO postfix is pretty easy to setup up. While sendmail is a complete nightmare. Agreed. Postfix is about as simple as defining MYDESTINATION and you are good to go Eximqmail - never touched those. isn't qmail abandonware? Either that or Dan considers is 100% bug free and not in need of maintenance.Plus it has that horrible license. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] What MTA to use to receiving mail for local users?
I would say postfix for sure. On 10 April 2014 16:52, Alan McKinnon alan.mckin...@gmail.com wrote: On 10/04/2014 17:41, Volker Armin Hemmann wrote: Am 10.04.2014 17:32, schrieb Grant Edwards: I use msmtp for outgoing mail, and plan to continue to do so. However, I need to temporarily set up an SMTP server to accept incoming mail from the Internet for local users. It is not going to handle sending of email, and I need it _not_ to install something as /usr/bin/sendmail (that's already taken by msmtp). It doesn't need to handle queueing, relaying, or anything other than acting as an SMTP server and delivering mail locally to mbox or maildir destinations. What's the easiest/simplest MTA to set up for that? sendmail? (No... just no.) qmail? (Seems a bit overly complex for my use case). postfix? exim? It's been a long time since I've used either postfix or exim, but I don't remember either of them being too complex to configure. I'm guessing that Portgage is going to object to installing both msmtp and postfix/exim, so I'll probably have to build the rx-only MTA from sources and install it in a non-standard location? Maybe I should just write a simple SMTP server in Python. [That's actually a lot easier than it sounds. Python's standard library has an smtpd class that's pretty simple to use.] well, IMHO postfix is pretty easy to setup up. While sendmail is a complete nightmare. Agreed. Postfix is about as simple as defining MYDESTINATION and you are good to go Eximqmail - never touched those. isn't qmail abandonware? Either that or Dan considers is 100% bug free and not in need of maintenance.Plus it has that horrible license. -- Alan McKinnon alan.mckin...@gmail.com -- Carlos Sura.- www.carlossura.com www.carlossura.com/blog
[gentoo-user] Re: 'Heartbleed' bug
On 04/09/2014 05:06 PM, Joseph wrote: Is gentoo effected by this new 'Heartbleed' bug? The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library http://heartbleed.com/ This topic was discussed in my favorite podcast, http://twit.tv/sn Steve Gibson explained that the heartbeat feature was introduced in openssl to allow *UDP* connections to mimic the 'keepalive' function of the TCP protocol. IIRC Steve didn't explain how UDP bugs can compromise TCP connections. Anyone here really understand the underlying principles? If so, please explain! Thanks.
Re: [gentoo-user] Re: 'Heartbleed' bug
On 11/04/2014 00:55, walt wrote: On 04/09/2014 05:06 PM, Joseph wrote: Is gentoo effected by this new 'Heartbleed' bug? The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library http://heartbleed.com/ This topic was discussed in my favorite podcast, http://twit.tv/sn Steve Gibson explained that the heartbeat feature was introduced in openssl to allow *UDP* connections to mimic the 'keepalive' function of the TCP protocol. IIRC Steve didn't explain how UDP bugs can compromise TCP connections. Anyone here really understand the underlying principles? If so, please explain! Thanks. UDP is not compromising TCP connections. The software bug allows malicious connecting code to determine the contents of memory, which is in use by sshd. How that memory got to be there is irrelevant. There are many lengthy discussions on the internet on how this vuln works. You should read them. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: 'Heartbleed' bug
On Thu, Apr 10, 2014 at 03:55:47PM -0700, walt wrote: On 04/09/2014 05:06 PM, Joseph wrote: Is gentoo effected by this new 'Heartbleed' bug? The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library http://heartbleed.com/ This topic was discussed in my favorite podcast, http://twit.tv/sn Steve Gibson explained that the heartbeat feature was introduced in openssl to allow *UDP* connections to mimic the 'keepalive' function of the TCP protocol. IIRC Steve didn't explain how UDP bugs can compromise TCP connections. Anyone here really understand the underlying principles? If so, please explain! Thanks. Yes, but no, actually. It's main use is in DTLS, over UDP and similar protocols, however it is also supported in TLS (over TCP). From the RFC [0]: DTLS is designed to secure traffic running on top of unreliable transport protocols. Usually, such protocols have no session management. The only mechanism available at the DTLS layer to figure out if a peer is still alive is a costly renegotiation, particularly when the application uses unidirectional traffic[...] TLS is based on reliable protocols, but there is not necessarily a feature available to keep the connection alive without continuous data transfer. The Heartbeat Extension as described in this document overcomes these limitations. So the heartbeat in [D]TLS, as implemented in OpenSSL, is standard-compliant. It's more useful in datagram communication (i.e. UDP, connectionless) but it is available for connection-oriented protocols (i.e. TCP), as well. It was the TLS heartbeat-implementation that suffered from this vulnerability. You can see the patch-fix here[1], if you're interested. [0] https://tools.ietf.org/html/rfc6520 [1] https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=96db9023b881d7cd9f379b0c154650d6c108e9a3
Re: [gentoo-user] Re: 'Heartbleed' bug
On 4/10/2014 6:59 PM, Alan McKinnon wrote: Steve Gibson explained that the heartbeat feature was introduced in openssl to allow *UDP* connections to mimic the 'keepalive' function of the TCP protocol. IIRC Steve didn't explain how UDP bugs can compromise TCP connections. Anyone here really understand the underlying principles? If so, please explain! Thanks. UDP is not compromising TCP connections. The software bug allows malicious connecting code to determine the contents of memory, which is in use by sshd. How that memory got to be there is irrelevant. There are many lengthy discussions on the internet on how this vuln works. You should read them. While there may be many OpenSSL experts on this list, I believe that the BEST source of information on this bug, how it works, what it does, and so forth would be the OpenSSL mailing lists. The official Heartbleed web page has some information on it that is a good beginning for researching this bug, the the lists I mentioned above are probably the best source of information, after you understand the basics from the web page. Chris Walters
Re: [gentoo-user] Re: 'Heartbleed' bug
Hi, On 04/11/2014 12:55 AM, walt wrote: Steve Gibson explained that the heartbeat feature was introduced in openssl to allow *UDP* connections to mimic the 'keepalive' function of the TCP protocol. IIRC Steve didn't explain how UDP bugs can compromise TCP connections. Anyone here really understand the underlying principles? If so, please explain! yes, a TCP connection is stateful, so imho heartbeat is not necessary. But you don't always speak UDP or TCP. Imagine some sort of direct connection without any type of transportation layer. As a generic cryptographic library, OpenSSL is designed to be adaptable and universal. That broke OpenSSL's neck. We only can hope, that the heartbeat exploit was not widely used before they published that zero-day. But we can be sure, that this is not going to be the last vulnerability of this kind. Regards Ralf
