Re: acme-client -t switch?

2017-03-11 Thread Kristaps Dzonsons
>>> Since this came up.. what does anyone think about adding the original
>>> version back to ports? (personally, I could do with moving things away
>>> from the python version, but I need dns-01..)
>>
>> I'm planing on re-introducing the [-t switch] functinality.
> 
> What direction are you planning on going with that?  Using the model
> that Kristaps is using in the git version where challenges are provided
> on stdout to another program?  Or using something closer to the original
> implementation where acme-client executes an arbitrary program when
> it needs to do the challenge?
> 
> I think the stdout mechanism would be cleaner as that way an extension
> only needs to integrate by calling acme-client, not integrating both
> caller and callee.  It would also reduce the differences between the
> versions.

Upstream and openbsd's version aren't that different beyond the
configuration file.  There are just more features upstream (OCSP, etc.),
but nothing fundamental.

I'll be pulling in the downstream config file, as already acme-client
has a ridiculous number of flags.  There are a few patches for user
credentials I'm sitting on because I just don't want to add flags.

As for [-t], I reckon I'll just have a config entry of challenge type
and the program to execute.  This'll then be invoked as a subprocess in
the same way as currently documented.  This will require more work, but
nothing crazy.



Re: fix ifconfig scan confusing WEP and WPA

2017-03-11 Thread Stefan Sperling
On Sat, Mar 11, 2017 at 09:55:15AM +0900, Stefan Sperling wrote:
> While a wifi interface is configured to use WEP 'ifconfig scan' will
> mistakenly show all WPA APs as WEP ones. Fix below.
> 
> This is a small ABI change in struct ieee80211_nodereq.

My diff has been committed but tb@ noticed that it does not actually
work in all cases.

This diff tries to introduce a clear distinction between what is supported
and what is enabled. 'ifconfig scan' now only shows what is supported.
I hope this is more clear and correct.

