Re: fingerd bug isn't
On 2014/11/19 22:32, Ted Unangst wrote: I don't think this qualifies as a bug. Using the wrong client is user error. fingerd should not be responsible for filtering anything you shouldn't send it. That makes much more sense than adding the same text to smtpd, httpd, bgpd, etc. :-) OK.
64-bit PCI bridge support: testers needed
Hi All,
dlg@ managed to get access to a machine that actually uses 64-bit PCI
addresses behind a bridge. This triggered some bugs in the so far
untested code. Quelle suprprise!
I'd appreciate it if some people can verify that this doesn't break
other systems. In particular I'm looking for testers on server-type
machines, both i386 and amd64.
Thanks,
Mark
Index: pci.c
===
RCS file: /cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.106
diff -u -p -r1.106 pci.c
--- pci.c 26 Oct 2014 16:18:42 - 1.106
+++ pci.c 20 Nov 2014 09:04:51 -
@@ -936,6 +936,12 @@ pci_reserve_resources(struct pci_attach_
blr = pci_conf_read(pc, tag, PPB_REG_PREFMEM);
base = (blr 0xfff0) 16;
limit = (blr 0xfff0) | 0x000f;
+#ifdef __LP64__
+ blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFBASE_HI32);
+ base |= ((uint64_t)blr) 32;
+ blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFLIM_HI32);
+ limit |= ((uint64_t)blr) 32;
+#endif
if (limit base)
size = (limit - base + 1);
else
Index: ppb.c
===
RCS file: /cvs/src/sys/dev/pci/ppb.c,v
retrieving revision 1.59
diff -u -p -r1.59 ppb.c
--- ppb.c 15 Sep 2014 14:22:07 - 1.59
+++ ppb.c 20 Nov 2014 09:04:51 -
@@ -261,7 +261,7 @@ ppbattach(struct device *parent, struct
name = malloc(32, M_DEVBUF, M_NOWAIT);
if (name) {
snprintf(name, 32, %s pcimem, sc-sc_dev.dv_xname);
- sc-sc_memex = extent_create(name, 0, 0x,
+ sc-sc_memex = extent_create(name, 0, (u_long)-1L,
M_DEVBUF, NULL, 0, EX_NOWAIT | EX_FILLED);
extent_free(sc-sc_memex, sc-sc_membase,
sc-sc_memlimit - sc-sc_membase + 1,
@@ -273,7 +273,7 @@ ppbattach(struct device *parent, struct
blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFMEM);
sc-sc_pmembase = (blr 0xfff0) 16;
sc-sc_pmemlimit = (blr 0xfff0) | 0x000f;
-#ifdef __LP64__/* XXX because extents use long... */
+#ifdef __LP64__
blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFBASE_HI32);
sc-sc_pmembase |= ((uint64_t)blr) 32;
blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFLIM_HI32);
Re: patch: tedu sccs support
On Wed, Nov 19, 2014 at 10:02:33PM -0500, Ted Unangst wrote: Are we still tracking upstream patch in any way? I think we've diverged in a few places, but there still is an upstream, yes? I don't think so. Looking at the past, the first version was written by Larry Wall who licensed it to FSF in GPL and to BSD in, well, BSD license. The README's commit states: patch(1) is now free, thanks Larry! Which means that there are at least two license-incompatible versions, the GNU patch and the BSD patch. As we can't use the former, let's look at the latter: FreeBSD stays in sync with our implementation. DragonflyBSD stays in sync with FreeBSD. NetBSD stays in sync with DragonflyBSD/FreeBSD. So, if there is any form of upstream among the larger BSDs, it's our implementation. GNU patch and our patch are kinda sibblings, yet GNU patch has more features than our patch has. The patches I've sent lately mostly apply to our patch only, but there are also bugs that hit the GNU patch version (and some that are exclusive to GNU patch, like using off_t for indexing memory). I've sent one larger diff to GNU patch and got asked if I would want to sign a contributor agreement, but no... I'm not interested in that. So before I send these common bug fixes to them, I would like to have them published in our patch, first. So they are clearly licensed in our terms and there is no further discussion about it. So whoever reads this: Reviewing my diffs would help me to make faster progress. Will have quite some time for patch development this week and next one, so the amount of diffs will be very likely higher than reviewing can happen. But every small review helps. :) Tobias
mandoc.db(5) names.bits
Hi Jason, Jason McIntyre wrote on Thu, Nov 20, 2014 at 06:34:45AM -0700: CVSROOT: /cvs Module name: src Changes by: j...@cvs.openbsd.org2014/11/20 06:34:45 Modified files: lib/libevent : Makefile Log message: put MLINKS in the order they appear in the man page, so i don;t go blind trying to check what's missing; No objection whatsoever, keeping the Makefiles clean is always good. Just mentioning a different approach in case anybody is interested - this got more powerful with some of my latest commits and is partly documented in mandoc.db(5): $ cd /usr/src/lib/libevent/ $ make cleandir $ cvs up -dP $ make obj $ make depend $ make $ sudo make install $ sudo makewhatis /usr/share/man $ alias qm='sqlite3 /usr/share/man/mandoc.db' # query mandoc.db $ qm 'select * from names where name=evbuffer_new;' 30|evbuffer_new|878 $ qm 'select * from names where pageid=878 and bits!=18;' 30|evbuffer_new|878 $ qm 'select * from names where name=event;' 16|event|877 $ qm 'select * from names where pageid=877 and bits!=18;' 16|event|877 30|event_init|877 Looks good now. The bits from /usr/src/usr.bin/mandoc/mansearch.h in the order of decreasing precedence for the new man(1) are: 16 file name (only this one is used by the old man(1)) 8 page header line (from the .Dt macro) 4 first .Nm entry in the NAME section 2 any .Nm entry in the NAME section 1 any .Nm entry in the SYNOPSIS section Right now, .Fo and .Fn in the SYNOPSIS do not yet set bit 1, but that's on my todo list. So, consistent values are: 31 (Christmas tree) for the primary page name 19 (= ~(8+4))for secondary page names Anything else is suspicious. This already works quite well for mdoc(7) pages. Regarding man(7) and cat pages, there are still some items on my todo list. Yours, Ingo
Re: mandoc.db(5) names.bits
On Thu, Nov 20, 2014 at 03:51:36PM +0100, Ingo Schwarze wrote: Hi Jason, Jason McIntyre wrote on Thu, Nov 20, 2014 at 06:34:45AM -0700: CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org2014/11/20 06:34:45 Modified files: lib/libevent : Makefile Log message: put MLINKS in the order they appear in the man page, so i don;t go blind trying to check what's missing; No objection whatsoever, keeping the Makefiles clean is always good. Just mentioning a different approach in case anybody is interested - this got more powerful with some of my latest commits and is partly documented in mandoc.db(5): $ cd /usr/src/lib/libevent/ $ make cleandir $ cvs up -dP $ make obj $ make depend $ make $ sudo make install $ sudo makewhatis /usr/share/man $ alias qm='sqlite3 /usr/share/man/mandoc.db' # query mandoc.db $ qm 'select * from names where name=evbuffer_new;' 30|evbuffer_new|878 $ qm 'select * from names where pageid=878 and bits!=18;' 30|evbuffer_new|878 $ qm 'select * from names where name=event;' 16|event|877 $ qm 'select * from names where pageid=877 and bits!=18;' 16|event|877 30|event_init|877 Looks good now. The bits from /usr/src/usr.bin/mandoc/mansearch.h in the order of decreasing precedence for the new man(1) are: 16 file name (only this one is used by the old man(1)) 8 page header line (from the .Dt macro) 4 first .Nm entry in the NAME section 2 any .Nm entry in the NAME section 1 any .Nm entry in the SYNOPSIS section Right now, .Fo and .Fn in the SYNOPSIS do not yet set bit 1, but that's on my todo list. So, consistent values are: 31 (Christmas tree) for the primary page name 19 (= ~(8+4))for secondary page names Anything else is suspicious. This already works quite well for mdoc(7) pages. Regarding man(7) and cat pages, there are still some items on my todo list. Yours, Ingo better still, you had a diff that made MLINKS redundant. that's what i want. jmc
Re: LibreSSL: GOWindows support
On Tue, Nov 11, 2014 at 8:41 AM, Brent Cook bust...@gmail.com wrote: I gave the openbsd src patches a spin last night. I wonder if there's a way we could instead coerce mingw into pretending to be more POSIX by way of header tricks in the portable tree: Hi Dongsheng, Thanks for doing the initial test port work and posting your fork. I gave the concept of 'coerce win32 support via stupid header tricks' a spin, and the result of that is here: https://github.com/busterb/portable/commits/win32-minimal This basically intercepts all of the BSD headers unavailable in Win32, doing the bulk of the required fixups passively through preprocessor abuse. Note the fun 'posix_close', for instance. I'm almost sure this has bugs, but tossing up as perhaps an example of Cunningham's law. While this whole thing feels a little wrong, software on Windows that uses 'int' interchangeably with SOCKET already sort of dooms it by design, especially on Win64. Hopefully nobody is seriously using BIO's builtin socket functions in the first place (they were already pretty lame on POSIX systems). The minimal pile of upstream portability changes that this needed to work are below, and there are not a lot. I am not sure if 'ui_openssl.c' takes the cake as the most out-of-place thing to find in a crypto library. I also wonder what software would break if it were moved into openssl(1) directly: https://github.com/busterb/openbsd/commits/win32-minimal The result passes 39/40 unit tests so far - still gotta look at pq_test. I took the poll.c from your fork and built it into openssl(1) only. However, asprintf worked without any extra effort thanks to recent mingw having a native version available (though I should probably look at how that is actually implemented). The idea of needing 2 different asprintf shims seems rather depressing. I didn't actually incorporate the syslog compat functions, and am debating if these should really just be no-op shims for Win32 - again, if someone is using these on Windows, they are not using event log properly, and will get some pretty ugly-looking logs. I tested and built on Ubuntu 14.04 with wine and the mingw-w64 package, using this config line: CC=i686-w64-mingw32-gcc ./configure --host=i686-w64-mingw32 Comments? - Brent
[PATCH]rcs: write usage function pointer always the same way
Hi tech, I think it's more readable if the usage() function pointer will always be written the same way. fritjof Index: rlog.c === RCS file: /cvs/src/usr.bin/rcs/rlog.c,v retrieving revision 1.69 diff -u -p -r1.69 rlog.c --- rlog.c 10 Oct 2014 08:15:25 - 1.69 +++ rlog.c 20 Nov 2014 15:54:28 - @@ -136,7 +136,7 @@ rlog_main(int argc, char **argv) timezone_flag = rcs_optarg; break; default: - (usage()); + (usage)(); } } pgpnNScZfk7ra.pgp Description: PGP signature
Re: mandoc.db(5) names.bits
Hi Jason, Jason McIntyre wrote on Thu, Nov 20, 2014 at 03:00:49PM +0001: better still, you had a diff that made MLINKS redundant. that's what i want. Jajaja! :-) But before i can put that in, i want to check off the list of things that i already know might go wrong. I don't want people ending up with not getting shown the pages they request, or being shown pages they don't request. Once the old man(1) is gone, that would really be inconvenient. After my list becomes empty, we still need a public testing phase, and not too close to release. So i think it won't make 5.7. What i have shown here is part of the way to get there, though. Yours, Ingo
Status on porting Rust to OpenBSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everybody, In my free time over the last few weeks I have been attempting to cross-compile the rust compiler using the same method that was used to add support for Dragonfly BSD. I started with the scripts from the Dragonfly effort and fixed them up to work with OpenBSD and Linux. All of my code and documentation is here: https://github.com/dhuseby/rust-cross-openbsd Currently, I'm stuck on stage 3. The part where all of the object files from both OpenBSD and Linux need to be linked together into an OpenBSD executable. I'm pretty certain the reason stage 3 doesn't complete is because of the old linker on OpenBSD. At the bottom of the README.md file I discuss some options on what to try next. I have also included build logs of all stages so that other people can see the output without jumping through all of the hoops I did. My options at this point are this: 1. Use the same version compiler/assembler/linker on Linux and OpenBSD so that the object files will be more compatible. Hopefully this will allow stage 3 to finish linking. 2. Apply my OpenBSD target patches to Rust and build a Linux rust compiler that knows how to target OpenBSD. Then I use Linux emulation on OpenBSD to run it to compile itself from scratch. 3. Figure out a way to get a newer linker working on OpenBSD. Thoughts? I'm looking for feedback. Are my assumptions and ideas right for why stage 3 doesn't successfully link? Any other ideas on what I can try? - --dave -BEGIN PGP SIGNATURE- iF4EAREIAAYFAlRtZBMACgkQvt/JvmUQuOkWZgD+PWr5ZmE6ypdQQuLgo1eHddGl e0LUUJi8CyvYpyNqUEMA/1EJCC6Z6mCeM11oGKhHxLdChv3qVjKg/6jXAoEIPynh =GD3X -END PGP SIGNATURE- 0x6510B8E9.asc Description: application/pgp-keys 0x6510B8E9.asc.sig Description: PGP signature
Re: fts: optimize by using fstatat instead of lstat
On Wed, 19 Nov 2014 20:30:04 -0800, Philip Guenther wrote: Committed, which leads to the next diff: use O_CLOEXEC on all internal fds, O_DIRECTORY when opening a directory other than ., and drop the 3rd argument to open() as unnecessary when O_CREAT isn't used. Looks good to me. OK millert@ - todd
Re: Status on porting Rust to OpenBSD
On Wed, Nov 19, 2014 at 19:46, Dave Huseby wrote: 3. Figure out a way to get a newer linker working on OpenBSD. binutils-2.17 is in the src tree at gnu/usr.bin/binutils-2.17. It's not enabled because it doesn't always work right, but at one point there was a plan to switch to it precisely because newer projects need it. You can try using that, but getting it to coexist with the regular binutils may be difficult.
Re: Status on porting Rust to OpenBSD
On Wed, Nov 19, 2014 at 07:46:27PM -0800, Dave Huseby wrote: Hi everybody, In my free time over the last few weeks I have been attempting to cross-compile the rust compiler using the same method that was used to add support for Dragonfly BSD. I started with the scripts from the Dragonfly effort and fixed them up to work with OpenBSD and Linux. All of my code and documentation is here: https://github.com/dhuseby/rust-cross-openbsd Currently, I'm stuck on stage 3. The part where all of the object files from both OpenBSD and Linux need to be linked together into an OpenBSD executable. I'm pretty certain the reason stage 3 doesn't complete is because of the old linker on OpenBSD. At the bottom of the README.md file I discuss some options on what to try next. I have also included build logs of all stages so that other people can see the output without jumping through all of the hoops I did. My options at this point are this: 1. Use the same version compiler/assembler/linker on Linux and OpenBSD so that the object files will be more compatible. Hopefully this will allow stage 3 to finish linking. 2. Apply my OpenBSD target patches to Rust and build a Linux rust compiler that knows how to target OpenBSD. Then I use Linux emulation on OpenBSD to run it to compile itself from scratch. Linux emul only works on OpenBSD/i386 iirc.. Did you try communicating with the dfly developer to exchange ideas on the issues you encounter, and the upstream developers ? Anyway, your effort is appreciated. I'll port servo on top as soon as rust is working :) Landry pgpj96M1eCILW.pgp Description: PGP signature
Re: fingerd bug isn't
On Wed, 19 Nov 2014 22:32:59 -0500, Ted Unangst wrote: I don't think this qualifies as a bug. Using the wrong client is user error. fingerd should not be responsible for filtering anything you shouldn't send it. OK millert@ (who wonders how many people even know what a TIP is these days) - todd
Re: vi: global state cleanup
On Wed, Nov 12, 2014 at 07:34:28PM +0100, Martin Natano wrote:
The 'struct _gs' type (aka. GS) contains pointers to screen interface
functions, which are set by cl_func_std(), but this mechanism isn't
necessary anymore, because the other frontends (tk, motif, ipc) have
been removed. The only remaining frontend is curses and can be used
directly. The only exception is the scr_msg function pointer, which is
used by the perl api (disabled by default) and thus must remain in GS.
Also, the tcl_interp, ip_private and tk_private fields are unused and
can be removed.
Below is an updated version of the patch, which applies cleanly to vi as
it is in CVS now. I killed scr_msg, because the last user (the perl api)
is now gone.
This diff is mostly a mechanical change from scr_* to cl_* (or vs_* in
the cases of scr_busy and scr_msg). The benefit is, that the global
state is used less, and the code should be more readable, as less
indirections are involved when a function is called. Does anyone want
to commit that?
See the diff below.
cheers,
natano
Index: cl/cl_funcs.c
===
RCS file: /cvs/src/usr.bin/vi/cl/cl_funcs.c,v
retrieving revision 1.17
diff -u -r1.17 cl_funcs.c
--- cl/cl_funcs.c 12 Nov 2014 16:29:04 - 1.17
+++ cl/cl_funcs.c 20 Nov 2014 20:36:40 -
@@ -466,14 +466,12 @@
int
cl_rename(SCR *sp, char *name, int on)
{
- GS *gp;
CL_PRIVATE *clp;
char *ttype;
- gp = sp-gp;
clp = CLP(sp);
- ttype = OG_STR(gp, GO_TERM);
+ ttype = OG_STR(sp-gp, GO_TERM);
/*
* XXX
Index: cl/cl_main.c
===
RCS file: /cvs/src/usr.bin/vi/cl/cl_main.c,v
retrieving revision 1.25
diff -u -r1.25 cl_main.c
--- cl/cl_main.c19 Nov 2014 03:42:40 - 1.25
+++ cl/cl_main.c20 Nov 2014 20:36:40 -
@@ -33,7 +33,6 @@
GS *__global_list; /* GLOBAL: List of screens. */
sigset_t __sigblockset;/* GLOBAL: Blocked
signals. */
-static void cl_func_std(GS *);
static CL_PRIVATE *cl_init(GS *);
static GS*gs_init(char *);
static void perr(char *, char *);
@@ -202,9 +201,6 @@
(void)close(fd);
}
- /* Initialize the list of curses functions. */
- cl_func_std(gp);
-
return (clp);
}
@@ -351,36 +347,6 @@
(void)sigaction(SIGINT, NULL, clp-oact[INDX_INT]);
(void)sigaction(SIGTERM, NULL, clp-oact[INDX_TERM]);
(void)sigaction(SIGWINCH, NULL, clp-oact[INDX_WINCH]);
-}
-
-/*
- * cl_func_std --
- * Initialize the standard curses functions.
- */
-static void
-cl_func_std(GS *gp)
-{
- gp-scr_addstr = cl_addstr;
- gp-scr_attr = cl_attr;
- gp-scr_baud = cl_baud;
- gp-scr_bell = cl_bell;
- gp-scr_busy = NULL;
- gp-scr_clrtoeol = cl_clrtoeol;
- gp-scr_cursor = cl_cursor;
- gp-scr_deleteln = cl_deleteln;
- gp-scr_event = cl_event;
- gp-scr_ex_adjust = cl_ex_adjust;
- gp-scr_fmap = cl_fmap;
- gp-scr_insertln = cl_insertln;
- gp-scr_keyval = cl_keyval;
- gp-scr_move = cl_move;
- gp-scr_msg = NULL;
- gp-scr_optchange = cl_optchange;
- gp-scr_refresh = cl_refresh;
- gp-scr_rename = cl_rename;
- gp-scr_screen = cl_screen;
- gp-scr_suspend = cl_suspend;
- gp-scr_usage = cl_usage;
}
/*
Index: cl/cl_read.c
===
RCS file: /cvs/src/usr.bin/vi/cl/cl_read.c,v
retrieving revision 1.19
diff -u -r1.19 cl_read.c
--- cl/cl_read.c12 Nov 2014 04:28:41 - 1.19
+++ cl/cl_read.c20 Nov 2014 20:36:40 -
@@ -128,12 +128,10 @@
{
struct termios term1, term2;
CL_PRIVATE *clp;
- GS *gp;
struct pollfd pfd[1];
input_t rval;
int nr, term_reset, timeout;
- gp = sp-gp;
clp = CLP(sp);
term_reset = 0;
@@ -205,7 +203,7 @@
* It's ugly that we wait on scripting file descriptors here, but it's
* the only way to keep from locking out scripting windows.
*/
- if (F_ISSET(gp, G_SCRWIN)) {
+ if (F_ISSET(sp-gp, G_SCRWIN)) {
if (sscr_check_input(sp))
goto err;
}
Index: common/gs.h
===
RCS file: /cvs/src/usr.bin/vi/common/gs.h,v
retrieving revision 1.13
diff -u -r1.13 gs.h
--- common/gs.h 20 Nov 2014 08:50:53 - 1.13
+++ common/gs.h 20 Nov 2014 20:36:40 -
@@ -40,13 +40,13 @@
u_int16_t flags;
};
-/* Action arguments to scr_exadjust(). */
+/* Action arguments to cl_ex_adjust(). */
typedef enum { EX_TERM_CE, EX_TERM_SCROLL } exadj_t;
-/* Screen attribute arguments to scr_attr(). */
+/* Screen attribute arguments to cl_attr(). */
typedef enum {
httpd errata
[on behalf of reyk]
Many people want to test the new httpd in OpenBSD 5.6; so we decided
to provide various improvements from -current for 5.6.
See the description below for more details.
untrusted comment: signature from openbsd 5.6 base private key
RWR0EANmo9nqhn3Gnfk2/2x+xII6do92zreKp/t5zOwfkVgsQAI4ZCPkWAazbbnWNV7Ptkle876f/kb6C2KuvnTqvwUItsyvogA=
OpenBSD 5.6 errata 9, Nov 18, 2014: httpd was developed very rapidly
in the weeks before 5.6 release, and it has a few flaws. It would be
nice to get these flaws fully remediated before the next release, and
that requires the community to want to use it. Therefore here is a
jumbo patch that brings in the most important fixes.
Apply patch using:
signify -Vep /etc/signify/openbsd-56-base.pub -x 009_httpd.patch.sig \
-m - | (cd /usr/src patch -p0)
Then build and install httpd:
cd /usr/src/usr.sbin/httpd
make obj
make
make install
Index: usr.sbin/httpd/config.c
===
RCS file: /cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.21
diff -u -p -r1.21 config.c
--- usr.sbin/httpd/config.c 6 Aug 2014 18:21:14 - 1.21
+++ usr.sbin/httpd/config.c 18 Nov 2014 15:02:54 -
@@ -223,7 +223,7 @@ config_getserver_config(struct httpd *en
#ifdef DEBUG
struct privsep *ps = env-sc_ps;
#endif
- struct server_config*srv_conf;
+ struct server_config*srv_conf, *parent;
u_int8_t*p = imsg-data;
u_intf;
@@ -233,18 +233,28 @@ config_getserver_config(struct httpd *en
IMSG_SIZE_CHECK(imsg, srv_conf);
memcpy(srv_conf, p, sizeof(*srv_conf));
+ /* Reset these variables to avoid free'ing invalid pointers */
+ serverconfig_reset(srv_conf);
+
+ TAILQ_FOREACH(parent, srv-srv_hosts, entry) {
+ if (strcmp(parent-name, srv_conf-name) == 0)
+ break;
+ }
+ if (parent == NULL)
+ parent = srv-srv_conf;
+
if (srv_conf-flags SRVFLAG_LOCATION) {
/* Inherit configuration from the parent */
f = SRVFLAG_INDEX|SRVFLAG_NO_INDEX;
if ((srv_conf-flags f) == 0) {
- srv_conf-flags |= srv-srv_conf.flags f;
- (void)strlcpy(srv_conf-index, srv-srv_conf.index,
+ srv_conf-flags |= parent-flags f;
+ (void)strlcpy(srv_conf-index, parent-index,
sizeof(srv_conf-index));
}
f = SRVFLAG_AUTO_INDEX|SRVFLAG_NO_AUTO_INDEX;
if ((srv_conf-flags f) == 0)
- srv_conf-flags |= srv-srv_conf.flags f;
+ srv_conf-flags |= parent-flags f;
f = SRVFLAG_SOCKET|SRVFLAG_FCGI;
if ((srv_conf-flags f) == SRVFLAG_FCGI) {
@@ -255,48 +265,48 @@ config_getserver_config(struct httpd *en
f = SRVFLAG_ROOT;
if ((srv_conf-flags f) == 0) {
- srv_conf-flags |= srv-srv_conf.flags f;
- (void)strlcpy(srv_conf-root, srv-srv_conf.root,
+ srv_conf-flags |= parent-flags f;
+ (void)strlcpy(srv_conf-root, parent-root,
sizeof(srv_conf-root));
}
f = SRVFLAG_FCGI|SRVFLAG_NO_FCGI;
if ((srv_conf-flags f) == 0)
- srv_conf-flags |= srv-srv_conf.flags f;
+ srv_conf-flags |= parent-flags f;
f = SRVFLAG_LOG|SRVFLAG_NO_LOG;
if ((srv_conf-flags f) == 0) {
- srv_conf-flags |= srv-srv_conf.flags f;
- srv_conf-logformat = srv-srv_conf.logformat;
+ srv_conf-flags |= parent-flags f;
+ srv_conf-logformat = parent-logformat;
}
f = SRVFLAG_SYSLOG|SRVFLAG_NO_SYSLOG;
if ((srv_conf-flags f) == 0)
- srv_conf-flags |= srv-srv_conf.flags f;
+ srv_conf-flags |= parent-flags f;
f = SRVFLAG_SSL;
- srv_conf-flags |= srv-srv_conf.flags f;
+ srv_conf-flags |= parent-flags f;
f = SRVFLAG_ACCESS_LOG;
if ((srv_conf-flags f) == 0) {
- srv_conf-flags |= srv-srv_conf.flags f;
+ srv_conf-flags |= parent-flags f;
(void)strlcpy(srv_conf-accesslog,
- srv-srv_conf.accesslog,
+ parent-accesslog,
sizeof(srv_conf-accesslog));
}
f = SRVFLAG_ERROR_LOG;
if ((srv_conf-flags f) == 0) {
- srv_conf-flags |= srv-srv_conf.flags f;
+
Re: httpd errata
This just made my day.
-Original Message-
From: Ted Unangst t...@tedunangst.com
Sent: 11/20/2014 6:26 PM
To: tech@openbsd.org tech@openbsd.org
Subject: httpd errata
[on behalf of reyk]
Many people want to test the new httpd in OpenBSD 5.6; so we decided
to provide various improvements from -current for 5.6.
See the description below for more details.
untrusted comment: signature from openbsd 5.6 base private key
RWR0EANmo9nqhn3Gnfk2/2x+xII6do92zreKp/t5zOwfkVgsQAI4ZCPkWAazbbnWNV7Ptkle876f/kb6C2KuvnTqvwUItsyvogA=
OpenBSD 5.6 errata 9, Nov 18, 2014: httpd was developed very rapidly
in the weeks before 5.6 release, and it has a few flaws. It would be
nice to get these flaws fully remediated before the next release, and
that requires the community to want to use it. Therefore here is a
jumbo patch that brings in the most important fixes.
Apply patch using:
signify -Vep /etc/signify/openbsd-56-base.pub -x 009_httpd.patch.sig \
-m - | (cd /usr/src patch -p0)
Then build and install httpd:
cd /usr/src/usr.sbin/httpd
make obj
make
make install
Index: usr.sbin/httpd/config.c
===
RCS file: /cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.21
diff -u -p -r1.21 config.c
--- usr.sbin/httpd/config.c 6 Aug 2014 18:21:14 - 1.21
+++ usr.sbin/httpd/config.c 18 Nov 2014 15:02:54 -
@@ -223,7 +223,7 @@ config_getserver_config(struct httpd *en
#ifdef DEBUG
struct privsep *ps = env-sc_ps;
#endif
- struct server_config*srv_conf;
+ struct server_config*srv_conf, *parent;
u_int8_t*p = imsg-data;
u_intf;
@@ -233,18 +233,28 @@ config_getserver_config(struct httpd *en
IMSG_SIZE_CHECK(imsg, srv_conf);
memcpy(srv_conf, p, sizeof(*srv_conf));
+ /* Reset these variables to avoid free'ing invalid pointers */
+ serverconfig_reset(srv_conf);
+
+ TAILQ_FOREACH(parent, srv-srv_hosts, entry) {
+ if (strcmp(parent-name, srv_conf-name) == 0)
+ break;
+ }
+ if (parent == NULL)
+ parent = srv-srv_conf;
+
if (srv_conf-flags SRVFLAG_LOCATION) {
/* Inherit configuration from the parent */
f = SRVFLAG_INDEX|SRVFLAG_NO_INDEX;
if ((srv_conf-flags f) == 0) {
- srv_conf-flags |= srv-srv_conf.flags f;
- (void)strlcpy(srv_conf-index, srv-srv_conf.index,
+ srv_conf-flags |= parent-flags f;
+ (void)strlcpy(srv_conf-index, parent-index,
sizeof(srv_conf-index));
}
f = SRVFLAG_AUTO_INDEX|SRVFLAG_NO_AUTO_INDEX;
if ((srv_conf-flags f) == 0)
- srv_conf-flags |= srv-srv_conf.flags f;
+ srv_conf-flags |= parent-flags f;
f = SRVFLAG_SOCKET|SRVFLAG_FCGI;
if ((srv_conf-flags f) == SRVFLAG_FCGI) {
@@ -255,48 +265,48 @@ config_getserver_config(struct httpd *en
f = SRVFLAG_ROOT;
if ((srv_conf-flags f) == 0) {
- srv_conf-flags |= srv-srv_conf.flags f;
- (void)strlcpy(srv_conf-root, srv-srv_conf.root,
+ srv_conf-flags |= parent-flags f;
+ (void)strlcpy(srv_conf-root, parent-root,
sizeof(srv_conf-root));
}
f = SRVFLAG_FCGI|SRVFLAG_NO_FCGI;
if ((srv_conf-flags f) == 0)
- srv_conf-flags |= srv-srv_conf.flags f;
+ srv_conf-flags |= parent-flags f;
f = SRVFLAG_LOG|SRVFLAG_NO_LOG;
if ((srv_conf-flags f) == 0) {
- srv_conf-flags |= srv-srv_conf.flags f;
- srv_conf-logformat = srv-srv_conf.logformat;
+ srv_conf-flags |= parent-flags f;
+ srv_conf-logformat = parent-logformat;
}
f = SRVFLAG_SYSLOG|SRVFLAG_NO_SYSLOG;
if ((srv_conf-flags f) == 0)
- srv_conf-flags |= srv-srv_conf.flags f;
+ srv_conf-flags |= parent-flags f;
f = SRVFLAG_SSL;
- srv_conf-flags |= srv-srv_conf.flags f;
+ srv_conf-flags |= parent-flags f;
f = SRVFLAG_ACCESS_LOG;
if ((srv_conf-flags f) == 0) {
- srv_conf-flags |= srv-srv_conf.flags f;
+ srv_conf-flags |= parent-flags f;
(void)strlcpy(srv_conf-accesslog,
- srv-srv_conf.accesslog,
+ parent-accesslog,
sizeof(srv_conf-accesslog));
crypt_newhash
Hi, The flak blog just had an interesting post about why the old crypt() interface should be replaced, and on the new crypt_newhash() and crypt_checkpass() that were added to OpenBSD. I would like to see this API become portable and perhaps standardized, but crypt_newhash is currently tied to login_cap_t, which is not a portable abstraction. The current synopsis is: #include login_cap.h int crypt_newhash(const char *pass, login_cap_t *lc, char *hash, size_t hashlen); The purpose of the lc parameter is to determine which algorithm to use: The implementation merely does a login_getcapstr(lc, localcipher, NULL, NULL) call to convert that into a string telling what algorithm to use. If lc is NULL, then it defaults to a reasonable algorithm. It would be superior to move the login_getcapstr call to the caller and instead have a string parameter. This removes the association with login_cap and it can be moved to unistd.h or pwd.h alongside the other functions. It also becomes more like crypt (where various algorithms can be requested) and thus more reusable in other situations than local-user authentication (like a web-server). Jonas
Re: crypt_newhash
On Thu, Nov 20, 2014 at 19:29, Jonas 'Sortie' Termansen wrote: Hi, The flak blog just had an interesting post about why the old crypt() interface should be replaced, and on the new crypt_newhash() and crypt_checkpass() that were added to OpenBSD. I would like to see this API become portable and perhaps standardized, but crypt_newhash is currently tied to login_cap_t, which is not a portable abstraction. The current synopsis is: #include login_cap.h int crypt_newhash(const char *pass, login_cap_t *lc, char *hash, size_t hashlen); The purpose of the lc parameter is to determine which algorithm to use: The implementation merely does a login_getcapstr(lc, localcipher, NULL, NULL) call to convert that into a string telling what algorithm to use. If lc is NULL, then it defaults to a reasonable algorithm. It would be superior to move the login_getcapstr call to the caller and instead have a string parameter. This removes the association with login_cap and it can be moved to unistd.h or pwd.h alongside the other functions. It also becomes more like crypt (where various algorithms can be requested) and thus more reusable in other situations than local-user authentication (like a web-server). Yes. Deciding which level of abstraction to incorporate was part of the fun. The factors in favor of login_cap is that the getcapstr code is basically boilerplate that all OpenBSD callers are going to duplicate. The various passwd/user/encrypt programs all have access to login cap. You have some good points that the interface could be changed to be more accomodating to other users. The bcrypt extension functions are standalone precisely for that reason, so that the code could be packaged and reused by anybody. The crypt_newhash function felt more like a system interface, particular to OpenBSD, but it is not strictly necessary for that to be the case. Parity with checkpass would be a bonus. So far only passwd uses the new function; it is still easy for me to change the interface. (The only constraint being that I need to coordinate library changes with other developments so it may not be an immediate change.)
Re: 64-bit PCI bridge support: testers needed
working on a 2950. will put try it on a r710 soon.
dlg
On 20 Nov 2014, at 19:10, Mark Kettenis mark.kette...@xs4all.nl wrote:
Hi All,
dlg@ managed to get access to a machine that actually uses 64-bit PCI
addresses behind a bridge. This triggered some bugs in the so far
untested code. Quelle suprprise!
I'd appreciate it if some people can verify that this doesn't break
other systems. In particular I'm looking for testers on server-type
machines, both i386 and amd64.
Thanks,
Mark
Index: pci.c
===
RCS file: /cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.106
diff -u -p -r1.106 pci.c
--- pci.c 26 Oct 2014 16:18:42 - 1.106
+++ pci.c 20 Nov 2014 09:04:51 -
@@ -936,6 +936,12 @@ pci_reserve_resources(struct pci_attach_
blr = pci_conf_read(pc, tag, PPB_REG_PREFMEM);
base = (blr 0xfff0) 16;
limit = (blr 0xfff0) | 0x000f;
+#ifdef __LP64__
+ blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFBASE_HI32);
+ base |= ((uint64_t)blr) 32;
+ blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFLIM_HI32);
+ limit |= ((uint64_t)blr) 32;
+#endif
if (limit base)
size = (limit - base + 1);
else
Index: ppb.c
===
RCS file: /cvs/src/sys/dev/pci/ppb.c,v
retrieving revision 1.59
diff -u -p -r1.59 ppb.c
--- ppb.c 15 Sep 2014 14:22:07 - 1.59
+++ ppb.c 20 Nov 2014 09:04:51 -
@@ -261,7 +261,7 @@ ppbattach(struct device *parent, struct
name = malloc(32, M_DEVBUF, M_NOWAIT);
if (name) {
snprintf(name, 32, %s pcimem, sc-sc_dev.dv_xname);
- sc-sc_memex = extent_create(name, 0, 0x,
+ sc-sc_memex = extent_create(name, 0, (u_long)-1L,
M_DEVBUF, NULL, 0, EX_NOWAIT | EX_FILLED);
extent_free(sc-sc_memex, sc-sc_membase,
sc-sc_memlimit - sc-sc_membase + 1,
@@ -273,7 +273,7 @@ ppbattach(struct device *parent, struct
blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFMEM);
sc-sc_pmembase = (blr 0xfff0) 16;
sc-sc_pmemlimit = (blr 0xfff0) | 0x000f;
-#ifdef __LP64__ /* XXX because extents use long... */
+#ifdef __LP64__
blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFBASE_HI32);
sc-sc_pmembase |= ((uint64_t)blr) 32;
blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFLIM_HI32);
Re: crypt_newhash
On Thu, Nov 20, 2014 at 20:22, Ted Unangst wrote: So far only passwd uses the new function; it is still easy for me to change the interface. (The only constraint being that I need to coordinate library changes with other developments so it may not be an immediate change.) Sneaking the change in was easier than I thought, and upon further review, some of the extra login_cap handling was unnecessary for most callers. Updated to use a string parameter (arguments regarding its defintion postponed til next week :)). Thanks for the quick feedback.
Re: 64-bit PCI bridge support: testers needed
works on an alpha es45 as well. theo made me do it.
On 21 Nov 2014, at 13:49, David Gwynne da...@gwynne.id.au wrote:
working on a 2950. will put try it on a r710 soon.
dlg
On 20 Nov 2014, at 19:10, Mark Kettenis mark.kette...@xs4all.nl wrote:
Hi All,
dlg@ managed to get access to a machine that actually uses 64-bit PCI
addresses behind a bridge. This triggered some bugs in the so far
untested code. Quelle suprprise!
I'd appreciate it if some people can verify that this doesn't break
other systems. In particular I'm looking for testers on server-type
machines, both i386 and amd64.
Thanks,
Mark
Index: pci.c
===
RCS file: /cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.106
diff -u -p -r1.106 pci.c
--- pci.c26 Oct 2014 16:18:42 - 1.106
+++ pci.c20 Nov 2014 09:04:51 -
@@ -936,6 +936,12 @@ pci_reserve_resources(struct pci_attach_
blr = pci_conf_read(pc, tag, PPB_REG_PREFMEM);
base = (blr 0xfff0) 16;
limit = (blr 0xfff0) | 0x000f;
+#ifdef __LP64__
+blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFBASE_HI32);
+base |= ((uint64_t)blr) 32;
+blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFLIM_HI32);
+limit |= ((uint64_t)blr) 32;
+#endif
if (limit base)
size = (limit - base + 1);
else
Index: ppb.c
===
RCS file: /cvs/src/sys/dev/pci/ppb.c,v
retrieving revision 1.59
diff -u -p -r1.59 ppb.c
--- ppb.c15 Sep 2014 14:22:07 - 1.59
+++ ppb.c20 Nov 2014 09:04:51 -
@@ -261,7 +261,7 @@ ppbattach(struct device *parent, struct
name = malloc(32, M_DEVBUF, M_NOWAIT);
if (name) {
snprintf(name, 32, %s pcimem, sc-sc_dev.dv_xname);
-sc-sc_memex = extent_create(name, 0, 0x,
+sc-sc_memex = extent_create(name, 0, (u_long)-1L,
M_DEVBUF, NULL, 0, EX_NOWAIT | EX_FILLED);
extent_free(sc-sc_memex, sc-sc_membase,
sc-sc_memlimit - sc-sc_membase + 1,
@@ -273,7 +273,7 @@ ppbattach(struct device *parent, struct
blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFMEM);
sc-sc_pmembase = (blr 0xfff0) 16;
sc-sc_pmemlimit = (blr 0xfff0) | 0x000f;
-#ifdef __LP64__ /* XXX because extents use long... */
+#ifdef __LP64__
blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFBASE_HI32);
sc-sc_pmembase |= ((uint64_t)blr) 32;
blr = pci_conf_read(pc, pa-pa_tag, PPB_REG_PREFLIM_HI32);
Re: httpd errata
Hi,
On Thu, Nov 20, 2014 at 06:24:23PM -0500, Ted Unangst wrote:
[on behalf of reyk]
Many people want to test the new httpd in OpenBSD 5.6; so we decided
to provide various improvements from -current for 5.6.
See the description below for more details.
[...]
Index: usr.sbin/httpd/httpd.c
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.c,v
retrieving revision 1.17
diff -u -p -r1.17 httpd.c
--- usr.sbin/httpd/httpd.c5 Aug 2014 15:36:59 - 1.17
+++ usr.sbin/httpd/httpd.c18 Nov 2014 15:02:54 -
[...]
@@ -623,6 +678,40 @@ socket_rlimit(int maxfd)
rl.rlim_cur = MAX(rl.rlim_max, (rlim_t)maxfd);
if (setrlimit(RLIMIT_NOFILE, rl) == -1)
fatal(socket_rlimit: failed to set resource limit);
+}
+
+char *
+evbuffer_getline(struct evbuffer *evb)
+{
+ u_int8_t*ptr = EVBUFFER_DATA(evb);
+ size_t len = EVBUFFER_LENGTH(evb);
+ char*str;
+ u_inti;
+
+ /* Safe version of evbuffer_readline() */
+ if ((str = get_string(ptr, len)) == NULL)
+ return (NULL);
+
+ for (i = 0; str[i] != '\0'; i++) {
+ if (str[i] == '\r' || str[i] == '\n')
+ break;
+ }
+
+ if (i == len) {
+ free(str);
+ return (NULL);
+ }
+
+ str[i] = '\0';
+
+ if ((i + 1) len) {
+ if (ptr[i] == '\r' ptr[i + 1] == '\n')
+ i++;
+ }
any concern over 'u_int i' vs 'size_t len' type-mismatch?
--patrick
