http://www.isc.org/products/INN/ "NN 2.4.0 contains extensive under-the-hood modifications to INN. It features a completely rewritten inn.conf parser that will replace other configuration parsers in INN in future releases, a completely rewritten and more reliable tradindexed overview method with new recovery tools, a new internal history API, and considerable internal code cleanup. It also now supports IPv6. For other features and changes, see below. INN 2.4.0 is almost entirely compatible with INN 2.3, and most INN 2.3 users will be able to upgrade with a simple "make update". However, users of the Perl or Python authentication hooks or users with UUCP feeds may need to make additional changes. See the NEWS file that comes with INN for more details. Further 2.4.x releases will be made for bug fixes. New features will go into the 2.5.x series, which is already under development. Please note that the STABLE development branch is now INN 2.4.x, and there will be no further INN 2.3.x releases after INN 2.3.5. " putting it in ~x86 because of those changes ? Reproducible: Always Steps to Reproduce:
next chance for you :)
just a "summary" field change to match my other bug report policy cate-gory/packagename-version (stable/unstable) : problem/version bump/new package just in the hope other people would follow this kind of naming policy, to make buglist more readable
http://www.securityfocus.com/archive/1/349160 better to drop it and add 2.4.1 to portage instead
2.4.3 fixes more security problems seems all versions of inn in portage are masked because of security problems of versions 2.3.5 and lower
secondary thing : the URL has changed to http://www.isc.org/sw/inn/
inn should still be masked.. I've attempted to bump this local without much success on more than one occasion. I simply was unable to locate 2.4.3 at ftp://ftp.isc.org/isc/inn/ Only thing I could find was ftp://ftp.isc.org/isc/inn/snapshots which I assume we would probably rather not use.
seems the "2.4.3" is a typo on their site as both are supposed to be from 07/01/2004 and there is nothing about a 2.4.2 nor any 2.4.2 or 2.4.3 on the FTP. i mailed the general inn@isc.org for confirmation and asked them to correct the page to clarify current state.
Thank you for doing the follow up Stephane
INN 2.4.1 is the correct version; the mention of INN 2.4.3 on the web page is a typo that will be fixed shortly. I'm sorry about the confusion.
http://www.isc.org/index.pl?/sw/inn/ has been fixed no more 2.4.3, only latest : 2.4.1
bummer they did not say anything about the confusion on the INN on the website. Anyway Martin Holzer can you bump this in portage. Everybody else till then please try to bump local and see everything looks good and report results here.
Created attachment 26193 [details] inn 2.4.1 ebuild i don't know how's the progress, so i'll attach an ebuild for 2.4.1 here Things which could need some tweaking: - doc installed twice (once via make install, once via doinst) - wrong libinnhist.la dependency (ebuild removes .la to force rebuild during make install) - masking Ebuild tested with USE="ipv6 ssl -tcltk -python -perl" on i686.
Created attachment 26196 [details] inn-2.4.1.ebuild sorry, uploaded wrong ebuild file. fixes ipv6 (use_enable instead of use_with)
Created attachment 26389 [details] inn-2.4.1.ebuild I finally got inn running as i need it, here are the changes: Changes: * prevent overwriting /var/spool/news/db/{active,newsgroups} (sample files get installed into /usr/share/doc/${PF}/dbexamples and will be copied only if active/newsgroups does not exist) * added sasl for nnrpd ssl support * typo fix (doc installed into ${P} instead of ${PF}) * experimental ebuild ${PF].ebuild config (does *not* configure, but some post installation steps like changing shell for news to bash, initializing history db, creating ssl certificate, running inncheck) Test pass (clients: slrn/tin): USE="ipv6 perl python sasl ssl -tcltk" emerge inn * IPv6 * SSL/Auth * SSL/Auth + IPv6 (nnrpd, client: slrn) * perl filtering Few groups with ~14k articles last days, no crashes so far. Bugs: use tcltk and innd segfaults
From the ISC site: "2004-01-07 - INN v2.4.1, among other things, fixes a security vulnerability in the special filing of control messages into per-type newsgroups which may be remotely exploitable. ISC strongly urges all users of INN 2.4.0 or STABLE snapshots to upgrade to this release as soon as possible. INN 2.3.x and earlier releases are not affected. Thanks to Dan Riley for his excellent bug report." 2.4.0 isn't in portage -- only 2.3.5 is. Furthermore, 2.3.5 is hard-masked at the moment (possibly incorrectly). At any rate, this is no longer a security issue, so removing security@ cc.
I have emerged the 2.4.1 ebuild, but I can not create the database. No makedbz executable is found. Nothing resembling a makedbz command seems to be on my system at all. Strange, no?
Now I emerged 2.3.5 first, and 2.4.1 after that. Makedbz is now installed, it seems that one needs 2.3.5 emerged, and 2.4.1 only updates it. At least on my system. Arno
Created attachment 31483 [details] inn-2.4.1.ebuild Thanks, this is fixed now with the new attachment. Tested: USE="ipv6 perl python sasl ssl -kerberos -tcltk" Actually the libtool coming with inn seems to be broken and does not relink correctly when installing with DESTDIR set to something different then the prefix. On a fresh installation, the hack forcing recompilation does not work, and because i forgot a die an incomplete install set has been build. :( Unfortunately, the fix forcing the use of gentoo's libtool makes inn depend on autoconf 2.13.
can we add this to cvs (masked) because of feature and security issuse?
Created attachment 38179 [details] inn-2.4.1.ebuild With 2.6 kernels and raiserfs inn complains about spool inodes. This ebuild makes use of a patch that corrcts this problem.
Created attachment 38180 [details, diff] inn-2.4.1-gentoo.diff
Comment on attachment 38179 [details] inn-2.4.1.ebuild With 2.6 kernels and reiserfs inn complains about spool inodes. This ebuild makes use of a patch that corrects this problem.
Comment on attachment 38180 [details, diff] inn-2.4.1-gentoo.diff kernel 2.6 + reiserfs fix taken from inn-current (stable) from isc.org. Place it in /usr/local/portage/net-news/inn/files and use ebuild above.
I'm running 2.6 and reiserfs on /var/spool/news as well. You just need to change the following entry in /etc/news/inn.conf: innwatchspoolnodes: 0 Then, it should also if you have something like !!!/bin/df -i .|/bin/sed '1d'|/bin/awk '{print $4;}' ! lt ! ${INNWATCHSPOOLNODES} ! throttle ! No space (spool inodes) in your innwatch.ctl. ;-)
*** Bug 62074 has been marked as a duplicate of this bug. ***
Created attachment 38461 [details] INN-2.4.1 ebuild I used the improvements of the previous two ebuilds (IDs 31483 and 38179) to merge them with my ebuild attached to Bug #62074. One should check compiling with berkeley database support, because I could not get it working...
Created attachment 38462 [details] rebuild-database
Just for information, here is the exact abort message for berkeley db support (warnings removed): | gcc -o .libs/innd art.o cc.o chan.o icd.o innd.o keywords.o lc.o nc.o | newsfeeds.o ng.o perl.o proc.o python.o rc.o site.o status.o tcl.o util.o | wip.o -Wl,-export-dynamic | /var/tmp/portage/inn-2.4.1/work/inn-2.4.1/lib/perl.o -rdynamic | /var/tmp/portage/inn-2.4.1/work/inn-2.4.1/history/.libs/libinnhist.so | /var/tmp/portage/inn-2.4.1/work/inn-2.4.1/storage/.libs/libstorage.so | /var/tmp/portage/inn-2.4.1/work/inn-2.4.1/lib/.libs/libinn.so -ldb | -L/usr/lib/python2.3/config -lpython2.3 -lpthread -ldl -lutil -lm | -L/usr/local/lib /usr/lib/perl5/5.8.4/i686-linux/auto/DynaLoader/DynaLoader.a | -L/usr/lib/perl5/5.8.4/i686-linux/CORE -lperl -lpthread -lnsl -ldl -lm | -lcrypt -lutil -Wl,--rpath -Wl,/usr/lib/news/lib | /var/tmp/portage/inn-2.4.1/work/inn-2.4.1/storage/.libs/libstorage.so: | undefined reference to `txn_abort' | /var/tmp/portage/inn-2.4.1/work/inn-2.4.1/storage/.libs/libstorage.so: | undefined reference to `txn_begin' | /var/tmp/portage/inn-2.4.1/work/inn-2.4.1/storage/.libs/libstorage.so: | undefined reference to `txn_commit' | collect2: ld returned 1 exit status => It seems as if txn_abort, txn_begin and txn_commit were inside of db.h but not in the listed Libraries. Now I tried to repoduce the error with example-code by Sleepycat. http://www.sleepycat.com/docs/ref/simple_tut/example.cs contains everything needed. Compiling without any changes should be no problem. Now we introduce debenv and add the line "DB_ENV *dbenv;" next to the other variables. Compiling should generate a warning with -Wall, nothing more. Then we write "txn_begin(NULL, NULL, NULL, 0);" somewhere after our first added line. Compiling will fail: | maurice@maurice-el1inf dbtest $ gcc -Wall -ldb dbtest.c -o dbtest | dbtest.c: In function `main': | dbtest.c:16: warning: unused variable `dbenv' | /tmp/ccENRxHs.o(.text+0x167): In function `main': | : undefined reference to `txn_begin' | collect2: ld returned 1 exit status Now we change the line to "dbenv->txn_begin(NULL, NULL, NULL, 0);". It should compile just fine - even when our new code would never be able to run cleanly, because we did not give allocated memory to the function - SIGSEGV is the result, however it is enough we need to know. I will try to create a patch for the changed interface, eventually send it to ISC, but as I have not seen the error somewhere else I am not sure whether this is special to my Berkeley DB (db-4.1.25_p1-r3) or even gentoo. Thanks in advance for anyone who can say anything about this. Please note that the ebuild I provided is not affected by the error. It does not compile berkeley db support in. Maurice
Created attachment 38675 [details, diff] db4-configure.patch Yes, i noticed the unresolved symbols in innstorage, too. Unfortunately i know nothing about berkeleydb. Here is a configure patch i started with. It assures that the latest include/.so pair is found even on gentoo linux, i hope this helps you to get started... apply patch; aclocal; autoconf; ./configure...
I already created a small patch, but as it may result in licence problems to put it here under GPL-2 and sending it to ISC for inclusion in a product that isn't covered by the same licence, I do not attach it to this bug. Your db4-patch might not work since 4.1 is the version and is correctly symlinked, at least here: maurice@maurice-el1inf lib $ ls -la | grep libdb -rw-r--r-- 1 root root 1080480 Aug 18 09:03 libdb-4.1.a -rw-r--r-- 1 root root 703 Aug 18 09:03 libdb-4.1.la -rwxr-xr-x 1 root root 803600 Aug 18 09:03 libdb-4.1.so lrwxrwxrwx 1 root root 11 Aug 18 09:03 libdb.a -> libdb-4.1.a lrwxrwxrwx 1 root root 12 Aug 18 09:03 libdb.so -> libdb-4.1.so [...] I am not sure whether your patch is needed for >=4.2, because -ldb should always work. The patch can be found here: http://mauricem.com/db_patch.patch, however I did not test it, but it should work as it conforms to the documentation for Berekeley DB. Maurice
I'm not sure, but imho you can just release your changes under GPL2. If you do, you are the owner of that changes and can release them under any other licence in parallel. The GPL2 released version can not be revoked, but it can be done anything the other licence allows with what you released under the other licence. http://www.gnu.org/licenses/gpl-faq.html#TOCReleaseUnderGPLAndNF http://www.gnu.org/licenses/gpl-faq.html#TOCHeardOtherLicense
Well, http://www.gentoo.org/doc/en/policy.xml says that copyright must be assigned to Gentoo. That is a problem in that case as I would not be able to release it under any other licence, because I would not be the copyright holder. In fact that guide makes life harder, but it is unnecessary, as all programs are copyrighted by their programmers and releasing ebuilds under GPL-2 ensures that this ebuild can be used freely and that any future work can base on that ebuild as long as the derived work gets released under the same licence. So, why shouldn't one leave the copyright by the respective owners? I do not want to violate the rule here and now, so the patch can be included as GPL-2 in the SRC_URI up to the time ISC includes a fix in a new version.
PLEASE PUT IT INTO PORTAGE ASAP!!! thanks! all versions < 2.4.1 are hard masked because of security flaws and the "good" 2.4.1 is not in portage since ages (2.4.1 is available since 2004-01-07).
sorry for SCREAMING ;-)
It is more than one developers fault. The first one masked INN 2.3.5 (there is no reason to do so) - and forgot it. The second one got assigned with this bug and mybe he looked at this bug - and forgot it. The third one needs a lot of time for checking of this ebuild, but I can understand him ...ahh... halfway. The next one is this bug system - it simply isn't designed for misusing it as an open versioning system. So for example it lacks of an easy way to effectively work on specified programs. For example easy switching of the development indicator is not possible. Once I installed gentoo, because I complained about all the old software on debian which needs to get replaced by current and I got recommended Gentoo. Nowadays I see ebuilds deposited in this bug tracking system. I looked into the portage code once and I won't do it any more, because it is too much code for that little effect. One might look at Source Mage. They aren't using anything than bash and they do not need so much code... Note that the file "rebuild-database" does not contain a copyright line claiming Gentoo as holder, so you must not claim your copyright and therefore copyright can not be assigned to Gentoo. I removed the db4 patch from my site. Reason for all this is beside of those points that I do not agree with the copyright assignment as the GNU General Public Licence gives everyone enough power and no one should be forced to give up his copyright. Everything is dubious to me since all developers have to sign this assignment, but I could neither find a signed document guaranteeing the developers one way the copyrights gets used nor an open list of the financial things they are doing. One might compare http://www.gentoo.org/proj/en/devrel/recruiters/ and the list on http://dev.gentoo.org/~swift/nfp-foundation.html to see them lying: "The trustees are not going to interfere with the Gentoo development process and situation - all that is handled by the current managers (or coordinators, it's just a name) and the project leads of the individual projects that Gentoo embodies." That is important as such people should not be able to decide who elects themselves. As you can see... :-( Sorry for the long posting, but as long as nothing very fundamental will change in the future it was my last one here. Maurice -- disappointed
OK, I commited 2.4.1 to CVS. It's package.mask'ed for some testing, please give it a whirl and report issues to this bug. If applicable attach a patch against the ebuild in portage.
ebuild works (at least emerge). Will test it this week.
I updated the ebuild with a patch to successfully compile in BerkeleyDB support and added the local USE flags inntaggedhash and innkeywords. Enabling the inntaggedhash flag will disable the large file support since their incompatible.
That's the result: | root@maurice-el1inf inn # ACCEPT_KEYWORDS="~x86" emerge -vp inn | | These are the packages that I would merge, in order: | | Calculating dependencies ...done! | [ebuild N ] sys-libs/db-3.2.9-r10 -doc +java 2,036 kB | [ebuild R ] net-news/inn-2.4.1 +berkdb -innkeywords -inntaggedhash -ipv6 | -kerberos +perl +python -sasl +ssl -tcltk 0 kB | | Total size of downloads: 2,036 kB Few things to remove overhead and add proper support for db4: SRC_URI + copy on mirror of http://mauricem.com/inn_db4.tar.gz LICENCE + GPL-2 src_compile + if use berkdb ; then mv ${WORKDIR}/db_patch.patch ${S} einfo 'Patching for Berkeley DB 4.x' patch -p0 -c -i db_patch.patch fi REST - remove old patch, use of autoconf and libtool, etc. Next - look at http://www.eyrie.org/~eagle/software/inn/docs-2.3/news.html and use the following information: "(Rather than .hash and .index files, you may have a .pag file if you're using tagged hash.)" HTH, Maurice
I made a Fresh Install. Starting from innd not possible, cause this Error: Starting innd. /usr/lib/news/bin/innd: error while loading shared libraries: libinnhist.so.2: cannot open shared object file: No such file or directory The Library doesn't exist on the complete System. With LDD i got this: linux-gate.so.1 => (0xffffe000) libinnhist.so.2 => not found libstorage.so.2 => not found libinn.so.2 => /usr/lib/news/lib/libinn.so.2 (0x4001a000) libdb-4.1.so => /usr/lib/libdb-4.1.so (0x40032000) libpthread.so.0 => /lib/libpthread.so.0 (0x400f7000) libdl.so.2 => /lib/libdl.so.2 (0x40147000) libutil.so.1 => /lib/libutil.so.1 (0x4014b000) libm.so.6 => /lib/libm.so.6 (0x4014e000) libperl.so.1 => /usr/lib/libperl.so.1 (0x4016f000) libnsl.so.1 => /lib/libnsl.so.1 (0x40268000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4027c000) libc.so.6 => /lib/libc.so.6 (0x402a8000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Should be fixed in CVS. Please re-emerge.
If there are no objections or further improvements, I'm going to unmask 2.4.2 in about 24h.
2.4.2? 8-) Have I missed anything? ftp://ftp.isc.org/isc/inn/ls-lR lets inn-2.4.2 appear somewhere... :-)
Typo, I meant 2.4.1 ;)
Unmasked.
