From ${URL} : the Debian Security Team is requesting 2 CVEs for inspircd. * the fix that was included in Debian for CVE-2012-1836 is incomplete, and does not solve the original remote code execution problem. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780880#5 * a DoS can be triggered by invalid DNS packets. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780880#5 https://github.com/inspircd/inspircd/commit/58c893e834ff20495d007709220881a3ff13f423 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
While designating this package to maintainer-needed is valid enough, doing so without any reasons provided? Once abandoned to maintainer-needed it is likely to simply sit neglected. Is there any plan of action to actually bump this package (given the link @ $URL currently cites no CVE designation)?
I plan to bump this and take maintenance of this package as soon as my primary Gentoo system is back up and running. ETA is by the end of June 2015 at the latest.
(In reply to Jeff (JD) Horelick from comment #2) > I plan to bump this and take maintenance of this package as soon as my > primary Gentoo system is back up and running. ETA is by the end of June 2015 > at the latest. All looks good.
2 CVE's Requested here - http://seclists.org/oss-sec/2015/q2/160
Created attachment 407694 [details, diff] InspIRCd 2.0.20 version of fix-path-builds The net-irc/inspircd ebuild itself does not seem to require any changes. Simply copying the 2.0.18 ebuild into my local overlay and renaming it 2.0.20, then adding this patch to files/, seems to have worked fine for various combinations of USE flags (though I did not test all permutations).
Unless, or until, a user like Andrew Wilcox from the previous entry puts a hand up and eptresses interest in proxy maintaining this, I have no authority of involvement here. This would add authority of the proxy-maint herd as a participant. Also the end of June 2015 is about to be surpassed by the end of July.
(In reply to Jeff (JD) Horelick from comment #2) > I plan to bump this and take maintenance of this package as soon as my > primary Gentoo system is back up and running. ETA is by the end of June 2015 > at the latest. Jeff, any interest in bumping this especially with Andrew providing some help?
Created attachment 411502 [details] 2.0.20 ebuild I would be happy to proxy-maintain this package. Attached is the 2.0.20 ebuild (unchanged from 2.0.18). Use along with the fix-path-builds patch attachment from earlier.
Great, I will CC proxy-maintainers then ;) Thanks
(In reply to Andrew Wilcox from comment #8) > Created attachment 411502 [details] > 2.0.20 ebuild > > I would be happy to proxy-maintain this package. Attached is the 2.0.20 > ebuild (unchanged from 2.0.18). Use along with the fix-path-builds patch > attachment from earlier. On runtesting, the ebuild fails to install unable to find the init file. portage has under files inspircd-2.0.17-init & inspircd-2.0.18-init then in install phase it has newinitd "${FILESDIR}/${P}-init" "${PN}" So ${P} no longer applies in an ebuild inspircd-2.0.20.ebuild. This standard installation needs a file named generically so it is robust in version bumps. 2 options; Either edit the entry in src_install to newinitd "${FILESDIR}/${P/20/18}-init" "${PN}" (which lacks elegance or rename or add a file under files to something like inspircd.initd and adjust the line above accordingly. It will then apply robustly over version bumps. (Copying the same file to a bumped name is imo a poor approach)
I would definitely say the best course of action is to rename to inspircd-init as the files are identical. Just did a quick test in my overlay and it worked fine. Should the other ebuilds be revbumped and use this file as well to clean up files/, since it is identical? Actually, I'm not sure the policy is for what to do with packages that have known security vulnerabilities. Should the older versions be masked? I can test 2.0.20 on at least i386 and ppc... probably mips and arm too if it'd help. I'm already using the 2.0.20 ebuild on my amd64 laptop for testing different parts of IRCv3 that inspircd implements and it's been perfectly fine.
I'll get onto this tomorrow. This is a security bug so old versions are planned to be purged. Let the sec team deal with that
(In reply to Andrew Wilcox from comment #11) > > Should the other ebuilds be revbumped and use this file as well to clean up > files/, since it is identical? The file could be changed to inspircd-init (${PN}-init) but since it's already in place I so little point. It can be removed post stabilising of -2.0.20. > Actually, I'm not sure the policy is for > what to do with packages that have known security vulnerabilities. Should > the older versions be masked? I can test 2.0.20 on at least i386 and ppc... > probably mips and arm too if it'd help. I'm already using the 2.0.20 ebuild > on my amd64 laptop for testing different parts of IRCv3 that inspircd > implements and it's been perfectly fine. We will deal this this by std procedure. commit d7208425f4d0843462fbf24751c6807c1098e79e Author: Ian Delaney <idella4@gentoo.org> Date: Fri Sep 18 11:36:22 2015 +0800 net-irc/inspircd: bump to 2.0.20 New maintainer added to metadata under proxy-maintainers herd, init file renamed to expand in any '{P}', new patch for fix-path-builds, ebuild and patch by new maintainer via bug #545034, rm 2.0.17
inspircd-2.0.18.ebuild looks fine to be made stable Please proceed
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
(In reply to Ian Delaney from comment #14) > inspircd-2.0.18.ebuild looks fine to be made stable > Please proceed I think I meant inspircd-2.0.20 which ago has made stable. Thx ago Author: Ian Delaney <idella4@gentoo.org> Date: Thu Sep 24 10:05:19 2015 +0800 net-irc/inspircd: cleanup wrt bug #545034
Arches and Maintainer(s), Thank you for your work. New GLSA Request filed.
CVE-2015-6674 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-6674): ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. ** TEMPORARY ** package inspircd is vulnerable. problem of "i =- 12" where "i -= 12" was intended
This issue was resolved and addressed in GLSA 201512-13 at https://security.gentoo.org/glsa/201512-13 by GLSA coordinator Yury German (BlueKnight).
