Bugzilla Bug 120842

I'd appreciate it if someone put the latest stable release from upstream in
portage. At the time of writing this is 0.6.2, though work seems to be going on
for 0.7.

Thanks in advance!

Created an attachment (id=80075) [edit]
Ebuild proposal for the 0.6.2 pam_mysql

(From update of attachment 80075 [edit])
Pleasure to help

Created an attachment (id=80076) [edit]
Ebuild proposal for the 0.6.2 pam_mysql

Header line corrected to respect the ebuild documentation
Pleasure to help

Created an attachment (id=80078) [edit]
Ebuild proposal for the 0.7RC1 pam_mysql

Pleasure to help

I had a look on the sasl2 and openssl options.
Ok, it won't work in this state. 
The configure file search about some directories which don't exist.
I don't understand why. So if someone could help ...

Created an attachment (id=80193) [edit]
0.6.2 and 0.7_rc1 versions corrected

Hi guys,

   I hope to have corrected thoses version to take in account sasl2 and
openssl.
   In fact this module was done on the Debian distrib and never found the
necessary includes and c functions to correctly link with ssl or sasl.
   So, i hope to have corectly modified the necessary files.


   Would it be possible that someone test it please ?

Cyrius

(From update of attachment 80193 [edit])
see bug 123405

*** Bug 85787 has been marked as a duplicate of this bug. ***

*** Bug 104967 has been marked as a duplicate of this bug. ***

*** Bug 123405 has been marked as a duplicate of this bug. ***

Created an attachment (id=85531) [edit]
pam_mysql-0.6.0-to-0.6.2.patch

I'd like to contribute this patch against pam_mysql-0.6.0.ebuild.

It not only is a version bump but provides a workaround against the configure
bug which prevents headers for MD5 to be found. MD5-support (crypt=3) works.

Created an attachment (id=85532) [edit]
pam_mysql-0.6_md5_openssl.patch

Created an attachment (id=85533) [edit]
pam_mysql-0.6_md5_sasl2.patch

quoted from http://pam-mysql.sourceforge.net/News/00005.php

Aressed security concerns:

    *

      Possible segmentation fault in the SQL logging facility, which can cause
Denial-of-Service (DoS).
    *

      Flaws in the authentication and authentication token alteration code
where incorrect treatment of the pointer returned by pam_get_item() were
spotted. They can most likely induce DoS or possibly lead to more severe
problems.

security team, please do your check.

If this is a security concern I'm for masking and asking for a new maintainer
on g-dev until someone steps up, and deleted when the case.

Reassgining to security.

Maintainer mail sent to -dev.

pam-mysql 0.7RC1 added to the tree, the package now belong to the "mysql" herd,
still need to look in depth at the patches "pam_mysql-0.6_md5_openssl.patch"
and "pam_mysql-0.6_md5_sasl2.patch", these, temporary have _not_ been applyed.

rgds, Francesco Riosa

P.S. I'm using 0.7RC1 from a pair of weeks on amd64

vivo, is this ready to be stable?

two additional use flag need to be added, "openssl" an "sasl", but need the
usual little modifications to the ebuild and further testing, so better do that
in a "-r1".

As is the package is minimally tested, only amd64, basically I do use it as
auth system on a mail-server where sasl+mysql was not an option.

However it compile and run, so yes it's ready for arch's tester and
stabilization.

x86 done

Created an attachment (id=86990) [edit]
pam_mysql-0.7_rc1.ebuild.md5.patch

Please see the attached patch which addresses the configure bug which prevents
headers for MD5 to be found.

The patch is to be applied on the current ebuild.

I've already published a complete ebuild here: http://svn.ossdl.de/all/ossdl/

alpha done.

I noticed 0.5 is stable on ppc, but 0.7_rc1 is still ~ppc. Maybe they should be
added to CC to stabilize 0.7_rc1 too?

ppc please test and stable, thanks. Also thanks to tcort for the headsup

Hello all,

   I'm clearly disapointed and discouraged. I've already done this in the
123405 bugg. 
   Then i don't understand you. Why do you not directly keep those attachments
from 123405 and correct them here ????

   I mean using sed like you want and others ?
   Could you explain your position ?
   That's great to re discover what i've already test and done. 


Cyrius

ppc stable

[glsa voting]

OK, i shoot first.

i would vote no glsa.

Phew. Gut feeling says "no" since I don't really see a big impact. On the other
hand, it's still valid and we don't give anything away by doing a GLSA. So why
not, in doubt count me as "yes".

I agree with frilled, why not,
vote yes glsa
rgds
daxomatic

Voting yes

sec-devs, please vote and decide on this B2-maybe. One "yes" would be
sufficient.

I vote YES.

Can we have someone from auditing take a deeper look at what's described as "or
possibly lead to more severe problems"
(http://pam-mysql.sourceforge.net/News/), or does somebody know?

Thx everyone.

GLSA 200606-18