Re: dependency of magic.h
On 2018/12/11 21:40, Christos Zoulas wrote:
In article <944c79fd-4414-1936-67f4-03ec228bd...@execsw.org>,
Masanobu SAITOH wrote:
Hi.
While doing "./build.sh -j16 distribution", I got "unterminated ifdef"
error in magic.h(src/external/bsd/file/lib). When I got this compile error,
I checked the file and the #ifdef...#endif was consistent. It seems the
compiler saw unfinished magic.h. Have you ever seen this error before?
src/external/bsd/file/lib/Makefile has "${ALLOBJS}: magic.h".
I'm not familiar with Makefile, but I suspect it should be replaced with
"DPSRCS+=magic.h".
Right?
It's hard to reproduce the problem, so I can't verify the change works
or not...
Why don't you change it anyway. I think I've seen this before too.
christo
Committed now!
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
daily CVS update output
Updating src tree: P src/bin/sh/main.c P src/bin/sh/parser.c P src/bin/sh/parser.h P src/bin/sh/sh.1 P src/lib/libkvm/kvm_getloadavg.3 P src/share/man/man4/shmif.4 P src/sys/arch/aarch64/aarch64/cpuswitch.S P src/sys/arch/aarch64/aarch64/genassym.cf P src/sys/arch/amd64/conf/GENERIC P src/sys/arch/amd64/conf/INSTALL P src/sys/arch/arm/include/cpufunc.h P src/sys/arch/hpcsh/dev/hd64461/hd64461uart.c P src/sys/arch/i386/conf/GENERIC P src/sys/arch/i386/conf/INSTALL P src/sys/arch/mips/ingenic/ingenic_com.c P src/sys/arch/mips/rmi/rmixl_com.c P src/sys/dev/ata/ata.c P src/sys/dev/ic/com.c P src/sys/dev/ic/comvar.h P src/sys/dev/marvell/com_mv.c P src/sys/dev/usb/if_mue.c P src/sys/dev/usb/if_muereg.h P src/sys/dev/usb/if_muevar.h P src/sys/dev/usb/ucom.c U src/sys/net/ether_sw_offload.c U src/sys/net/ether_sw_offload.h P src/sys/net/files.net P src/sys/net/if.c P src/sys/net/if_bridge.c P src/sys/net/if_bridgevar.h P src/sys/netinet/in_offload.c P src/sys/netinet/in_offload.h P src/sys/netinet/ip_output.c P src/sys/netinet/sctp_pcb.c P src/sys/netinet6/in6_offload.c P src/sys/netinet6/in6_offload.h P src/sys/netinet6/ip6_output.c P src/sys/rump/dev/lib/libnetsmb/netsmb_user.c P src/sys/rump/dev/lib/libpci/rumpdev_bus_dma.c P src/sys/rump/dev/lib/libpci/rumpdev_bus_space.c P src/sys/rump/dev/lib/libscsipi/scsipi_component.c P src/sys/rump/dev/lib/libucom/ucom_at_usb.c P src/sys/rump/dev/lib/libugenhc/ugenhc_user.c P src/sys/rump/dev/lib/libulpt/ulpt_at_usb.c P src/sys/rump/dev/lib/libumass/umass_component.c P src/sys/rump/dev/lib/libwscons/wscons_component.c P src/sys/rump/kern/lib/libsys_cygwin/rump_cygwin_compat.c P src/sys/rump/kern/lib/libsys_cygwin/sys_cygwin_component.c P src/sys/rump/kern/lib/libsys_linux/linux_rump.c P src/sys/rump/kern/lib/libsys_linux/sys_linux_component.c P src/sys/rump/kern/lib/libsys_sunos/rump_sunos_compat.c P src/sys/rump/kern/lib/libsys_sunos/sys_sunos_component.c P src/sys/rump/librump/rumpkern/arch/generic/rump_generic_directmap.c P src/sys/rump/librump/rumpnet/net_stub.c P src/sys/rump/net/lib/libnet/Makefile P src/sys/rump/net/lib/libpppoe/pppoe_component.c P src/sys/rump/net/lib/libshmif/if_shmem.c P src/sys/rump/net/lib/libshmif/shmif_user.c P src/sys/rump/net/lib/libsockin/sockin_user.c P src/sys/rump/net/lib/libvirtif/virtif_user.c P src/tests/net/if_vlan/t_vlan.sh Updating xsrc tree: Killing core files: Updating release-7 src tree (netbsd-7): P bin/sh/parser.c U doc/CHANGES-7.3 Updating release-7 xsrc tree (netbsd-7): Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.1 P sys/dev/vnd.c Updating release-8 xsrc tree (netbsd-8): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 52219217 Dec 12 03:09 ls-lRA.gz
Re: MSI/MSI-X implementation and interrupt handling on i386/amd64
Moving this to port-amd64 (bcced current-users@ for reference) Le mar. 11 déc. 2018 à 04:34, Kengo NAKAHARA a écrit : > I mention some old Athlon 64 series (before socket AM2) do not support > cmpxchg16b instruction. That would affect rewriting spllower to support > 64 bit interrupt bitmask. Indeed, need to do runtime check for cmpxchg16b support. I'm investigating an initial solution which will keep the ipending+ilevel still as 64-bit quantity suitable for cmpxchg8b, using 4 bits for the ilevel and remaining 60 for ipending. The 60/4 split with cmpxchg8b should work for i386 too. Besides spl.S/vector.S, so far I only found one place using atomic write on the ipending - clearing interrupt from ipending in intr disestablish. This one can easily change to just block all interrupts during the clearing, since this is not performance critical path. Jaromir
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2018.12.11.16.45.49 martin src/sys/dev/usb/if_mue.c,v 1.23 2018.12.11.16.52.49 maya src/sys/arch/amd64/conf/GENERIC,v 1.511 2018.12.11.16.52.49 maya src/sys/arch/amd64/conf/INSTALL,v 1.94 2018.12.11.16.52.49 maya src/sys/arch/i386/conf/GENERIC,v 1.1196 2018.12.11.16.52.49 maya src/sys/arch/i386/conf/INSTALL,v 1.335 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2018.12.html#2018.12.11.16.52.49
NetBSD Security Advisory 2018-009: bozohttpd can allow access to .htpasswd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 NetBSD Security Advisory 2018-009 = Topic: bozohttpd can allow access to .htpasswd Version:NetBSD-current: prior to 2018-11-22 NetBSD 8*: affected NetBSD 7.2*:affected NetBSD 7.1*:affected pkgsrc: bozohttpd package prior to 20181123 Severity: Remote access to encrypted passwords and usernames Fixed: NetBSD-current: November 21, 2018 NetBSD-8 branch:November 24, 2018 NetBSD-7-2 branch: November 24, 2018 NetBSD-7-1 branch: November 24, 2018 pkgsrc-current: bozohttpd-20181123 corrects this issue Please note that NetBSD releases prior to 7.1 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract Under certain circumstances bozohttpd(8) can be tricked into revealing the contents of certain special files. These special files are configuration files for bozohttpd(8) and include the standard .htpasswd file for HTTP Basic Authorisation (RFC-7617), which contains both a list of user names and their encrypted passwords. Technical Details = There were two problems in the handling of bozohttpd special files. The first was a missing check against .htpasswd itself in some cases, which would allow access to the encrypted passwords and username to be seen for the top-level directory. Any empty top-level directory name elided the check for any special files. All requests now check special files. The second was lack of short circuit when the error was detected. The error would be returned, but instead of closing the connection, the contents of the requested file was also returned. This was caused by not checking the return value of bozo_check_special_files(). This function is now marked with the "warn_unused_result" attribute. Solutions and Workarounds = Users of any bozohttpd(8) features using special files should be upgraded to bozohttpd 20181123 or later. There is no workaround except for not using these features, which may mean simply disabling parts of the served tree until the server is upgraded. Consider changing all the passwords used in the .htpasswd as they may be compromised. To apply a fixed version from a releng build, fetch a fitting base.tgz from nyftp.netbsd.org and extract the fixed binaries: cd /var/tmp ftp http://nyftp.netbsd.org/pub/NetBSD-daily/REL/BUILD/ARCH/binary/sets/base.tgz cd / tar xzpf /var/tmp/base.tgz ./usr/libexec/httpd with the following replacements: REL = the release version you are using BUILD = the source date of the build. 20181125* and later will fit ARCH = your system's architecture The following instructions describe how to upgrade your bozohttpd binaries by updating your source tree and rebuilding and installing a new version of bozohttpd. * NetBSD-current: Systems running NetBSD-current dated from before 2018-11-21 should be upgraded to NetBSD-current dated 2018-11-22 or later. The following files/directories need to be updated from the netbsd-current CVS branch (aka HEAD): src/libexec/httpd To update from CVS, re-build, and re-install bozohttpd: # cd src # cvs update -r netbsd-8 -d -P src/libexec/httpd # cd src/libexec/httpd # make USETOOLS=no cleandir dependall # make USETOOLS=no install * NetBSD 8.*: Systems running NetBSD 8.* sources dated from before 2018-11-24 should be upgraded from NetBSD 8.* sources dated 2018-11-25 or later. The following files/directories need to be updated from the netbsd-8 branche: src/libexec/httpd To update from CVS, re-build, and re-install bozohttpd: # cd src # cvs update -r netbsd-8 -d -P src/libexec/httpd # cd src/libexec/httpd # make USETOOLS=no cleandir dependall # make USETOOLS=no install * NetBSD 7.*: Systems running NetBSD 7.* sources dated from before 2018-11-24 should be upgraded from NetBSD 7.* sources dated 2018-11-25 or later. The following files/directories need to be updated from the netbsd-7, netbsd-7-2 or netbsd-7-1 branches: src/libexec/httpd To update from CVS, re-build, and re-install bozohttpd: # cd src # cvs update -r -d -P src/libexec/httpd # cd src/libexec/httpd # make USETOOLS=no cleandir dependall # make USETOOLS=no install Thanks To = Thanks to JP for reporting this issue and helping find the problematic
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2018.12.11.11.00.18.
An extract from the build.sh output follows:
cd /tmp/bracket/build/2018.12.11.11.00.18-i386/src/sys/arch/i386/conf &&
/tmp/bracket/build/2018.12.11.11.00.18-i386/tools/bin/nbconfig -s
/tmp/bracket/build/2018.12.11.11.00.18-i386/src/sys -U DEBUG -b
/tmp/bracket/build/2018.12.11.11.00.18-i386/obj/sys/arch/i386/compile/INSTALL_XEN3PAE_DOMU
INSTALL_XEN3PAE_DOMU
--- kern-LEGACY ---
cd /tmp/bracket/build/2018.12.11.11.00.18-i386/src/sys/arch/i386/conf &&
/tmp/bracket/build/2018.12.11.11.00.18-i386/tools/bin/nbconfig -s
/tmp/bracket/build/2018.12.11.11.00.18-i386/src/sys -U DEBUG -b
/tmp/bracket/build/2018.12.11.11.00.18-i386/obj/sys/arch/i386/compile/LEGACY
LEGACY
--- kern-MONOLITHIC ---
cd /tmp/bracket/build/2018.12.11.11.00.18-i386/src/sys/arch/i386/conf &&
/tmp/bracket/build/2018.12.11.11.00.18-i386/tools/bin/nbconfig -s
/tmp/bracket/build/2018.12.11.11.00.18-i386/src/sys -U DEBUG -b
/tmp/bracket/build/2018.12.11.11.00.18-i386/obj/sys/arch/i386/compile/MONOLITHIC
MONOLITHIC
--- kern-XEN3PAE_DOM0 ---
cd /tmp/bracket/build/2018.12.11.11.00.18-i386/src/sys/arch/i386/conf &&
/tmp/bracket/build/2018.12.11.11.00.18-i386/tools/bin/nbconfig -s
/tmp/bracket/build/2018.12.11.11.00.18-i386/src/sys -U DEBUG -b
/tmp/bracket/build/2018.12.11.11.00.18-i386/obj/sys/arch/i386/compile/XEN3PAE_DOM0
XEN3PAE_DOM0
--- kern-XEN3PAE_DOMU ---
cd /tmp/bracket/build/2018.12.11.11.00.18-i386/src/sys/arch/i386/conf &&
/tmp/bracket/build/2018.12.11.11.00.18-i386/tools/bin/nbconfig -s
/tmp/bracket/build/2018.12.11.11.00.18-i386/src/sys -U DEBUG -b
/tmp/bracket/build/2018.12.11.11.00.18-i386/obj/sys/arch/i386/compile/XEN3PAE_DOMU
XEN3PAE_DOMU
--- distrib-dirs ---
cd /tmp/bracket/build/2018.12.11.11.00.18-i386/src/etc/mtree &&
/tmp/bracket/build/2018.12.11.11.00.18-i386/tools/bin/nbmake distrib-dirs
--- check_DESTDIR ---
--- NetBSD.dist.tmp ---
/tmp/bracket/build/2018.12.11.11.00.18-i386/tools/bin/nbcat
/tmp/bracket/build/2018.12.11.11.00.18-i386/src/etc/mtree/NetBSD.dist.base
/tmp/bracket/build/2018.12.11.11.00.18-i386/src/etc/mtree/NetBSD.dist.tests
/tmp/bracket/build/2018.12.11.11.00.18-i386/src/etc/mtree/NetBSD.dist.dtrace >
NetBSD.dist.tmp
--- NetBSD.dist ---
cmp -s NetBSD.dist.tmp NetBSD.dist || { echo "Updating NetBSD.dist"; mv
NetBSD.dist.tmp NetBSD.dist; }
--- snap_pre ---
--- kern-INSTALL ---
INSTALL:21: `nouveau*' not defined
*** Stop.
*** [kern-INSTALL] Error code 1
nbmake[1]: stopped in /tmp/bracket/build/2018.12.11.11.00.18-i386/src/etc
The following commits were made between the last successful build and
the failed build:
2018.12.11.11.00.18 maya src/sys/arch/amd64/conf/GENERIC,v 1.510
2018.12.11.11.00.18 maya src/sys/arch/i386/conf/GENERIC,v 1.1195
Log files can be found at:
http://releng.NetBSD.org/b5reports/i386/commits-2018.12.html#2018.12.11.11.00.18
Re: dependency of magic.h
In article <944c79fd-4414-1936-67f4-03ec228bd...@execsw.org>,
Masanobu SAITOH wrote:
> Hi.
>
> While doing "./build.sh -j16 distribution", I got "unterminated ifdef"
>error in magic.h(src/external/bsd/file/lib). When I got this compile error,
>I checked the file and the #ifdef...#endif was consistent. It seems the
>compiler saw unfinished magic.h. Have you ever seen this error before?
>
> src/external/bsd/file/lib/Makefile has "${ALLOBJS}: magic.h".
>I'm not familiar with Makefile, but I suspect it should be replaced with
>"DPSRCS+=magic.h".
>
> Right?
>
> It's hard to reproduce the problem, so I can't verify the change works
>or not...
Why don't you change it anyway. I think I've seen this before too.
christo
dependency of magic.h
Hi.
While doing "./build.sh -j16 distribution", I got "unterminated ifdef"
error in magic.h(src/external/bsd/file/lib). When I got this compile error,
I checked the file and the #ifdef...#endif was consistent. It seems the
compiler saw unfinished magic.h. Have you ever seen this error before?
src/external/bsd/file/lib/Makefile has "${ALLOBJS}: magic.h".
I'm not familiar with Makefile, but I suspect it should be replaced with
"DPSRCS+=magic.h".
Right?
It's hard to reproduce the problem, so I can't verify the change works
or not...
--
---
SAITOH Masanobu (msai...@execsw.org
msai...@netbsd.org)
