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 attachment 80075 [details] Ebuild proposal for the 0.6.2 pam_mysql
Comment on attachment 80075 [details] Ebuild proposal for the 0.6.2 pam_mysql Pleasure to help
Created attachment 80076 [details] Ebuild proposal for the 0.6.2 pam_mysql Header line corrected to respect the ebuild documentation Pleasure to help
Created attachment 80078 [details] 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 attachment 80193 [details] 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
Comment on attachment 80193 [details] 0.6.2 and 0.7_rc1 versions corrected 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 attachment 85531 [details, diff] 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 attachment 85532 [details, diff] pam_mysql-0.6_md5_openssl.patch
Created attachment 85533 [details, diff] 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 attachment 86990 [details, diff] 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
