This bug seems to only affect Mageia 2.
Mageia 3 and Cauldron was already patched against this bug on Nov 1, 2012, by luigiwalser.

No, even if I added that patch before, there was a flaw in the patch, and the patch has been updated.

Cauldron package fixed and submitted.

I have uploaded updated packages for mageia 2 and 3.
I don't know what advisory to use, but apparently the existing patch was flawed, so feel free to suggest an advisory.

========================
Updated mageia 2 packages in core/updates_testing:
ssmtp-2.64-5.2.mga2

Source RPM: 
ssmtp-2.64-5.2.mga2.src.rpm


Updated mageia 3 packages in core/updates_testing:
ssmtp-2.64-8.2.mga3

Source RPM: 
ssmtp-2.64-8.2.mga3.src.rpm

CC: (none) => cooker
Assignee: cooker => qa-bugs

Thanks Johnny.

Here's another minor change you might want to sync in the Cauldron package:
http://pkgs.fedoraproject.org/cgit/ssmtp.git/commit/?id=999dce90599cad18f1d6fc4bd05ae31fc85db581

Version: Cauldron => 3
Whiteboard: MGA3TOO, MGA2TOO => MGA2TOO

Advisory:
========================

Updated ssmtp packages fix security vulnerability:

It was reported that ssmtp, an extremely simple MTA to get mail off the system
to a mail hub, did not perform x509 certificate validation when initiating a
TLS connection to server. A rogue server could use this flaw to conduct man-in-
the-middle attack, possibly leading to user credentials leak.

References:
https://lists.fedoraproject.org/pipermail/package-announce/2013-August/114906.html
========================

Updated packages in core/updates_testing:
========================
ssmtp-2.64-5.2.mga2
ssmtp-2.64-8.2.mga3

Source RPMs:
ssmtp-2.64-5.2.mga2.src.rpm
ssmtp-2.64-8.2.mga3.src.rpm

(In reply to David Walser from comment #4)
> Here's another minor change you might want to sync in the Cauldron package:

Nice. Added to Cauldron. :-)=

Advisory 11148.adv committed to svn

CC: (none) => davidwhodgins

Some testing info here: https://wiki.archlinux.org/index.php/SSMTP

Testing mga3 64

I edited ssmtp.conf and used the settings from the one given in the link in comment 8, changing them to my gmail login. I didn't bother following that guide any further as our ssmtp.conf is setgid after the last update. 

Tested with a mail to myself.


After installing the update it fails so there is some regression here. 

Enabling Debug=YES in the conf shows this in the journal..

sSMTP[5461]: 220 mx.google.com ESMTP c4sm8709118wiz.0 - gsmtp
sSMTP[5461]: EHLO localhost
sSMTP[5461]: 250 CHUNKING
sSMTP[5461]: STARTTLS
sSMTP[5461]: 220 2.0.0 Ready to start TLS
sSMTP[5461]: SSL not working: certificate verify failed (20)
sSMTP[5461]: Cannot open smtp.gmail.com:587
sSMTP[5461]: Can't open /home/claire/dead.letter failing horribly!

This is despite these two settings being commented..

# Use SSL/TLS certificate to authenticate against smtp host.
#UseTLSCert=YES

# Use this RSA certificate.
#TLSCert=/etc/ssl/certs/ssmtp.pem

Whiteboard: MGA2TOO has_procedure => MGA2TOO has_procedure feedback

It seems to need the patch in comment 4

Once the line below is added to ssmtp.conf it connects & sends Ok.

TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt

If it's decided to add it, be careful to create an rpmnew and not overwrite the existing conf.

it will also need to require/suggest rootcerts

$ urpmf /etc/pki/tls/certs/ca-bundle.crt
rootcerts:/etc/pki/tls/certs/ca-bundle.crt

(In reply to claire robinson from comment #10)
> It seems to need the patch in comment 4
> 
> Once the line below is added to ssmtp.conf it connects & sends Ok.
> 
> TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt

So I should add the patch to both mga2 and 3, right?

Ideally, I think so, see what David thinks.

Submited a new release in testing now.

Updated packages in core/updates_testing:
========================
ssmtp-2.64-5.3.mga2
ssmtp-2.64-8.3.mga3

Source RPMs:
ssmtp-2.64-5.3.mga2.src.rpm
ssmtp-2.64-8.3.mga3.src.rpm

Testing complete mga3 64

installing ssmtp-2.64-8.3.mga3.x86_64.rpm from /var/cache/urpmi/rpms                                                                        
Preparing...                     #########################################
      1/1: ssmtp                 warning: /etc/ssmtp/ssmtp.conf created as /etc/ssmtp/ssmtp.conf.rpmnew


Confirmed the rpmnew contains the ca-bundle.crt line

#IMPORTANT: Uncomment the following line if you use TLS authentication
#TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt


Tested with..

$ echo test | mail -v -s "testing ssmtp setup" username@somedomain.com

Whiteboard: MGA2TOO has_procedure => MGA2TOO has_procedure mga3-64-ok

Updating with MageiaUpdate gives no warning of the rpmnew, it should give a notice and diff comparison. Without any notice given, this will silently break people's configurations.

I think something is still missing here Johnny, probably mga3 aswell.

Sorry, testing mga2 64 in comment 17

From the spec in Mageia 2:
%attr(2750, root, mail) %config(noreplace) %{_sysconfdir}/ssmtp/*

So he's properly got the config marked as config(noreplace).  If MageiaUpdate isn't doing the right thing, that's MageiaUpdate's fault.  There's nothing else that can be done in this package about that.

Whiteboard: MGA2TOO has_procedure mga3-64-ok? feedback => MGA2TOO has_procedure mga3-64-ok

Validating this one then. I checked mga3 again and it does offer the diff there but not mga2, so must just be a peculiarity of mga2, or maybe just my mga2.

Advisory updated. I removed the CVE stanza as it seems it is deemed as hardening rather than being vulnerable and so is not being allocated one.

Could sysadmin please push from 2&3 core/updates_testing to updates

Thanks!

Keywords: (none) => validated_update
Whiteboard: MGA2TOO has_procedure mga3-64-ok => MGA2TOO has_procedure mga3-64-ok mga3-32-ok mga2-64-ok mga2-32-ok
CC: (none) => sysadmin-bugs

Update pushed:
http://advisories.mageia.org/MGASA-2013-0296.html

Status: ASSIGNED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED