Sending route messages for local routes or cloning routes
Hi Martin, as requested in your commit message I would like to tell you about a regression with the introduced local routes: Before OpenBSD 5.6 it was possible to add route labels to interfaces and tell ospfd to redistribute all labeled routes. After adding an address to a labeled interface a new route was announced via ospf. Now the ospfd can't detect added or deleted addresses anymore, because the kernel informs about local routes instead of cloning routes. route -nv monitor: OPENBSD_5_5: RTM_NEWADDR: address being added to iface: len 96, metric 0, flags:CLONING sockaddrs: NETMASK,IFP,IFA,BRD 255.255.255.0 08:00:27:ad:dd:7c 5.5.5.5 5.5.5.255 RTM_ADD: Add Route: len 192, priority 4, table 0, pid: 0, seq 0, errno 0 flags:UP,CLONING use:0 mtu:0expire:0 locks: inits: sockaddrs: DST,GATEWAY,NETMASK,LABEL 5.5.5.0 link#3 255.255.255.0 EXPORT OPENBSD_5_6: RTM_NEWADDR: address being added to iface: len 96, metric 0, flags:UP sockaddrs: NETMASK,IFP,IFA,BRD 255.255.255.0 08:00:27:fd:b8:81 5.5.5.5 5.5.5.255 RTM_ADD: Add Route: len 184, priority 1, table 0, pid: 0, seq 0, errno 0 flags:UP,HOST,LLINFO,LOCAL use:0 mtu:0expire:0 locks: inits: sockaddrs: DST,GATEWAY,LABEL 5.5.5.5 08:00:27:fd:b8:81 EXPORT In the commit message of route.c r1.172 you said always generating one message per locally configured address. Are any userland tools needing this message? Would it make sense to remove the loop in rt_newaddrmsg which generates the two route messages? Instead of this rt_newaddrmsg sends only the RTM_NEWADDR / RTM_DELADDR message and the other message gets send after creating/deleting the cloning route. By the way if rt_newaddrmsg() sends RTM_NEWADDR and RTM_DELADDR we should rename it to rt_addrmsg(). Regards, Florian
Re: Sending route messages for local routes or cloning routes
Hello Florian, On 23/12/14(Tue) 11:17, Florian Riehm wrote: Hi Martin, as requested in your commit message I would like to tell you about a regression with the introduced local routes: Before OpenBSD 5.6 it was possible to add route labels to interfaces and tell ospfd to redistribute all labeled routes. After adding an address to a labeled interface a new route was announced via ospf. Now the ospfd can't detect added or deleted addresses anymore, because the kernel informs about local routes instead of cloning routes. Thanks for your attention and the report! route -nv monitor: OPENBSD_5_5: RTM_NEWADDR: address being added to iface: len 96, metric 0, flags:CLONING sockaddrs: NETMASK,IFP,IFA,BRD 255.255.255.0 08:00:27:ad:dd:7c 5.5.5.5 5.5.5.255 RTM_ADD: Add Route: len 192, priority 4, table 0, pid: 0, seq 0, errno 0 flags:UP,CLONING use:0 mtu:0expire:0 locks: inits: sockaddrs: DST,GATEWAY,NETMASK,LABEL 5.5.5.0 link#3 255.255.255.0 EXPORT OPENBSD_5_6: RTM_NEWADDR: address being added to iface: len 96, metric 0, flags:UP sockaddrs: NETMASK,IFP,IFA,BRD 255.255.255.0 08:00:27:fd:b8:81 5.5.5.5 5.5.5.255 RTM_ADD: Add Route: len 184, priority 1, table 0, pid: 0, seq 0, errno 0 flags:UP,HOST,LLINFO,LOCAL use:0 mtu:0expire:0 locks: inits: sockaddrs: DST,GATEWAY,LABEL 5.5.5.5 08:00:27:fd:b8:81 EXPORT In the commit message of route.c r1.172 you said always generating one message per locally configured address. Are any userland tools needing this message? At least dhclient(8). Would it make sense to remove the loop in rt_newaddrmsg which generates the two route messages? Instead of this rt_newaddrmsg sends only the RTM_NEWADDR / RTM_DELADDR message and the other message gets send after creating/deleting the cloning route. I think it does make sense. It would restore the RTM_ADD for RTF_CLONING routes and keep one RTM_NEWADDR for RTF_LOCAL routes. Apart from your scenario with ospfd/ospf6d, dhclient should be happy with this change and I can think of a third case. If you configure two addresses of the same subnet you should see 2 RTM_NEWADDR but only one RTM_ADD since only the first address will get a cloning route. By the way if rt_newaddrmsg() sends RTM_NEWADDR and RTM_DELADDR we should rename it to rt_addrmsg(). If you remove the loop and generate only one message, I think that you can simply use rt_sendmsg() and kill rt_newaddrmsg().
Re: Sending route messages for local routes or cloning routes
On 12/23/14 11:59, Martin Pieuchot wrote: Would it make sense to remove the loop in rt_newaddrmsg which generates the two route messages? Instead of this rt_newaddrmsg sends only the RTM_NEWADDR / RTM_DELADDR message and the other message gets send after creating/deleting the cloning route. I think it does make sense. It would restore the RTM_ADD for RTF_CLONING routes and keep one RTM_NEWADDR for RTF_LOCAL routes. Apart from your scenario with ospfd/ospf6d, dhclient should be happy with this change and I can think of a third case. If you configure two addresses of the same subnet you should see 2 RTM_NEWADDR but only one RTM_ADD since only the first address will get a cloning route. By the way if rt_newaddrmsg() sends RTM_NEWADDR and RTM_DELADDR we should rename it to rt_addrmsg(). If you remove the loop and generate only one message, I think that you can simply use rt_sendmsg() and kill rt_newaddrmsg(). ok, thanks for your advice. I will try it and let you know if it works.
tls_init(3): mention tls_accept_socket function
Hi, tls_accept_socket function missing in tls_init(3) manpage. Index: tls_init.3 === RCS file: /cvs/src/lib/libtls/tls_init.3,v retrieving revision 1.4 diff -u -p -r1.4 tls_init.3 --- tls_init.3 11 Nov 2014 04:17:34 - 1.4 +++ tls_init.3 23 Dec 2014 14:39:06 - @@ -45,6 +45,7 @@ .Nm tls_connect , .Nm tls_connect_fds , .Nm tls_connect_socket , +.Nm tls_accept_socket , .Nm tls_read , .Nm tls_write , .Nd TLS client and server API @@ -105,6 +106,8 @@ .Ft int .Fn tls_connect_socket struct tls *ctx int s const char *hostname .Ft int +.Fn tls_accept_socket struct tls *ctx struct tls **ctx int s +.Ft int .Fn tls_read struct tls *ctx void *buf size_t buflen size_t *outlen .Ft int .Fn tls_write struct tls *ctx const void *buf size_t buflen size_t *outlen @@ -295,6 +298,9 @@ connects a client context to a pair of e .It .Fn tls_connect_socket connects a client context to an already established socket connection. +.It +.Fn tls_accept_socket +accepts a client context on an already established socket connection. .It .Fn tls_read reads
Re: httpd: redirect to https, or www, or non-www
On Tue, Dec 23, 2014 at 12:44 PM, Carlin Bingham c...@viennan.net wrote: ngninx and apache support url rewriting, letting you redirect from arbitrary urls with pattern matching. In my experience the primary uses for this are to redirect from http to https or to remove/add www in the hostname, so I thought it might be useful to have options making these specific uses possible and simple to do. This adds an enforce option, where enforce https redirects non-http to https, enforce www redirects from example.org to www.example.org http://www.example.org, and enforce no www redirects from www.example.org http://www.example.org to example.org. Would appreciate any feedback or suggestions. Thanks As someone who admins a number of web services with redirects to enforce SSL, and consistent hostnames: I feel like enforce https is ok, as it's a protocol and the options are pretty limited and require differences in configurations so you know what you want to support. However enforce www seems too specific. What if I have www1.server.com or ww2.server.com or anything.server.com? I would want a more general approach to hostname/domain name rewriting. Tim.
Re: [PATCH] update zlib to 1.2.8
On Tue, Dec 23, 2014 at 10:54:15PM +0200, Timo Myyrä wrote: I was trying to port notmuch mail indexer but got little stuck with it as it requires newer Zlib version than whats in base. It is easy to patch notmuch, the requirement is rather silly. FYI. Joerg
Re: httpd: redirect to https, or www, or non-www
Making insecure redirects that the attacker can manipulate arbitrarily
is worse than dumb. because it trains users to like it.
I do not think we should be propagating such thinking.
On Tue, Dec 23, 2014 at 10:44 AM, Carlin Bingham c...@viennan.net wrote:
ngninx and apache support url rewriting, letting you redirect from
arbitrary urls with pattern matching. In my experience the primary
uses for this are to redirect from http to https or to remove/add www
in the hostname, so I thought it might be useful to have options making
these specific uses possible and simple to do.
This adds an enforce option, where enforce https redirects non-http
to https, enforce www redirects from example.org to www.example.org
http://www.example.org,
and enforce no www redirects from www.example.org http://www.example.org
to example.org.
Would appreciate any feedback or suggestions.
Thanks
Index: usr.sbin/httpd/httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.64
diff -u -p -u -r1.64 httpd.h
--- usr.sbin/httpd/httpd.h 12 Dec 2014 14:45:59 - 1.64
+++ usr.sbin/httpd/httpd.h 23 Dec 2014 17:20:55 -
@@ -345,6 +345,10 @@ SPLAY_HEAD(client_tree, client);
\10\01NODELAY\02NO_NODELAY\03SACK\04NO_SACK \
\05SOCKET_BUFFER_SIZE\06IP_TTL\07IP_MINTTL\10NO_SPLICE
+#define ENFORCE_HTTPS 0x10
+#define ENFORCE_WWW0x01
+#define ENFORCE_NO_WWW 0x02
+
enum log_format {
LOG_FORMAT_COMMON,
LOG_FORMAT_COMBINED,
@@ -391,6 +395,8 @@ struct server_config {
u_int8_t tcpipttl;
u_int8_t tcpipminttl;
+ u_int8_t enforce;
+
enum log_format logformat;
struct log_file *logaccess;
struct log_file *logerror;
@@ -499,6 +505,7 @@ struct server_config *
serverconfig_byid(u_int32_t);
int server_foreach(int (*)(struct server *,
struct server_config *, void *), void *);
+int server_enforce_redirect(struct client *);
SPLAY_PROTOTYPE(client_tree, client, clt_nodes, server_client_cmp);
Index: usr.sbin/httpd/parse.y
===
RCS file: /cvs/src/usr.sbin/httpd/parse.y,v
retrieving revision 1.46
diff -u -p -u -r1.46 parse.y
--- usr.sbin/httpd/parse.y 21 Dec 2014 00:54:49 - 1.46
+++ usr.sbin/httpd/parse.y 23 Dec 2014 17:20:56 -
@@ -129,7 +129,7 @@ typedef struct {
%token COMBINED CONNECTION DIRECTORY ERR FCGI INDEX IP KEY LISTEN LOCATION
%token LOG LOGDIR MAXIMUM NO NODELAY ON PORT PREFORK REQUEST REQUESTS ROOT
%token SACK SERVER SOCKET STYLE SYSLOG TCP TIMEOUT TLS TYPES
-%token ERROR INCLUDE
+%token ERROR INCLUDE ENFORCE HTTPS WWW
%token v.string STRING
%token v.number NUMBER
%type v.portport
@@ -371,6 +371,15 @@ serveroptsl: LISTEN ON STRING opttls po
}
| DIRECTORY dirflags
| DIRECTORY '{' dirflags_l '}'
+ | ENFORCE HTTPS {
+ srv_conf-enforce |= ENFORCE_HTTPS;
+ }
+ | ENFORCE WWW {
+ srv_conf-enforce |= ENFORCE_WWW;
+ }
+ | ENFORCE NO WWW{
+ srv_conf-enforce |= ENFORCE_NO_WWW;
+ }
| logformat
| fastcgi
| LOCATION STRING {
@@ -863,8 +872,10 @@ lookup(char *s)
{ common, COMMON },
{ connection, CONNECTION },
{ directory, DIRECTORY },
+ { enforce,ENFORCE },
{ error, ERR },
{ fastcgi,FCGI },
+ { https, HTTPS },
{ include,INCLUDE },
{ index, INDEX },
{ ip, IP },
@@ -890,7 +901,8 @@ lookup(char *s)
{ tcp,TCP },
{ timeout,TIMEOUT },
{ tls,TLS },
- { types, TYPES }
+ { types, TYPES },
+ { www,WWW }
};
const struct keywords *p;
Index: usr.sbin/httpd/server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.57
diff -u -p -u -r1.57 server_http.c
--- usr.sbin/httpd/server_http.c21 Dec 2014 00:54:49 - 1.57
+++ usr.sbin/httpd/server_http.c23 Dec 2014 17:20:56 -
@@ -882,6 +882,9 @@ server_response(struct httpd *httpd, str
/* Now search
Re: [PATCH] update zlib to 1.2.8
Hi, There's some value in having a newer zlib release. There have been bugfixes, documentation fixes, various improvements, and API additions. I'm not sure how much is backported to the OpenBSD zlib, but a quick glance through your attached patch suggests there's stuff that would be nice to have. Do note your patch does revert some OpenBSD-local changes to zlib. You should diff the older zlib release with the OpenBSD zlib to see what they are and try to preserve them when rebasing on the latest zlib release. But if you read the patch to 1.2.8 carefully, you would also notice a good deal of added portability code. Nothing too exciting has happened in the zlib world the past decade, except the addition of more portability to support even more awful systems. It's basically the OpenSSL approach to portability gone worse. Not all of it is worth having, some of it is undesirable. I think it's a better idea to go through the patch manually and pick out the desirable changes and apply them. Or, as Joerg suggests, just patch the port to be compatible with older zlib releases if possible. Recently I got fed up with the awful code quality of upsteam zlib, so I fetched 1.2.8 and removed support for awful systems line by line, converting it to nice standard C, not zlib-C. The result was a great deal simpler and the process revealed a great deal of horrors. You just need to open a random file to find them. Jonas
