Current unassigned ports problem reports
Current FreeBSD problem reports The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. Critical problems S Tracker Resp. Description f ports/117270[UPDATE] net/asterisk-addons to 1.4.4 1 problem total. Serious problems S Tracker Resp. Description o ports/106369vpnd caused kernel panic with ppp mode o ports/106372vpnd can't run with slip mode f ports/108077www/linux-flashplugin9 crashes linux-firefox f ports/108413net/vnc does not works. f ports/112385sysutils/lookupd on Kernel 64 f ports/112921x11-wm/Beryl not loading focus and keybinding settings f ports/113144print/ghostscript-gnu dumps core with several output d f ports/115818Executable clash between databases/grass and ruby gems f ports/116378xorg 7.3 on -stable breaks math/scilab f ports/116385net/vnc using vnc.so crashes Xorg 7.3 when remote comp f ports/116586net/isc-dhcp3-server does not work when compiled with o ports/116611devel/p5-gearmand - rename to devel/p5-Gearman-Server f ports/116753multimedia/MPlayer crashes after playing *.flv on 7.0- f ports/116777The math/scilab port fails in demos-signal-bode. f ports/116778security/nmap ping-scan misses some hosts f ports/116949security/vpnc: Some Cisco Concentrators refuse Connect o ports/117025multimedia/pwcbsd: Pwcbsd-1.4.0 + New USBStack not wor o ports/117119new port: emulators/dboxfe, a front-end to DosBox conf f ports/117128security/ipsec-tools racoon.sh fails with /var on mfs o ports/117144sysutils/nut : ACL with IPv6 address rejected o ports/117145[PATCH] math/dislin - update to 9.2 f ports/117196Port net/asterisk-addons 1.4.2 fails to compile f ports/117686print/fontforge : extract fails when building with NOP o ports/117689[update] games/ftjava o ports/117792new version of sysutils/Kgtk port o ports/117882mail/prayer needs update f ports/117886ports: net/nss_ldap 257 size mismatch from source PADL o ports/117942net/redir: fix core dump on redir f ports/117956HP LaserJet 1022 not working after upgrade to print/HP o ports/117985ftp/jftpgw: has incorrect startup script 30 problems total. Non-critical problems S Tracker Resp. Description f ports/101166bittorrent-curses only works under English locales. o ports/107354net/icmpinfo: icmpinfo -vvv does not recocnize any ICM a ports/107447[patch] devel/sdl12 - Add devel/directfb support f ports/107937jailed net/isc-dhcp3-server wouldn't run with an immut f ports/111399print/ghostscript-gpl: ghostscript-gpl WITH_FT_BRIDGE f ports/111456[UPDATE] finance/pfpro updated distinfo f ports/112887net/nxserver 1.4.0_1 fails to compile after upgrading f ports/113423Update for ports net/freenx to version 0.6.0 f ports/114127net/vnc - vnc.so installed to bad location f ports/114825pam module security/pam_abl not working s ports/115216ADA devel/florist exit_process program doesn't compile s ports/115217Ada devel/florist socket program doesn't compile due t f ports/115304multimedia/gpac-mp4box cannot import files larger than f ports/115336port multimedia/avifile on FreeBSD 7.0
Re: [PATCH] portmaster with SU_CMD
Doug Barton wrote: This is very interesting stuff, but I don't see how it would be useful to a very wide audience. My feeling is that the vast majority of our users build and/or install ports as root, and I don't see any good reason for that not to be the default practice. I'll review your patch more thoroughly when time allows (since we are in a freeze I can't add new features right now anyway) but I'm not inclined to add this unless there is a fairly substantial clamor for it. I'd use it if it was available. (I even think this should be default behaviour, but that's for another thread/bikeshed). regards, Hans Lambermont ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] portmaster with SU_CMD
On Sun, 11 Nov 2007 16:59:50 -0600, Doug Barton [EMAIL PROTECTED] wrote: This is very interesting stuff, but I don't see how it would be useful to a very wide audience. My feeling is that the vast majority of our users build and/or install ports as root, and I don't see any good reason for that not to be the default practice. I'll review your patch more thoroughly when time allows (since we are in a freeze I can't add new features right now anyway) but I'm not inclined to add this unless there is a fairly substantial clamor for it. In fact I think I've passed a tipping point for portmaster where the complexity of the code, and the number of options (and thus, optional code paths) make adding new stuff very hard to do without introducing more bugs, and because there are so many different combinations of options it's hard to regression test improvements to existing features, never mind new ones. I'm not saying I'll never add a new feature, just that there needs to be a really good reason to do so. I agree, because you can't build any ports in /usr/ports as in normal user anyway. I don't see any good reason to do it either. Cheers, Mezz Doug -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: mod_security2-2.1.3
--On Sunday, November 11, 2007 13:55:42 -0200 Marcelo Araujo [EMAIL PROTECTED] wrote: Grant Peel wrote: Hello, mod_security seems to have a problem with the MAC Safari browser using some post statements. Accoring the the developers, these problems should be fixed in 2.1.4. Are there any plans to upgrade the port anytime soon? -Grant Hey Grant, After freeze, I should work to do a upgrade on mod_security2 to new version. Thanks a lot for the reporting. Best Regards. Please be sure to add notes to UPDATING. The change to version 2 of mod_security is a dramatic change that renders older versions obsolete. Folks who are using mod_security (includes me) need to know that they will have to completely rewrite their rules to use the new syntax. (In fact, you may want to keep the older version in mod_security-1.3 or something like that to allow folks who don't want to make the change right away to continue to use the old port.) -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] portmaster with SU_CMD
On Mon, 12 Nov 2007 10:33:55 -0600 Jeremy Messenger [EMAIL PROTECTED] wrote: I agree, because you can't build any ports in /usr/ports as in normal user anyway. I don't see any good reason to do it either. Yes you can. You just need to set WRKDIRPREFIX in your /etc/make.conf, to /tmp for instance. I've been doing that happily for some years now. -- Ricardo Nabinger Sanchez [EMAIL PROTECTED] Powered by FreeBSD Left to themselves, things tend to go from bad to worse. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] portmaster with SU_CMD
On Mon, 12 Nov 2007 11:31:42 -0600, Ricardo Nabinger Sanchez [EMAIL PROTECTED] wrote: On Mon, 12 Nov 2007 10:33:55 -0600 Jeremy Messenger [EMAIL PROTECTED] wrote: I agree, because you can't build any ports in /usr/ports as in normal user anyway. I don't see any good reason to do it either. Yes you can. No, not by default and I have pointed 'in /usr/ports'. You just need to set WRKDIRPREFIX in your /etc/make.conf, to /tmp for instance. I've been doing that happily for some years now. Doug said, 'I'm not saying I'll never add a new feature, just that there needs to be a really good reason to do so.' Do anyone has any? I personal still don't see any good reason to do it. Cheers, Mezz -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] portmaster with SU_CMD
Greg Minshall wrote: i'd add my two cents for being able to do builds without running as root. Building as non-root user and then installing as root has its caveats I would think.. Pro: - Compiling as a non-root user and then installing as root reduces the security risk of a possible exploit in the portmaster / base system infrastructure. Con: - People with sufficient permissions (possibly caused by bad umask settings) but without root access, can modify the binaries / recompile files to suit their needs prior to them being installed as root (say modify the source's logic to suit one's needs, i.e. skip a critical step or install a hardcoded backdoor). Don't think that this isn't a problem because many ports take a long time to compile, and as such there are plenty of chances to inject whatever code one wants so that it's installed. - The same goes for reinstalls, because if I knew that a user didn't clean out their compiled sources (don't remember if portmaster does this; portupgrade / portinstall do this though), and someone recompiled a portion of the binaries and the maintaining user didn't check that the binaries had been untouched since the last compile / install, they would be in serious trouble. It's not entirely likely but given some peoples' resources and knowledge, and if they were either rubbed the wrong way, or wanted to make sure they had access to the machine at all times, this would definitely be a potential issue. Personally, I don't really care either way because no one has access to my machines, either locally or remotely, but I would think that these are issues to consider before going all gung ho with this patch. Sometimes you gotta think as a system cracker (consider security faults), before you start thinking like a hacker (trying to fix things). -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] portmaster with SU_CMD
Hi all, I haven't got all the mails in this thread so far because I haven't been subscribed to ports@ in a while. I'll try to reply to what I've read in the archives so far. I'm subscribed again now so I will get followups from here on without people having to Cc me. On Mon, Nov 12, 2007 at 03:31:42PM -0200, Ricardo Nabinger Sanchez wrote: On Mon, 12 Nov 2007 10:33:55 -0600 Jeremy Messenger [EMAIL PROTECTED] wrote: I agree, because you can't build any ports in /usr/ports as in normal user anyway. Nonesense. I described one particular way of doing it in the mail that started this thread. I don't see any good reason to do it either. There's tons of good reasons for doing it. For example, my reason is that I don't see a point in running something as root that does not need root, especially if execution of arbitrary commands is involved. This can always lead to problems. I'd rather not have some bug in some build or configure script mess with arbitrary stuff in my filesystems. Yes you can. You just need to set WRKDIRPREFIX in your /etc/make.conf, to /tmp for instance. I've been doing that happily for some years now. There's literally tons of ways of doing it. No, not by default and I have pointed 'in /usr/ports'. Arguing that building ports as root is the default behaviour in FreeBSD is no argument at all against the patch, because the patch does not change this default behaviour. It just adds an option that makes portmaster work nicely with another option that is already provided by FreeBSD, namely setting SU_CMD in /etc/make.conf. The same option is provided in NetBSD's pkgsrc and OpenBSD's ports, by the way. It's not that exotic. But: I respect Doug's caution, because the patch isn't small. It took me a while to get it working right on my system. It could have side effects no one knows about -- AFAIK it's only been tested on a single system yet (mine), with only a single way of building ports as non-root while there's many more systems out there that are all set up differently. So I guess it would help if people who want this feature simply test the patch for a while and then report whether it works for them or not. And people who don't want the patch test it with their standard procedure to see if it messes things up for them or not. Just saying that you want it or don't want it without testing whether it actually works or breaks anything for you won't help Doug make the decision whether to adopt this patch or not. He needs proper feedback to make an informed decision. I need proper feedback to fix any issues that might come up for other people using this patch. So if you have the time, please test it, no matter if you want to use the -S flag or not. Here's my own take again: I have been using the patch in its current form for 2 or 3 weeks during which I updated ports about three or four times. I haven't noticed any regressions so far. In my already described setup it even made it through the big gnome-2.18-2.20 update without any issues, except for one issue unrelated to portmaster which has already been filed. See http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/117976 I also found an issue in devel/ncurses while testing the patch, not related to portmaster either, but to the port not heeding WRKDIRPREFIX correctly. This bug has since been fixed: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/117643 -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgp6Z8kKsOcRa.pgp Description: PGP signature
Re: [PATCH] portmaster with SU_CMD
On Mon, 12 Nov 2007 12:58:25 -0600, Stefan Sperling [EMAIL PROTECTED] wrote: Hi all, I haven't got all the mails in this thread so far because I haven't been subscribed to ports@ in a while. I'll try to reply to what I've read in the archives so far. I'm subscribed again now so I will get followups from here on without people having to Cc me. On Mon, Nov 12, 2007 at 03:31:42PM -0200, Ricardo Nabinger Sanchez wrote: On Mon, 12 Nov 2007 10:33:55 -0600 Jeremy Messenger [EMAIL PROTECTED] wrote: I agree, because you can't build any ports in /usr/ports as in normal user anyway. Nonesense. I described one particular way of doing it in the mail that started this thread. I don't see any good reason to do it either. There's tons of good reasons for doing it. For example, my reason is that I don't see a point in running something as root that does not need root, especially if execution of arbitrary commands is involved. I don't count this as a good reason, since there is no reason to do it in complicate way for portmaster. The portmaster required root for install, so why not just login as in root and run portmaster? This can always lead to problems. I'd rather not have some bug in some build or configure script mess with arbitrary stuff in my filesystems. You do have a good point but I have yet to see configure/build will mess up the filesystem, which installation will. I have seen the installation will poke (not edit files, but install files in the wrong place) around in / filesystem a few of times. Kind of no difference. Yes you can. You just need to set WRKDIRPREFIX in your /etc/make.conf, to /tmp for instance. I've been doing that happily for some years now. There's literally tons of ways of doing it. No, not by default and I have pointed 'in /usr/ports'. Arguing that building ports as root is the default behaviour in FreeBSD is no argument at all against the patch, because the patch does not change this default behaviour. It just adds an option that makes portmaster work nicely with another option that is already provided by FreeBSD, namely setting SU_CMD in /etc/make.conf. The same option is provided in NetBSD's pkgsrc and OpenBSD's ports, by the way. It's not that exotic. But: I respect Doug's caution, because the patch isn't small. It took me a while to get it working right on my system. It could have side effects no one knows about -- AFAIK it's only been tested on a single system yet (mine), with only a single way of building ports as non-root while there's many more systems out there that are all set up differently. So I guess it would help if people who want this feature simply test the patch for a while and then report whether it works for them or not. And people who don't want the patch test it with their standard procedure to see if it messes things up for them or not. Just saying that you want it or don't want it without testing whether it actually works or breaks anything for you won't help Doug make the decision whether to adopt this patch or not. He needs proper feedback to make an informed decision. Exactly what I am doing with no shame. :-) I had to jump in to push people to give a very good reason other than 'me too'. I have yet to see a very good reason other than 'just because I want to'. It looks like it works. ;-) Cheers, Mezz I need proper feedback to fix any issues that might come up for other people using this patch. So if you have the time, please test it, no matter if you want to use the -S flag or not. Here's my own take again: I have been using the patch in its current form for 2 or 3 weeks during which I updated ports about three or four times. I haven't noticed any regressions so far. In my already described setup it even made it through the big gnome-2.18-2.20 update without any issues, except for one issue unrelated to portmaster which has already been filed. See http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/117976 I also found an issue in devel/ncurses while testing the patch, not related to portmaster either, but to the port not heeding WRKDIRPREFIX correctly. This bug has since been fixed: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/117643 -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] portmaster with SU_CMD
On Mon, Nov 12, 2007 at 10:24:19AM -0800, Garrett Cooper wrote: Greg Minshall wrote: i'd add my two cents for being able to do builds without running as root. Building as non-root user and then installing as root has its caveats I would think.. Pro: - Compiling as a non-root user and then installing as root reduces the security risk of a possible exploit in the portmaster / base system infrastructure. I myself am not hoping that not compiling as root will save my system from being cracked by Mr. Malicious, and I would not advise anyone to believe in such illusions. Think about it, make install is still vulnerable :) Compiling ports as non-root simply follows from the principle of least authority. I hope it will save me from bugs in some makefile or configure script touching files on my system it should not be touching. I could do it with portupgrade, it never hurt, now I can do it with portmaster, too. Con: - People with sufficient permissions (possibly caused by bad umask settings) but without root access, can modify the binaries / recompile files to suit their needs prior to them being installed as root Indeed. Of course, on a multiuser system you should take proper precautions before using portmaster with -S. I'd like to stress again that the patch does not stop anyone from simply running portmaster entirely as root if desired. It's just like the -s switch portupgrade has had for ages. I wonder if there was a similar discussion about that switch when it was first introduced... -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgptwWu154Wu9.pgp Description: PGP signature
apache 2.x + php 5.x http post temporary file name non-randomness
There seems to be a bug (or feature?) somewhere that limits the number
of unique temporary file names used when storing temporary files that
are uploaded by posting a form. Looking through my webserver logs of
11 file uploads, I find no more than 495 unique temporary file names
which are being reused again and again.
(File name example: /var/tmp/phpzzJuIt)
I think PHP is supposed to use mkstemp(). From the mkstemp(3) manual:
The number of unique file names mktemp() can return depends on the
number of `Xs' provided; six `Xs' will result in mktemp() selecting one
of 56800235584 (62 ** 6) possible temporary file names.
PHP uses 6 Xs. This makes the low number of observed unique file names
(495) a bit disappointing.
I have the same problem on the following 2 combinations:
amd64 + freebsd 6.0 + php 5.1 + apache 2.0 prefork MPM (+ several php
extensions)
amd64 + freebsd 6.2 + php 5.2 + apache 2.2 prefork MPM (+ several php
extensions)
Does anyone know what causes this and/or how to fix it?
The attached patch for php 5.2.4 Works For Me(tm), but I'd rather have
the problem fixed at it's source than working around it...
--
Erik
--- main/php_open_temporary_file.c.orig Mon Nov 12 18:46:03 2007
+++ main/php_open_temporary_file.c Mon Nov 12 18:49:30 2007
@@ -101,6 +101,7 @@
char cwd[MAXPATHLEN];
cwd_state new_state;
int fd = -1;
+ struct timeval tval;
#ifndef HAVE_MKSTEMP
int open_flags = O_CREAT | O_TRUNC | O_RDWR
#ifdef PHP_WIN32
@@ -131,7 +132,8 @@
trailing_slash = /;
}
- if (spprintf(opened_path, 0, %s%s%sXX, new_state.cwd,
trailing_slash, pfx) = MAXPATHLEN) {
+ gettimeofday(tval, NULL);
+ if (spprintf(opened_path, 0, %s%s%s_%d_%d_XX, new_state.cwd,
trailing_slash, pfx, tval.tv_sec, tval.tv_usec) = MAXPATHLEN) {
efree(opened_path);
free(new_state.cwd);
return -1;
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stunnel not working
On Mon, 12 Nov 2007 16:02:59 +0200 Peter Pentchev [EMAIL PROTECTED] wrote: On Thu, Nov 08, 2007 at 11:59:15PM +0100, Pav Lucistnik wrote: RW p??e v ?t 08. 11. 2007 v 22:06 +: Stunnel doesn't seem to be working correctly on my 6.2 desktop, I'm getting the following in /var/log/messages, and I have no stunnel process [snip] stunnel: LOG3[926:134660096]: local socket: Protocol not supported (43) stunnel: warning: can't get client address: Bad file descriptor [snip] On my machines, I noticed 4.21 no longer understands domain names in connect statement of configuration file. Try replacing that secure.new.seasynews.com by it's IP. Could you try the attached patch? According to the stunnel developers, it should fix the problem. It has been submitted to the portmgr@ team for commit approval. I apologize for the apparently insufficient testing before the port update to version 4.21. I tried it and it didn't solve my problem, but I rebuilt my kernel with IPv6 and now it works. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: apache 2.x + php 5.x http post temporary file name non-randomness
On Mon, Nov 12, 2007 at 09:21:56PM +0100, Erik Stian Tefre wrote: There seems to be a bug (or feature?) somewhere that limits the number of unique temporary file names used when storing temporary files that are uploaded by posting a form. Looking through my webserver logs of 11 file uploads, I find no more than 495 unique temporary file names which are being reused again and again. (File name example: /var/tmp/phpzzJuIt) I think PHP is supposed to use mkstemp(). From the mkstemp(3) manual: The number of unique file names mktemp() can return depends on the number of `Xs' provided; six `Xs' will result in mktemp() selecting one of 56800235584 (62 ** 6) possible temporary file names. PHP uses 6 Xs. This makes the low number of observed unique file names (495) a bit disappointing. It sounds as if the limitation in range (56800235584 vs. 495) may be due to what's considered a permittable character in a filename. I'm betting the function ANDs the per-byte results, requiring them to be within [0-9A-Za-z]. That's (26+26+10)^6. Based on that, it sounds as if there's no easy way to increase the entropy. I'm not really sure I'd use gettimeofday() for extending this, though. If I remember correctly (someone please correct me if I'm wrong): * The clock is not a good source of randomness because it's predictable (although in this case it's not the sole source of entropy) * gettimeofday() is an expensive call due to communication with the RTC. I'm left believing that adding more X's to the path passed to mkstemp() would be a better solution, and a more compatible one. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
