On Tue, Jun 28, 2011 at 3:08 AM, Zhang Huangbin
<[log in to unmask]> wrote:
>
> On Jun 28, 2011, at 1:41 PM, Nico Kadel-Garcia wrote:
>
>> On Tue, Jun 28, 2011 at 12:10 AM, Zhang Huangbin
>> <[log in to unmask]> wrote:
>>> Dear Scientific Linux users,
>>>
>>> Just want to let you know, there's a free and open source mail server
>>> solution, iRedMail, works well on Scientific Linux 5.x, supports both
>>> i386 and x86_64. Web site: http://www.iredmail.org/
>>
>> And Postfix.
>>
>> And Sendmail.
>>
>> And Exim.
>>
>> And Qmail.
>>
>> And look,  it's available only as an installer which reaches out and
>> downloads things from your website without actually mentioning what
>> they are in advance. Wow, I could go on with the obvious issues from
>> the website, but given that there's not even a GPG signature for the
>> installation widget, this is actively unsafe.
>
>
> Sorry about unclear description.

That is, perhaps, the *least* of the problems. Downloading unsigned
binary packages from a third-party for a production system like email
services is begging for trouble. All we need is your domain hijacked,
and your clients will be installing rootkits without your or their
awareness.

> iRedMail is just shell scripts, it will install and configure mail server
> related components automatically for you. That's why i call it a 'solution'
> instead of a 'software'. Source code of iRedMail is available in Google
> Code: http://code.google.com/p/iredmail/source/list

And the *source* should be published

> Used major components:
>
> - Postfix (SMTP)
> - Dovecot (POP3, IMAP, Managesieve)
> - Apache (Web server)
> - MySQL (Storing application data and/or mail accounts)
> - OpenLDAP (Storing mail accounts)
> - Amavisd + SpamAssassin + ClamAV (anti-spam, anti-virus)
> - Roundcube (Webmail)
> - Awstats (Apache and Postfix log analyzer)

Good. Now put that on your web page, please.

> Since RHEL doesn't provide all of them, iRedMail project has to provide
> some of them. As we mentioned in README[1] file under yum repository
> directory, most of them comes from third-party repositories, some were
> packed by iRedMail project, SRPMS are avalable:

See above. It should really be in the web page, *long* before setting
up yum repositories.

> ####
> Most packages come from:
>
>    - Dag Wieers: http://packages.sw.be/
>    - EPEL: http://download.fedora.redhat.com/pub/epel/
>    - ATrpms.net: http://atrpms.net/
>
> Thank you all :)
>
> Packages which contains 'ired' tag in package name are packed
> by iRedMail project, you can find source RPM here:
> http://iredmail.org/yum/srpms/
> ####

Which should be..... wait for it...... on the web page. I also note
that the packages there lack GPG signatures.

Worse is your listing for 'License' under your SRPM's. "Public Domain
and BSD" is not a license. It's a legal morass, begging for a client
to step in it and lose a boot. Pick one!!!!!

> iRedMail will verify packages with command 'md5sum'[2] after downloaded
> to make sure they're truly downloaded from iredmail.org.

Which is not the same as a GPG signature. That's merely a transmission
verification, not a sign that the original package actually came from
anyone you trust. The lack of a checksum for the installer tarball is,
in particularly, hazardous, since a malicious person could replace the
contents of *that*.

Security takes attention. This lack of attention to basic security
steps is frightening in a tool that expects to integrate numerous,
password handling components such as jabber, Postfix, Dovecot, and
MySQL.

> [1] README: http://iredmail.org/yum/rpms/5/00README
> [2] Verify packages with 'md5sum': it's defined in some files:
>    o iRedMail-x.y.z/pkgs/get_all.sh
>    o iRedMail-x.y.z/pkgs/MD5.*

And nothing in the srpms or source directories. Defining checksums
inside  the already downloaded installer for 3rd-party downloads is
missing the point, and does nothing to alleviate concerns abou the
authenticity of the package, especially if an RPM is built and
replaced by a malicious third party from their own, unpublished SRPM.
It's very important for security to tie the binary RPM's to the source
RPM's from the same author. This is pretty basic security practice for
software repositories. Can I, or someone else, find you a guideline on
this?

Even if I distruct your product outright due to these missing
features, I'm happy for people to learn how to do these security
practices better.

> ----
> Zhang Huangbin
>
> iRedMail: Open Source Mail Server Solution for Red Hat Enterprise Linux,
> CentOS, Debian, Ubuntu, openSUSE, FreeBSD: http://www.iredmail.org/