Index: ieee80211_input.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_input.c,v
retrieving revision 1.187
diff -u -p -r1.187 ieee80211_input.c
--- ieee80211_input.c   1 Mar 2017 19:28:48 -   1.187
+++ ieee80211_input.c   12 Mar 2017 00:48:02 -
@@ -1654,35 +1654,57 @@ ieee80211_recv_probe_resp(struct ieee802
&& ic->ic_opmode != IEEE80211_M_HOSTAP
 #endif
   ) {
-   struct ieee80211_rsnparams rsn;
-   const u_int8_t *saveie = NULL;
+   struct ieee80211_rsnparams rsn, wpa;
+
+   ni->ni_rsnprotos = IEEE80211_PROTO_NONE;
+   ni->ni_supported_rsnprotos = IEEE80211_PROTO_NONE;
+   ni->ni_rsnakms = 0;
+   ni->ni_supported_rsnakms = 0;
+   ni->ni_rsnciphers = 0;
+   ni->ni_rsngroupcipher = 0;
+   ni->ni_rsngroupmgmtcipher = 0;
+   ni->ni_rsncaps = 0;
+
+   if (rsnie != NULL &&
+   ieee80211_parse_rsn(ic, rsnie, ) == 0) {
+   ni->ni_supported_rsnprotos |= IEEE80211_PROTO_RSN;
+   ni->ni_supported_rsnakms |= rsn.rsn_akms;
+   }
+   if (wpaie != NULL &&
+   ieee80211_parse_wpa(ic, wpaie, ) == 0) {
+   ni->ni_supported_rsnprotos |= IEEE80211_PROTO_WPA;
+   ni->ni_supported_rsnakms |= wpa.rsn_akms;
+   }
+
/*
-* If the AP advertises both RSN and WPA IEs (WPA1+WPA2),
-* we only store the parameters of the highest protocol
-* version we support.
+* If the AP advertises both WPA and RSN IEs (WPA1+WPA2),
+* we only use the highest protocol version we support.
 */
if (rsnie != NULL &&
+   (ni->ni_supported_rsnprotos & IEEE80211_PROTO_RSN) &&
(ic->ic_rsnprotos & IEEE80211_PROTO_RSN)) {
-   if (ieee80211_parse_rsn(ic, rsnie, ) == 0) {
+   if (ieee80211_save_ie(rsnie, >ni_rsnie) == 0) {
ni->ni_rsnprotos = IEEE80211_PROTO_RSN;
-   saveie = rsnie;
+   ni->ni_rsnakms = rsn.rsn_akms;
+   ni->ni_rsnciphers = rsn.rsn_ciphers;
+   ni->ni_rsngroupcipher = rsn.rsn_groupcipher;
+   ni->ni_rsngroupmgmtcipher =
+   rsn.rsn_groupmgmtcipher;
+   ni->ni_rsncaps = rsn.rsn_caps;
}
} else if (wpaie != NULL &&
+   (ni->ni_supported_rsnprotos & IEEE80211_PROTO_WPA) &&
(ic->ic_rsnprotos & IEEE80211_PROTO_WPA)) {
-   if (ieee80211_parse_wpa(ic, wpaie, ) == 0) {
+   if (ieee80211_save_ie(wpaie, >ni_rsnie) == 0) {
ni->ni_rsnprotos = IEEE80211_PROTO_WPA;
-   saveie = wpaie;
+   ni->ni_rsnakms = wpa.rsn_akms;
+   ni->ni_rsnciphers = wpa.rsn_ciphers;
+   ni->ni_rsngroupcipher = wpa.rsn_groupcipher;
+   ni->ni_rsngroupmgmtcipher =
+   wpa.rsn_groupmgmtcipher;
+   ni->ni_rsncaps = wpa.rsn_caps;
}
}
-   if (saveie != NULL &&
-   ieee80211_save_ie(saveie, >ni_rsnie) == 0) {
-   ni->ni_rsnakms = rsn.rsn_akms;
-   ni->ni_rsnciphers = rsn.rsn_ciphers;
-   ni->ni_rsngroupcipher = rsn.rsn_groupcipher;
-   ni->ni_rsngroupmgmtcipher = rsn.rsn_groupmgmtcipher;
-   ni->ni_rsncaps = rsn.rsn_caps;
-   } else
-   ni->ni_rsnprotos = IEEE80211_PROTO_NONE;
}
 
if (ssid[1] != 0 && ni->ni_esslen == 0) {
@@ -2018,6 +2040,15 @@ ieee80211_recv_assoc_req(struct ieee8021
goto end;
}
 
+   ni->ni_rsnprotos = IEEE80211_PROTO_NONE;
+   ni->ni_supported_rsnprotos = IEEE80211_PROTO_NONE;
+   ni->ni_rsnakms = 0;
+   ni->ni_supported_rsnakms = 0;
+   

Re: Improved support for Apple trackpads: tests needed

2017-03-11 Thread Joerg Jung
On Fri, Mar 10, 2017 at 12:47:37AM +0100, Ulf Brosziewski wrote:
> This patch for ubcmtp makes it use the multitouch-input functions of
> wsmouse. It's the first driver that would apply the "tracking" variant
> (wsmouse_mtframe).
> 
> No wonders will result from the change, but the two-finger gestures that
> involve movement - scrolling and click-and-drag with two fingers on a
> clickpad - should work without flaws.
> 
> A quick way to check whether all touch positions are available and the
> selection of the active touch works properly is two-finger-scrolling,
> performed with only one finger moving, then switching to the other one.
> 
> Please note that click-and-drag will still require that the "ClickPad"
> attribute is set in the synaptics(4) configuration.
> 
> The patch has been tested on a MacBookPro 8,2 (from 2011). It would be
> nice to learn that it doesn't introduce regressions on older or newer
> models.
> 
> If you don't use a brand-new version of the synaptics driver, you may
> encounter the following bug: If the X cursor is in a window with
> scrollable content and you put two finger on the touchpad without moving
> them, the window content may quickly scroll up and down by a small
> distance. This bug is fixed in the latest version.


Tested and works fine MacBookAir6,2 with some slightly tweaked values:

synclient ClickFinger2=3
synclient ClickFinger3=2
synclient ClickPad=1
synclient VertScrollDelta=-237
synclient HorizScrollDelta=-237
synclient HorizTwoFingerScroll=1

ClickPad/click-and-drag  works, awesome! :)

Diff reads fine. Thanks!
OK jung@ 

> Index: dev/usb/ubcmtp.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ubcmtp.c,v
> retrieving revision 1.12
> diff -u -p -r1.12 ubcmtp.c
> --- dev/usb/ubcmtp.c  30 Mar 2016 23:34:12 -  1.12
> +++ dev/usb/ubcmtp.c  9 Mar 2017 22:17:50 -
> @@ -125,6 +125,12 @@ struct ubcmtp_finger {
>  #define UBCMTP_SN_COORD  250
>  #define UBCMTP_SN_ORIENT 10
>  
> +/* Identify clickpads in ubcmtp_configure. */
> +#define IS_CLICKPAD(ubcmtp_type) (ubcmtp_type != UBCMTP_TYPE1)
> +
> +/* Use a constant, synaptics-compatible pressure value for now. */
> +#define DEFAULT_PRESSURE 40
> +
>  struct ubcmtp_limit {
>   int limit;
>   int min;
> @@ -316,17 +322,6 @@ static struct ubcmtp_dev ubcmtp_devices[
>   },
>  };
>  
> -/* coordinates for each tracked finger */
> -struct ubcmtp_pos {
> - int down;
> - int x;
> - int y;
> - int z;
> - int w;
> - int dx;
> - int dy;
> -};
> -
>  struct ubcmtp_softc {
>   struct device   sc_dev; /* base device */
>  
> @@ -355,7 +350,8 @@ struct ubcmtp_softc {
>   uint32_tsc_status;
>  #define UBCMTP_ENABLED   1
>  
> - struct ubcmtp_pos   pos[UBCMTP_MAX_FINGERS];
> + struct mtpoint  frame[UBCMTP_MAX_FINGERS];
> + int contacts;
>   int btn;
>  };
>  
> @@ -519,6 +515,24 @@ ubcmtp_activate(struct device *self, int
>  }
>  
>  int
> +ubcmtp_configure(struct ubcmtp_softc *sc)
> +{
> + struct wsmousehw *hw = wsmouse_get_hw(sc->sc_wsmousedev);
> +
> + hw->type = WSMOUSE_TYPE_ELANTECH;   /* see ubcmtp_ioctl */
> + hw->hw_type = (IS_CLICKPAD(sc->dev_type->type)
> + ? WSMOUSEHW_CLICKPAD : WSMOUSEHW_TOUCHPAD);
> + hw->x_min = sc->dev_type->l_x.min;
> + hw->x_max = sc->dev_type->l_x.max;
> + hw->y_min = sc->dev_type->l_y.min;
> + hw->y_max = sc->dev_type->l_y.max;
> + hw->mt_slots = UBCMTP_MAX_FINGERS;
> + hw->flags = WSMOUSEHW_MT_TRACKING;
> +
> + return wsmouse_configure(sc->sc_wsmousedev, NULL, 0);
> +}
> +
> +int
>  ubcmtp_enable(void *v)
>  {
>   struct ubcmtp_softc *sc = v;
> @@ -534,6 +548,9 @@ ubcmtp_enable(void *v)
>   return (1);
>   }
>  
> + if (ubcmtp_configure(sc))
> + return (1);
> +
>   if (ubcmtp_setup_pipes(sc) == 0) {
>   sc->sc_status |= UBCMTP_ENABLED;
>   return (0);
> @@ -608,6 +625,7 @@ ubcmtp_ioctl(void *v, unsigned long cmd,
>   wsmode);
>   return (EINVAL);
>   }
> + wsmouse_set_mode(sc->sc_wsmousedev, wsmode);
>  
>   DPRINTF("%s: changing mode to %s\n",
>   sc->sc_dev.dv_xname, (wsmode == WSMOUSE_COMPAT ? "compat" :
> @@ -779,7 +797,7 @@ ubcmtp_tp_intr(struct usbd_xfer *xfer, v
>   struct ubcmtp_softc *sc = priv;
>   struct ubcmtp_finger *pkt;
>   u_int32_t pktlen;
> - int i, diff = 0, finger = 0, fingers = 0, s, t;
> + int i, s, btn, contacts, fingers;
>  
>   if (usbd_is_dying(sc->sc_udev) || !(sc->sc_status & UBCMTP_ENABLED))
>   return;
> @@ -803,76 +821,30 @@ ubcmtp_tp_intr(struct usbd_xfer *xfer, v
>   pkt = (struct ubcmtp_finger *)(sc->tp_pkt + sc->tp_offset);
>   fingers = (pktlen - 

Re: disklabel template on miniroot

2017-03-11 Thread Rivo Nurges
Hi!

It looks a bit silly to copy the template from one folder to another with ftp, 
but yeah, it works. Thanks for the hint.

Rivo

On 12/03/2017, 00:13, "owner-t...@openbsd.org on behalf of Theo Buehler" 
 wrote:

On Sat, Mar 11, 2017 at 09:59:09PM +, Rivo Nurges wrote:
> Hi!
> 
> Following will add support for disklabel template on miniroot.

Can't you achieve the same by adding

URL to autopartitioning template for disklabel = file:///disklabel.auto

to your auto_{install,upgrade}.conf ?

> 
> Rivo
> 
> Index: distrib/miniroot/install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.987
> diff -u -p -r1.987 install.sub
> --- distrib/miniroot/install.sub  10 Mar 2017 22:34:09 -  1.987
> +++ distrib/miniroot/install.sub  11 Mar 2017 21:56:42 -
> @@ -396,6 +396,11 @@ disklabel_autolayout() {
>   [[ $_disk != $ROOTDISK ]] && return
>  
>   while $AUTO; do
> + if [[ -f /disklabel.auto ]]; then
> + disklabel -T /disklabel.auto -F $_f -w -A $_disk && 
return
> + echo "Autopartitioning failed"
> + exit 1
> + fi
>   ask "URL to autopartitioning template for disklabel?" none
>   [[ $resp == none ]] && break
>   if ! $FTP_TLS && [[ $resp == https://* ]]; then
> Index: share/man/man8/autoinstall.8
> ===
> RCS file: /cvs/src/share/man/man8/autoinstall.8,v
> retrieving revision 1.21
> diff -u -p -r1.21 autoinstall.8
> --- share/man/man8/autoinstall.8  21 Jan 2017 06:00:38 -  1.21
> +++ share/man/man8/autoinstall.8  11 Mar 2017 21:56:42 -
> @@ -58,6 +58,11 @@ behaves as if the machine is netbooted, 
>  In case both files exist,
>  .Pa /auto_install.conf
>  takes precedence.
> +If
> +.Pa /disklabel.auto
> +is found
> +.Nm
> +will use it as the autopartitioning template.
>  .Pp
>  .Nm
>  uses HTTP to fetch one of the files
> @@ -204,6 +209,8 @@ configuration file
>  response file for unattended installation
>  .It Pa upgrade.conf
>  response file for unattended upgrade
> +.It Pa disklabel.auto
> +autopartitioning template for unattended installation
>  .El
>  .Sh EXAMPLES
>  A typical





Re: disklabel template on miniroot

2017-03-11 Thread Theo Buehler
On Sat, Mar 11, 2017 at 09:59:09PM +, Rivo Nurges wrote:
> Hi!
> 
> Following will add support for disklabel template on miniroot.

Can't you achieve the same by adding

URL to autopartitioning template for disklabel = file:///disklabel.auto

to your auto_{install,upgrade}.conf ?

> 
> Rivo
> 
> Index: distrib/miniroot/install.sub
> ===
> RCS file: /cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.987
> diff -u -p -r1.987 install.sub
> --- distrib/miniroot/install.sub  10 Mar 2017 22:34:09 -  1.987
> +++ distrib/miniroot/install.sub  11 Mar 2017 21:56:42 -
> @@ -396,6 +396,11 @@ disklabel_autolayout() {
>   [[ $_disk != $ROOTDISK ]] && return
>  
>   while $AUTO; do
> + if [[ -f /disklabel.auto ]]; then
> + disklabel -T /disklabel.auto -F $_f -w -A $_disk && 
> return
> + echo "Autopartitioning failed"
> + exit 1
> + fi
>   ask "URL to autopartitioning template for disklabel?" none
>   [[ $resp == none ]] && break
>   if ! $FTP_TLS && [[ $resp == https://* ]]; then
> Index: share/man/man8/autoinstall.8
> ===
> RCS file: /cvs/src/share/man/man8/autoinstall.8,v
> retrieving revision 1.21
> diff -u -p -r1.21 autoinstall.8
> --- share/man/man8/autoinstall.8  21 Jan 2017 06:00:38 -  1.21
> +++ share/man/man8/autoinstall.8  11 Mar 2017 21:56:42 -
> @@ -58,6 +58,11 @@ behaves as if the machine is netbooted, 
>  In case both files exist,
>  .Pa /auto_install.conf
>  takes precedence.
> +If
> +.Pa /disklabel.auto
> +is found
> +.Nm
> +will use it as the autopartitioning template.
>  .Pp
>  .Nm
>  uses HTTP to fetch one of the files
> @@ -204,6 +209,8 @@ configuration file
>  response file for unattended installation
>  .It Pa upgrade.conf
>  response file for unattended upgrade
> +.It Pa disklabel.auto
> +autopartitioning template for unattended installation
>  .El
>  .Sh EXAMPLES
>  A typical



disklabel template on miniroot

2017-03-11 Thread Rivo Nurges
Hi!

Following will add support for disklabel template on miniroot.

Rivo

Index: distrib/miniroot/install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.987
diff -u -p -r1.987 install.sub
--- distrib/miniroot/install.sub10 Mar 2017 22:34:09 -  1.987
+++ distrib/miniroot/install.sub11 Mar 2017 21:56:42 -
@@ -396,6 +396,11 @@ disklabel_autolayout() {
[[ $_disk != $ROOTDISK ]] && return
 
while $AUTO; do
+   if [[ -f /disklabel.auto ]]; then
+   disklabel -T /disklabel.auto -F $_f -w -A $_disk && 
return
+   echo "Autopartitioning failed"
+   exit 1
+   fi
ask "URL to autopartitioning template for disklabel?" none
[[ $resp == none ]] && break
if ! $FTP_TLS && [[ $resp == https://* ]]; then
Index: share/man/man8/autoinstall.8
===
RCS file: /cvs/src/share/man/man8/autoinstall.8,v
retrieving revision 1.21
diff -u -p -r1.21 autoinstall.8
--- share/man/man8/autoinstall.821 Jan 2017 06:00:38 -  1.21
+++ share/man/man8/autoinstall.811 Mar 2017 21:56:42 -
@@ -58,6 +58,11 @@ behaves as if the machine is netbooted, 
 In case both files exist,
 .Pa /auto_install.conf
 takes precedence.
+If
+.Pa /disklabel.auto
+is found
+.Nm
+will use it as the autopartitioning template.
 .Pp
 .Nm
 uses HTTP to fetch one of the files
@@ -204,6 +209,8 @@ configuration file
 response file for unattended installation
 .It Pa upgrade.conf
 response file for unattended upgrade
+.It Pa disklabel.auto
+autopartitioning template for unattended installation
 .El
 .Sh EXAMPLES
 A typical


begin-base64 644 install_autolabel.diff
SW5kZXg6IGRpc3RyaWIvbWluaXJvb3QvaW5zdGFsbC5zdWIKPT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTog
L2N2cy9zcmMvZGlzdHJpYi9taW5pcm9vdC9pbnN0YWxsLnN1Yix2CnJldHJpZXZpbmcgcmV2aXNp
b24gMS45ODcKZGlmZiAtdSAtcCAtcjEuOTg3IGluc3RhbGwuc3ViCi0tLSBkaXN0cmliL21pbmly
b290L2luc3RhbGwuc3ViCTEwIE1hciAyMDE3IDIyOjM0OjA5IC0wMDAwCTEuOTg3CisrKyBkaXN0
cmliL21pbmlyb290L2luc3RhbGwuc3ViCTExIE1hciAyMDE3IDIxOjU2OjQyIC0wMDAwCkBAIC0z
OTYsNiArMzk2LDExIEBAIGRpc2tsYWJlbF9hdXRvbGF5b3V0KCkgewogCVtbICRfZGlzayAhPSAk
Uk9PVERJU0sgXV0gJiYgcmV0dXJuCiAKIAl3aGlsZSAkQVVUTzsgZG8KKwkJaWYgW1sgLWYgL2Rp
c2tsYWJlbC5hdXRvIF1dOyB0aGVuCisJCQlkaXNrbGFiZWwgLVQgL2Rpc2tsYWJlbC5hdXRvIC1G
ICRfZiAtdyAtQSAkX2Rpc2sgJiYgcmV0dXJuCisJCQllY2hvICJBdXRvcGFydGl0aW9uaW5nIGZh
aWxlZCIKKwkJCWV4aXQgMQorCQlmaQogCQlhc2sgIlVSTCB0byBhdXRvcGFydGl0aW9uaW5nIHRl
bXBsYXRlIGZvciBkaXNrbGFiZWw/IiBub25lCiAJCVtbICRyZXNwID09IG5vbmUgXV0gJiYgYnJl
YWsKIAkJaWYgISAkRlRQX1RMUyAmJiBbWyAkcmVzcCA9PSBodHRwczovLyogXV07IHRoZW4KSW5k
ZXg6IHNoYXJlL21hbi9tYW44L2F1dG9pbnN0YWxsLjgKPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2
cy9zcmMvc2hhcmUvbWFuL21hbjgvYXV0b2luc3RhbGwuOCx2CnJldHJpZXZpbmcgcmV2aXNpb24g
MS4yMQpkaWZmIC11IC1wIC1yMS4yMSBhdXRvaW5zdGFsbC44Ci0tLSBzaGFyZS9tYW4vbWFuOC9h
dXRvaW5zdGFsbC44CTIxIEphbiAyMDE3IDA2OjAwOjM4IC0wMDAwCTEuMjEKKysrIHNoYXJlL21h
bi9tYW44L2F1dG9pbnN0YWxsLjgJMTEgTWFyIDIwMTcgMjE6NTY6NDIgLTAwMDAKQEAgLTU4LDYg
KzU4LDExIEBAIGJlaGF2ZXMgYXMgaWYgdGhlIG1hY2hpbmUgaXMgbmV0Ym9vdGVkLCAKIEluIGNh
c2UgYm90aCBmaWxlcyBleGlzdCwKIC5QYSAvYXV0b19pbnN0YWxsLmNvbmYKIHRha2VzIHByZWNl
ZGVuY2UuCitJZgorLlBhIC9kaXNrbGFiZWwuYXV0bworaXMgZm91bmQKKy5ObQord2lsbCB1c2Ug
aXQgYXMgdGhlIGF1dG9wYXJ0aXRpb25pbmcgdGVtcGxhdGUuCiAuUHAKIC5ObQogdXNlcyBIVFRQ
IHRvIGZldGNoIG9uZSBvZiB0aGUgZmlsZXMKQEAgLTIwNCw2ICsyMDksOCBAQCBjb25maWd1cmF0
aW9uIGZpbGUKIHJlc3BvbnNlIGZpbGUgZm9yIHVuYXR0ZW5kZWQgaW5zdGFsbGF0aW9uCiAuSXQg
UGEgdXBncmFkZS5jb25mCiByZXNwb25zZSBmaWxlIGZvciB1bmF0dGVuZGVkIHVwZ3JhZGUKKy5J
dCBQYSBkaXNrbGFiZWwuYXV0bworYXV0b3BhcnRpdGlvbmluZyB0ZW1wbGF0ZSBmb3IgdW5hdHRl
bmRlZCBpbnN0YWxsYXRpb24KIC5FbAogLlNoIEVYQU1QTEVTCiBBIHR5cGljYWwK




httpd: expand HTTP Host

2017-03-11 Thread Rivo Nurges
Hi!

Following will add possibility to expand $HTTP_HOST to the HTTP
Host header in "block return".

In my setup I have relayd on port 443 and httpd on 80. This patch
allows me to redirect http(httpd) to https(relayd) without knowing
the host.

/etc/httpd.conf:
server "redirect" {
  listen on * port 80
  block return 301 "https://$HTTP_HOST$REQUEST_URI;
}

Rivo

Index: usr.sbin/httpd/server_http.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
retrieving revision 1.115
diff -u -p -r1.115 server_http.c
--- usr.sbin/httpd/server_http.c10 Mar 2017 21:06:43 -  1.115
+++ usr.sbin/httpd/server_http.c11 Mar 2017 17:51:23 -
@@ -1068,6 +1068,18 @@ server_expand_http(struct client *clt, c
if (ret != 0)
return (NULL);
}
+   if (strstr(val, "$HTTP_HOST") != NULL) {
+   if (desc->http_host == NULL) {
+   ret = expand_string(buf, len, "$HTTP_HOST", "");
+   } else {
+   if ((str = url_encode(desc->http_host)) == NULL)
+   return (NULL);
+   ret = expand_string(buf, len, "$HTTP_HOST", str);
+   free(str);
+   }
+   if (ret != 0)
+   return (NULL);
+   }
if (strstr(val, "$REMOTE_") != NULL) {
if (strstr(val, "$REMOTE_ADDR") != NULL) {
if (print_host(>clt_ss,
Index: usr.sbin/httpd/httpd.conf.5
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.79
diff -u -p -r1.79 httpd.conf.5
--- usr.sbin/httpd/httpd.conf.5 7 Feb 2017 12:27:42 -   1.79
+++ usr.sbin/httpd/httpd.conf.5 11 Mar 2017 17:51:23 -
@@ -221,6 +221,8 @@ The configured IP address of the server.
 The configured TCP server port of the server.
 .It Ic $SERVER_NAME
 The name of the server.
+.It Ic $HTTP_HOST
+The host from the HTTP Host header.
 .It Pf % Ar n
 The capture index
 .Ar n

begin-base64 644 http_host.diff
SW5kZXg6IHVzci5zYmluL2h0dHBkL3NlcnZlcl9odHRwLmMKPT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTog
L2N2cy9zcmMvdXNyLnNiaW4vaHR0cGQvc2VydmVyX2h0dHAuYyx2CnJldHJpZXZpbmcgcmV2aXNp
b24gMS4xMTUKZGlmZiAtdSAtcCAtcjEuMTE1IHNlcnZlcl9odHRwLmMKLS0tIHVzci5zYmluL2h0
dHBkL3NlcnZlcl9odHRwLmMJMTAgTWFyIDIwMTcgMjE6MDY6NDMgLTAwMDAJMS4xMTUKKysrIHVz
ci5zYmluL2h0dHBkL3NlcnZlcl9odHRwLmMJMTEgTWFyIDIwMTcgMTc6NTE6MjMgLTAwMDAKQEAg
LTEwNjgsNiArMTA2OCwxOCBAQCBzZXJ2ZXJfZXhwYW5kX2h0dHAoc3RydWN0IGNsaWVudCAqY2x0
LCBjCiAJCWlmIChyZXQgIT0gMCkKIAkJCXJldHVybiAoTlVMTCk7CiAJfQorCWlmIChzdHJzdHIo
dmFsLCAiJEhUVFBfSE9TVCIpICE9IE5VTEwpIHsKKwkJaWYgKGRlc2MtPmh0dHBfaG9zdCA9PSBO
VUxMKSB7CisJCQlyZXQgPSBleHBhbmRfc3RyaW5nKGJ1ZiwgbGVuLCAiJEhUVFBfSE9TVCIsICIi
KTsKKwkJfSBlbHNlIHsKKwkJCWlmICgoc3RyID0gdXJsX2VuY29kZShkZXNjLT5odHRwX2hvc3Qp
KSA9PSBOVUxMKQorCQkJCXJldHVybiAoTlVMTCk7CisJCQlyZXQgPSBleHBhbmRfc3RyaW5nKGJ1
ZiwgbGVuLCAiJEhUVFBfSE9TVCIsIHN0cik7CisJCQlmcmVlKHN0cik7CisJCX0KKwkJaWYgKHJl
dCAhPSAwKQorCQkJcmV0dXJuIChOVUxMKTsKKwl9CiAJaWYgKHN0cnN0cih2YWwsICIkUkVNT1RF
XyIpICE9IE5VTEwpIHsKIAkJaWYgKHN0cnN0cih2YWwsICIkUkVNT1RFX0FERFIiKSAhPSBOVUxM
KSB7CiAJCQlpZiAocHJpbnRfaG9zdCgmY2x0LT5jbHRfc3MsCkluZGV4OiB1c3Iuc2Jpbi9odHRw
ZC9odHRwZC5jb25mLjUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2cy9zcmMvdXNyLnNiaW4vaHR0
cGQvaHR0cGQuY29uZi41LHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjc5CmRpZmYgLXUgLXAgLXIx
Ljc5IGh0dHBkLmNvbmYuNQotLS0gdXNyLnNiaW4vaHR0cGQvaHR0cGQuY29uZi41CTcgRmViIDIw
MTcgMTI6Mjc6NDIgLTAwMDAJMS43OQorKysgdXNyLnNiaW4vaHR0cGQvaHR0cGQuY29uZi41CTEx
IE1hciAyMDE3IDE3OjUxOjIzIC0wMDAwCkBAIC0yMjEsNiArMjIxLDggQEAgVGhlIGNvbmZpZ3Vy
ZWQgSVAgYWRkcmVzcyBvZiB0aGUgc2VydmVyLgogVGhlIGNvbmZpZ3VyZWQgVENQIHNlcnZlciBw
b3J0IG9mIHRoZSBzZXJ2ZXIuCiAuSXQgSWMgJFNFUlZFUl9OQU1FCiBUaGUgbmFtZSBvZiB0aGUg
c2VydmVyLgorLkl0IEljICRIVFRQX0hPU1QKK1RoZSBob3N0IGZyb20gdGhlIEhUVFAgSG9zdCBo
ZWFkZXIuCiAuSXQgUGYgJSBBciBuCiBUaGUgY2FwdHVyZSBpbmRleAogLkFyIG4K




Re: arm64 setjmp/longjmp once again.

2017-03-11 Thread Theo de Raadt
> > setjmp.S and _setjmp.S were modified to save the full 128 bit floating
> > point registers instead of only the 64 bit portion of the registers.
> 
> Both Linux and Android
> 
> * Save x19-x30 + sp (x31)
> * Save d8-d15 (so only the 64-bit portion of the registers)
> * Do not save fpcr.
> 
> I don't think we should deviate from that unless we have a good reason
> to do so.

Agree.

> I also think we should make jmpbuf fully opaque, and simply remove the
> _JB_XXX constants from .

Indeed.  Some study of the ports tree happened last year.  Only a few
programs use the fields, and inside #ifdef OS + #ifdef ARCH fields,
typically as hand-built thread API or a debugging/inspection method.
Very few cases of this, generally in very old code.  If I recall only
a few did modification of SP and PC, others did inspection of SP, PC,
and "first argument".

No need to extend such support to new architectures.

> The plan is to "encrypt" the contents of jmpbuf so users shouldn't be
> messing around with its contents.

xor safety is now enforced on most architectures.  That's paving the
way for us to be sure we can do authentication or encryption. Auth
would entail replacing the two-value xor with something like a hmac,
but still exposing the registers for inspection by
debugging/inspection methods.  Encryption would hide the values on the
stack further, not sure what the gain would be yet.  The difficulty is
that this is written in asm, and painful to get right.

> It'd be good to document the layout somewhere in the source code
> though, e.g. in setjmp.S.

If _JB-XXX fields disappear from .h files, then the layout is only
handled inside the .S file.  Correct place to document it, if the asm
doesn't make it clear.

> If we want, I think we can adjust the size of jmpbuf.  No formal
> release yet and I don't think it's a difficial ABI break to overcome.

Our base uses so few setjmp calls, so an ABI break in this area is
really inexpensive, just get through a build and it's done.

Dale, please look at the xor handling in .S files on other architectures.



Re: arm64 setjmp/longjmp once again.

2017-03-11 Thread Mark Kettenis
> Date: Fri, 10 Mar 2017 02:14:00 -0500
> From: Dale Rahn 
> 
> Yesterday's comments about setjmp caused me to dig more deeply into the
> function today. Here are several fixes. There is still one possibly
> outstanding issue with fpsr. When reading thru the calling convention
> it seemed to indicate that the rounding mode was not to be assumed.
> (Document is 
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf)
> 
>  These fields [in FPSR] are not preserved across a public interface and may
>  have any value on entry to a subroutine.
> 
> This would seem to indicate that none of those fields need to be preserved,
> however should fpcr (rounding modes) be saved and restored?  The text
> doesn't seem to give any indication about saving that state across routines.
> 
> setjmp.h had never been updated for arm64, the defines were all from arm32.
> It was necessary to move the signal mask because after saving the full
> floating point context, the old save location was used by the fp context.
> Also the context is quite a bit larger than necessary 64 * 8 bytes,
> where the structure is only around 31 * 8 bytes in context.
> 
> setjmp.S and _setjmp.S were modified to save the full 128 bit floating
> point registers instead of only the 64 bit portion of the registers.

Both Linux and Android

* Save x19-x30 + sp (x31)
* Save d8-d15 (so only the 64-bit portion of the registers)
* Do not save fpcr.

I don't think we should deviate from that unless we have a good reason
to do so.

I also think we should make jmpbuf fully opaque, and simply remove the
_JB_XXX constants from .  The plan is to "encrypt"
the contents of jmpbuf so users shouldn't be messing around with its
contents.  Again Linux and Android don't expose such constants either.
It'd be good to document the layout somewhere in the source code
though, e.g. in setjmp.S.

If we want, I think we can adjust the size of jmpbuf.  No formal
release yet and I don't think it's a difficial ABI break to overcome.

> _setjmp.S was modified to have _longjmp always return non-zero, effectively
> the same diff as was applied to setjmp.S recently.
> 
> Finally, the regress/lib/libc/setjmp-signal test was wrong, it was
> attempting to write to a null pointer, however the compiler was optimizing
> away the NULL deref and replacing it with a breakpoint instruction.
> Adding a volatile defeats the compiler optimization, this may not be
> the best fix for this issue. Is there better suggestions?

I think it's perfectly fine.  So ok kettenis@ on that bit.

> Index: sys/arch/arm64/include/setjmp.h
> ===
> RCS file: /cvs/src/sys/arch/arm64/include/setjmp.h,v
> retrieving revision 1.1
> diff -u -p -r1.1 setjmp.h
> --- sys/arch/arm64/include/setjmp.h   17 Dec 2016 23:38:33 -  1.1
> +++ sys/arch/arm64/include/setjmp.h   10 Mar 2017 06:41:15 -
> @@ -16,27 +16,32 @@
>   * Description of the setjmp buffer
>   *
>   * word  0   magic number(dependant on creator)
> - *   1 -  3  f4  fp register 4
> - *4 -  6 f5  fp register 5
> - *7 -  9 f6  fp register 6
> - *   10 - 12 f7  fp register 7
> - *   13  fpsrfp status register
> - *   14  r4  register 4
> - *   15  r5  register 5
> - *   16  r6  register 6
> - *   17  r7  register 7
> - *   18  r8  register 8
> - *   19  r9  register 9
> - *   20  r10 register 10 (sl)
> - *   21  r11 register 11 (fp)
> - *   22  r12 register 12 (ip)
> - *   23  r13 register 13 (sp)
> - *   24  r14 register 14 (lr)
> - *   25  signal mask (dependant on magic)
> - *   26  (con't)
> - *   27  (con't)
> - *   28  (con't)
> - *
> + *   1   sp  stack
> + *   2   x19 register 19
> + *   3   x20 register 20
> + *   4   x21 register 21
> + *   5   x22 register 22
> + *   6   x23 register 23
> + *   7   x24 register 24
> + *   8   x25 register 25
> + *   9   x26 register 26
> + *  10   x27 register 27
> + *  11   x28 register 28
> + *  12   x29 register 29
> + *  13   x30 register 30
> + *   14  q8  fp register 8
> + *   16  q9  fp register 9
> + *   18  q10 fp register 10
> + *   20  q11 fp register 11
> + *   22  q12 fp register 12
> + *   24  q13 fp register 13
> + *   26  q14 fp register 14
> + *   28  v15 fp register 15
> + *   30  signal mask (dependant on magic)
> + *   31  (con't)
> + *   32  (con't)
> + *   33  

Re: Empty usb vendor and product strings

2017-03-11 Thread Martin Pieuchot
On 11/03/17(Sat) 16:39, Mark Kettenis wrote:
> The GL3521 USB 3 hub on the odroid XU4 returns empty vendor and
> product strings.  That makes us skip the lookup in our own tables and
> print a "vendor 0x05e3 pruduct 0x0616" string.  Not sure if that's
> intentional (can't think of a good reason).  If it isn't, I propose
> the diff below.

If you sure there's no problem in usbd_get_string() then I'd rather
change the function to return NULL if an empty string is found.

> 
> ok?
> 
> 
> Index: usb_subr.c
> ===
> RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
> retrieving revision 1.131
> diff -u -p -r1.131 usb_subr.c
> --- usb_subr.c19 Sep 2016 16:46:10 -  1.131
> +++ usb_subr.c11 Mar 2017 15:12:08 -
> @@ -254,9 +254,9 @@ usbd_devinfo_vp(struct usbd_device *dev,
>   product = usbd_get_string(dev, udd->iProduct, p, pl);
>   usbd_trim_spaces(product);
>   } else {
> - if (dev->vendor != NULL)
> + if (dev->vendor != NULL && *dev->vendor)
>   vendor = dev->vendor;
> - if (dev->product != NULL)
> + if (dev->product != NULL && *dev->product)
>   product = dev->product;
>   }>  #ifdef USBVERBOSE
> 



Re: pledge vs. sockopt IP_HDRINCL

2017-03-11 Thread Theo de Raadt
> pledge() currently forbids IP_HDRINCL in setsockopt().
> 
> If I allow it in "inet", I can pledge /usr/ports/net/mtr (a traceroute tool)
> to "stdio rpath inet dns tty".
> 
> Is this safe? Should I require something else than "inet"?

No.  It blocks it intentionally.

We don't want "inet" programs in control of headers.

You've found 1 program that wants this, but by allowing it you are
permitting 300 others to suddenly gain it as a risk factor.


> 
> Index: kern_pledge.c
> ===
> RCS file: /cvs/src/sys/kern/kern_pledge.c,v
> retrieving revision 1.192
> diff -u -p -r1.192 kern_pledge.c
> --- kern_pledge.c 23 Jan 2017 05:49:24 -  1.192
> +++ kern_pledge.c 11 Mar 2017 08:33:19 -
> @@ -1414,6 +1414,7 @@ pledge_sockopt(struct proc *p, int set, 
>   case IP_PORTRANGE:
>   case IP_RECVDSTADDR:
>   case IP_RECVDSTPORT:
> + case IP_HDRINCL:
>   return (0);
>   case IP_MULTICAST_IF:
>   case IP_ADD_MEMBERSHIP:
> 



Empty usb vendor and product strings

2017-03-11 Thread Mark Kettenis
The GL3521 USB 3 hub on the odroid XU4 returns empty vendor and
product strings.  That makes us skip the lookup in our own tables and
print a "vendor 0x05e3 pruduct 0x0616" string.  Not sure if that's
intentional (can't think of a good reason).  If it isn't, I propose
the diff below.

ok?


Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.131
diff -u -p -r1.131 usb_subr.c
--- usb_subr.c  19 Sep 2016 16:46:10 -  1.131
+++ usb_subr.c  11 Mar 2017 15:12:08 -
@@ -254,9 +254,9 @@ usbd_devinfo_vp(struct usbd_device *dev,
product = usbd_get_string(dev, udd->iProduct, p, pl);
usbd_trim_spaces(product);
} else {
-   if (dev->vendor != NULL)
+   if (dev->vendor != NULL && *dev->vendor)
vendor = dev->vendor;
-   if (dev->product != NULL)
+   if (dev->product != NULL && *dev->product)
product = dev->product;
}
 #ifdef USBVERBOSE



OF_getindex() API

2017-03-11 Thread Mark Kettenis
A recurring pattern in device trees is that there is a "xxx-names"
property that allows you to lookup an entry in the corresponding "xxx"
property by names.  Examples that we already use in our tree are
"clock-names", "reset-names" and "pinctrl-names".  There is duplicated
code to do this for all three cases, and I just found myself writing
similar code yet again.  So here is a diff that adds a new generic
openfirmware.h API that does such a lookup.  It accepts a node handle,
the name of the entry you're looking up and the name of the propery 

The casts are (unfortunately) necessary because the API dealing with
properties isn't const-correct.

ok?


Index: dev/ofw/fdt.c
===
RCS file: /cvs/src/sys/dev/ofw/fdt.c,v
retrieving revision 1.19
diff -u -p -r1.19 fdt.c
--- dev/ofw/fdt.c   23 Aug 2016 18:12:09 -  1.19
+++ dev/ofw/fdt.c   11 Mar 2017 13:32:31 -
@@ -18,8 +18,8 @@
  */
 
 #include 
-#include 
 #include 
+#include 
 
 #include 
 #include 
@@ -905,3 +905,34 @@ OF_is_compatible(int handle, const char 
return (fdt_is_compatible(node, name));
 }
 
+int
+OF_getindex(int handle, const char *entry, const char *prop)
+{
+   char *names;
+   char *name;
+   char *end;
+   int idx = 0;
+   int len;
+
+   if (entry == NULL)
+   return 0;
+
+   len = OF_getproplen(handle, (char *)prop);
+   if (len <= 0)
+   return -1;
+
+   names = malloc(len, M_TEMP, M_WAITOK);
+   OF_getprop(handle, (char *)prop, names, len);
+   end = names + len;
+   name = names;
+   while (name < end) {
+   if (strcmp(name, entry) == 0) {
+   free(names, M_TEMP, len);
+   return idx;
+   }
+   name += strlen(name) + 1;
+   idx++;
+   }
+   free(names, M_TEMP, len);
+   return -1;
+}
Index: dev/ofw/ofw_clock.c
===
RCS file: /cvs/src/sys/dev/ofw/ofw_clock.c,v
retrieving revision 1.7
diff -u -p -r1.7 ofw_clock.c
--- dev/ofw/ofw_clock.c 27 Aug 2016 16:50:40 -  1.7
+++ dev/ofw/ofw_clock.c 11 Mar 2017 13:32:31 -
@@ -120,38 +120,6 @@ clock_next_clock(uint32_t *cells)
return cells + ncells + 1;
 }
 
-int
-clock_index(int node, const char *clock)
-{
-   char *names;
-   char *name;
-   char *end;
-   int idx = 0;
-   int len;
-
-   if (clock == NULL)
-   return 0;
-
-   len = OF_getproplen(node, "clock-names");
-   if (len <= 0)
-   return -1;
-
-   names = malloc(len, M_TEMP, M_WAITOK);
-   OF_getprop(node, "clock-names", names, len);
-   end = names + len;
-   name = names;
-   while (name < end) {
-   if (strcmp(name, clock) == 0) {
-   free(names, M_TEMP, len);
-   return idx;
-   }
-   name += strlen(name) + 1;
-   idx++;
-   }
-   free(names, M_TEMP, len);
-   return -1;
-}
-
 uint32_t
 clock_get_frequency_idx(int node, int idx)
 {
@@ -186,7 +154,7 @@ clock_get_frequency(int node, const char
 {
int idx;
 
-   idx = clock_index(node, name);
+   idx = OF_getindex(node, name, "clock-names");
if (idx == -1)
return 0;
 
@@ -227,7 +195,7 @@ clock_set_frequency(int node, const char
 {
int idx;
 
-   idx = clock_index(node, name);
+   idx = OF_getindex(node, name, "clock-names");
if (idx == -1)
return -1;
 
@@ -266,7 +234,7 @@ clock_do_enable(int node, const char *na
 {
int idx;
 
-   idx = clock_index(node, name);
+   idx = OF_getindex(node, name, "clock-names");
if (idx == -1)
return;
 
@@ -344,38 +312,6 @@ reset_next_reset(uint32_t *cells)
return cells + ncells + 1;
 }
 
-int
-reset_index(int node, const char *reset)
-{
-   char *names;
-   char *name;
-   char *end;
-   int idx = 0;
-   int len;
-
-   if (reset == NULL)
-   return 0;
-
-   len = OF_getproplen(node, "reset-names");
-   if (len <= 0)
-   return -1;
-
-   names = malloc(len, M_TEMP, M_WAITOK);
-   OF_getprop(node, "reset-names", names, len);
-   end = names + len;
-   name = names;
-   while (name < end) {
-   if (strcmp(name, reset) == 0) {
-   free(names, M_TEMP, len);
-   return idx;
-   }
-   name += strlen(name) + 1;
-   idx++;
-   }
-   free(names, M_TEMP, len);
-   return -1;
-}
-
 void
 reset_do_assert_idx(int node, int idx, int assert)
 {
@@ -408,7 +344,7 @@ reset_do_assert(int node, const char *na
 {
int idx;
 
-   idx = reset_index(node, name);
+   idx = OF_getindex(node, name, "reset-names");
if (idx == -1)
return;
 

Re: dynamic RTS threshold in 11n mode

2017-03-11 Thread Stefan Sperling
On Sat, Mar 11, 2017 at 08:55:54AM +0900, Stefan Sperling wrote:
> On Sat, Mar 04, 2017 at 10:04:51PM +0100, Stefan Sperling wrote:
> > This diff makes the RTS threshold dynamic in 11n mode.
> > It flips the RTS threshold between DEFAULT (512 bytes) and MAX (the
> > maximum size of a non-aggregated 802.11 frame).
> 
> Things have been working fine for me with this diff.
> Any concerns about putting it in?

This diff is causing throughput regressions in some environments so
I am shelving it for now.



Re: special sequences %a, %c, %m, %v in PKG_PATH [Was: Re: Fix broken example link in packages.7]

2017-03-11 Thread Marc Espie
On Sat, Mar 11, 2017 at 08:42:37AM +, Raf Czlonka wrote:
> Hi all,
> 
> Ping.
> 
> How about something like this?
> 
> Recreated verbatim from pkg.conf.5:
> 
> Index: usr.sbin/pkg_add/pkg_add.1
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v
> retrieving revision 1.142
> diff -u -p -r1.142 pkg_add.1
> --- usr.sbin/pkg_add/pkg_add.127 Feb 2017 21:53:11 -  1.142
> +++ usr.sbin/pkg_add/pkg_add.111 Mar 2017 08:37:35 -
> @@ -225,7 +225,14 @@ All paths recognize special sequences
>  .Sq %a ,
>  .Sq %c ,
>  .Sq %m ,
> -.Sq %v .
> +.Sq %v ,
> +which will be expanded to
> +.Sq package architecture ,
> +.Sq OS version or snapshots ,
> +.Sq full mirror path
> +and
> +.Sq OS version
> +respectively.
>  .Pp
>  The following examples are valid:
>  .Bd -literal -offset indent

Hehe.
There's one specific reason the manpage hasn't been updated yet.
%c is going to be slightly more magic in 6.1 and later, because
there is going to be also a packages-stable directory, and %c
will automagically expand the path to two directories.



Re: "user" chroot (patch)

2017-03-11 Thread Mateusz Guzik
On Sat, Mar 11, 2017 at 05:02:14AM +, Kristaps Dzonsons wrote:
> In running risky non-root applications, it'd be great to chroot(2)
> without needing to be root.  But the manpage says no.  So I added a
> system call, uchroot(2), that does the following:
> 
>  (1) performs the change-root w/o checking for root
>  (2) disables setuid (flag is inherited)
> 
> The (2) plugs the hole wherein a non-root normal chroot could allow for
> privilege escalation by a cooked master.passwd and setuid.
> 
> Enclosed is a patch.  (Without the bits generated from make syscalls: I
> don't know whether that's preferred.  Also doesn't include the libc
> parts.)  It can't be this easy, can it?  What did I miss?
> 

fd tables can be shared between processes (see FORK_SHAREFILES). So in
particular if one process uchroots and another one performs execve, the
execve is done against the chroot while "ignore suid" is not set.

While this bit is easily fixable I think this is too hairy in general
and the feature is unnecessary for the intended purpose.

> My initial motivation is CGI scripts, which can and do pledge, yes, but
> I'd like to limit *path-pledged processes to a directory so scripts
> can't read everything else in /var/www.  For example, within /var/www,
> to (say) /vhosts/foo.com.
> 

I think the way to go is "will only use lookups against a file
descriptor" pledge. Nice added value is that programs can now use
different places in the tree with directory granulalrity as opposed to
having to chroot to the common parent.

This poses a problem with confining ".." lookups.  There is a hack in
FreeBSD to explicitly track them, but perhaps you will be fine enough
with disallowing ".."s in the first place.

-- 
Mateusz Guzik 



tcpmd5: unique SPIs necessary?

2017-03-11 Thread Stuart Henderson
Does anyone reading know about how SPIs are handled?

I have a patch for BIRD to adapt their existing Linux/FreeBSD support
for tcpmd5. It was originally written for Linux which requires a fixed
SPI (0x1000) and they do the same on FreeBSD, they don't have a way
to store SPI with the peer (and adding it looks fiddly).

OpenBGPd does fetch a new SPI from the kernel but I think it's needed
there because it's used to support IPsec as well as tcpmd5.

Patched BIRD functions OK in tests using a fixing SPI - add/remove all
work - just wondering if I'm setting up for trouble by not using unique
ones, or whether it just means it can't have multiple tcpmd5 SAs for
the same host (e.g. for different ports, which is unlikely to be of any
practical use).



Re: pledge vs. sockopt IP_HDRINCL

2017-03-11 Thread Sebastien Marie
On Sat, Mar 11, 2017 at 05:44:51PM +0900, Stefan Sperling wrote:
> pledge() currently forbids IP_HDRINCL in setsockopt().
> 
> If I allow it in "inet", I can pledge /usr/ports/net/mtr (a traceroute tool)
> to "stdio rpath inet dns tty".
> 

IP_HDRINCL is used in net/mtr to avoid defining multiples sockets (one
per protocol) and to control TOS and TTL fields in the IP header.

As alternative code is present in net.c (in case IP_HDRINCL isn't
defined), isn't possible to use it instead of extending "inet" promise ?

Thanks.
-- 
Sebastien Marie



pledge vs. sockopt IP_HDRINCL

2017-03-11 Thread Stefan Sperling
pledge() currently forbids IP_HDRINCL in setsockopt().

If I allow it in "inet", I can pledge /usr/ports/net/mtr (a traceroute tool)
to "stdio rpath inet dns tty".

Is this safe? Should I require something else than "inet"?

Index: kern_pledge.c
===
RCS file: /cvs/src/sys/kern/kern_pledge.c,v
retrieving revision 1.192
diff -u -p -r1.192 kern_pledge.c
--- kern_pledge.c   23 Jan 2017 05:49:24 -  1.192
+++ kern_pledge.c   11 Mar 2017 08:33:19 -
@@ -1414,6 +1414,7 @@ pledge_sockopt(struct proc *p, int set, 
case IP_PORTRANGE:
case IP_RECVDSTADDR:
case IP_RECVDSTPORT:
+   case IP_HDRINCL:
return (0);
case IP_MULTICAST_IF:
case IP_ADD_MEMBERSHIP:



special sequences %a, %c, %m, %v in PKG_PATH [Was: Re: Fix broken example link in packages.7]

2017-03-11 Thread Raf Czlonka
Hi all,

Ping.

How about something like this?

Recreated verbatim from pkg.conf.5:

Index: usr.sbin/pkg_add/pkg_add.1
===
RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v
retrieving revision 1.142
diff -u -p -r1.142 pkg_add.1
--- usr.sbin/pkg_add/pkg_add.1  27 Feb 2017 21:53:11 -  1.142
+++ usr.sbin/pkg_add/pkg_add.1  11 Mar 2017 08:37:35 -
@@ -225,7 +225,14 @@ All paths recognize special sequences
 .Sq %a ,
 .Sq %c ,
 .Sq %m ,
-.Sq %v .
+.Sq %v ,
+which will be expanded to
+.Sq package architecture ,
+.Sq OS version or snapshots ,
+.Sq full mirror path
+and
+.Sq OS version
+respectively.
 .Pp
 The following examples are valid:
 .Bd -literal -offset indent


On Thu, Mar 02, 2017 at 09:20:20AM GMT, Raf Czlonka wrote:
> On Wed, Mar 01, 2017 at 10:39:08PM GMT, Frederic Cambus wrote:
> > On Tue, Feb 28, 2017 at 09:14:49PM +, Stuart Henderson wrote:
> > > On 2017/02/28 20:28, Frederic Cambus wrote:
> > > > Hi tech@,
> > > > 
> > > > In packages.7, PKG_PATH points to a broken link. This diff fixes it.
> > > 
> > > https is going to be horrible for pkg_add -u...
> > 
> > Following tj@ and sthen@ suggestions, use %c and %a instead of
> > hardcoding strings, and switch to http instead of https.
> 
> Hi all,
> 
> There's a small issue with the special sequences %a, %c, %m and %v.
> With the removal of pkg.conf(5), these are only mentioned in
> pkg_add(1) but it is not explained what they actually mean.
> 
> They're still going to be supported in the next release I take it?
> 
> Regards,
> 
> Raf
> 
> > Index: share/man/man7/packages.7
> > ===
> > RCS file: /cvs/src/share/man/man7/packages.7,v
> > retrieving revision 1.40
> > diff -u -p -r1.40 packages.7
> > --- share/man/man7/packages.7   24 Oct 2015 08:44:49 -  1.40
> > +++ share/man/man7/packages.7   1 Mar 2017 14:28:07 -
> > @@ -240,7 +240,7 @@ are supported: pointing
> >  .Ev PKG_PATH
> >  to a distant package repository, e.g.,
> >  .Bd -literal -offset 1n
> > -# export PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/5.2/packages/i386/
> > +# export PKG_PATH=http://ftp.openbsd.org/pub/OpenBSD/%c/packages/%a/
> >  .Ed
> >  .Pp
> >  will let
> >