Re: LibreSSL 2.2.2 release

[Brent Cook]

On Mon, Aug 10, 2015 at 5:10 AM, Mark Kettenis  wrote:
> Jan Engelhardt schreef op 2015-08-10 10:29:
>
>> On Monday 2015-08-10 02:38, Brent Cook wrote:

 On Aug 9, 2015, at 10:07 AM, Jan Engelhardt  wrote:

> We have released LibreSSL 2.2.2, which will be arriving in the
> LibreSSL directory of your local OpenBSD mirror soon.


 The .pc files in libressl-2.2.2 upset the package mechanisms at hand, in
 particular rpm, where ':' is used to denote the (ancient concept of)
 epochs.

 [   99s] Invalid version (double separator ':'): 35:0:0:
 mingw32(pkg:libcrypto) = 35:0:0
 [   99s] mingw32(pkg:libssl) = 35:0:0
 [   99s] mingw32(pkg:libtls) = 6:0:0
 [   99s] mingw32(pkg:openssl) = 2.2.2

 The version: field in .pc files is (still) supposed to be the
 package version number, not the ABI number, and this was not a problem
 in libressl <= 2.2.1.
>>>
>>>
>>> Thanks for the note, Jan.
>>>
>>> Right or wrong, I'm fairly certain the format has not changed any time
>>> recently, e.g. here is the libtls .pc file from 2.2.1:
>>
>>
>> So it turns out rpm does not consider it an error, just a warning (but it
>> is the first time the warning showed up on the last screenful, the one
>> paid most attention to).
>>
>>> I'm not so sure that this should be the package version number though.
>>> Can you
>>> point to some further documentation here?
>>
>>
>> pkg-config(1): "Version:
>> This   should  be  the  most-specific-possible  package  version
>> string."
>>
>> * x:0:0 is not specific enough, as it would not change when the ABI-API
>>   stays unmodified between two releases.
>>
>> * the observation that all other .pc files I happen to have installed
>>   on my machine right now (some 194) all match \d+(\.\d+)*

Thanks. That matches my observation too.

>
> Right.  Brent, looks like you used the libtool version specification here,
> which is (primarily) about encoding the ABI.  But for pkg-config it's
> the API that's important.  Hence the tradition to simply use the package
> version number here, since that will change (by definition) when the API
> changes, but will also change when there are just some bug fixes (which
> people might want to check for).  Configure scripts will often contain
> checks
> for the package version number to be larger or equal (using pkg-config
> --atleast-version) to some version that is known to have all features
> required for building the software.
>
> So I think all the .pc files in LibreSSL should simply use the LibreSSL
> version number (2.2.2) like the openssl.pc does.  This does mean that
> checking
> for individual libraries in LibreSSL version 2.2.2 and older will probably
> busted, but such is life.  Not sure how the colon-separated version strings
> interact with --atleast-version.  Might be worth checking that out.

The main exception I found was that ffmpeg encoded ABI rather than API
in its .pc files too, but your explanations make sense to me.

I'm happy that people are noticing issues like this now, since it
means the files are getting some use :) I'll make the change for the
next release.

> Cheers,
>
> Mark
>
> P.S. OpenBSD still ships with .pc files that have 1.0.0 as the version
> number.  We might want to change that at some point, but this should be
> coordinated with the ports people.
>
>

ssh_config.5 sshd_config.5 - update cipher order

[Brian Conway]

This matches the current myproposal.h ordering with
chacha20-poly1305's promotion (and referenced in various release
notes). Please correct if I've misunderstood or misformatted. Thanks.

Index: usr.bin/ssh/ssh_config.5
===
RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v
retrieving revision 1.214
diff -u -p -u -p -r1.214 ssh_config.5
--- usr.bin/ssh/ssh_config.5 30 Jul 2015 00:01:34 - 1.214
+++ usr.bin/ssh/ssh_config.5 11 Aug 2015 02:54:48 -
@@ -415,9 +415,9 @@ chacha20-poly1...@openssh.com
 .Pp
 The default is:
 .Bd -literal -offset indent
+chacha20-poly1...@openssh.com,
 aes128-ctr,aes192-ctr,aes256-ctr,
 aes128-...@openssh.com,aes256-...@openssh.com,
-chacha20-poly1...@openssh.com,
 arcfour256,arcfour128,
 aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,
 aes192-cbc,aes256-cbc,arcfour
Index: usr.bin/ssh/sshd_config.5
===
RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v
retrieving revision 1.210
diff -u -p -u -p -r1.210 sshd_config.5
--- usr.bin/ssh/sshd_config.5 6 Aug 2015 14:53:21 - 1.210
+++ usr.bin/ssh/sshd_config.5 11 Aug 2015 02:54:48 -
@@ -477,9 +477,9 @@ chacha20-poly1...@openssh.com
 .Pp
 The default is:
 .Bd -literal -offset indent
+chacha20-poly1...@openssh.com,
 aes128-ctr,aes192-ctr,aes256-ctr,
-aes128-...@openssh.com,aes256-...@openssh.com,
-chacha20-poly1...@openssh.com
+aes128-...@openssh.com,aes256-...@openssh.com
 .Ed
 .Pp
 The list of available ciphers may also be obtained using the

Brian Conway

Re: Less strict requirement for USB_REQUEST ioctl

[Theo de Raadt]

> ludovic coues schreef op 2015-08-10 23:29:
> > 2015-08-10 22:56 GMT+02:00 Martin Pieuchot :
> >> On 30/07/15(Thu) 12:18, Ludovic Coues wrote:
> >>> Right now, an USB_REQUEST ioctl will fail with an EBADF error if done
> >>> on a device opened as read-only. With this patch, the ioctl will fail
> >>> only if the USB_REQUEST is a write request.
> >> 
> >> Do you need this to be able to use your usbdevs-like tool as a normal
> >> use with the "w" bit on a /dev/usb node?
> >> 
> > 
> > In the case a user have the read right on the node without the write
> > right, this patch would allow the normal use of my usbdevs-like tools
> > for this user.
> > 
> > In a system with default permission, this won't change anything as
> > root and wheel have read + write permission on /dev/usb nodes and
> > everybody else have nothing.
> 
> Well, the point is that the USB_REQUEST ioctl sends a command to the 
> device.  In that sense, it always involves a "write" to the device even
> if the command issued is a "read" command.  The fact that there is only 
> data transfer from the device to the host doesn't mean it doesn't affect
> the state of the device.
> 
> I think the current code is right.  If you open the node read-only, you 
> only get to see the kernel state for the device.  If you open with write 
> permission, you get full control over the device.

Essentially the OP wants to completely remove the security model, running
unknown lines of code in the kernel, and in the firmware of the actual
device, causing unknown responses to trigger bugs on the underside of
the USB stack.

Then why not open it as root?  Oh, because you have no root privilege
to exercise those code paths on purpose.  That's the whole idea of this
seperation.

Do you understand?

Re: worm(6): exit earlier if given invalid arg

[Ted Unangst]

Michael Reed wrote:
> I only have a very loose idea of what gets accepted or not when the tree
> is "locked", so apologies if this should have been sent at a different
> time.

patches are always welcome. they just get overlooked sometimes. :)

> Index: worm.c
> ===
> RCS file: /cvs/src/games/worm/worm.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 worm.c
> --- worm.c9 Mar 2015 19:52:02 -   1.28
> +++ worm.c10 Aug 2015 19:06:06 -
> @@ -93,6 +93,14 @@ main(int argc, char **argv)
>   struct pollfd pfd[1];
>   const char *errstr;
>  
> + if (argc >= 2) {
> + start_len = strtonum(argv[1], 1, ((LINES-3) * (COLS-2)) / 3,
> + &errstr);
> + if (errstr) {
> + endwin();
> + errx(1, "length argument is %s.", errstr);
> + }
> + }
>   setbuf(stdout, outbuf);
>   signal(SIGINT, leave);

Unfortunately, this doesn't look right. Now it's calling endwin() before it
calls initscr(). And it's still using LINES and COLS. I think we may just live
with the flashing.

Re: Less strict requirement for USB_REQUEST ioctl

[Mark Kettenis]

ludovic coues schreef op 2015-08-10 23:29:

2015-08-10 22:56 GMT+02:00 Martin Pieuchot :

On 30/07/15(Thu) 12:18, Ludovic Coues wrote:

Right now, an USB_REQUEST ioctl will fail with an EBADF error if done
on a device opened as read-only. With this patch, the ioctl will fail
only if the USB_REQUEST is a write request.


Do you need this to be able to use your usbdevs-like tool as a normal
use with the "w" bit on a /dev/usb node?



In the case a user have the read right on the node without the write
right, this patch would allow the normal use of my usbdevs-like tools
for this user.

In a system with default permission, this won't change anything as
root and wheel have read + write permission on /dev/usb nodes and
everybody else have nothing.


Well, the point is that the USB_REQUEST ioctl sends a command to the 
device.
In that sense, it always involves a "write" to the device even if the 
command
issued is a "read" command.  The fact that there is only data transfer 
from the
device to the host doesn't mean it doesn't affect the state of the 
device.


I think the current code is right.  If you open the node read-only, you 
only
get to see the kernel state for the device.  If you open with write 
permission,

you get full control over the device.

Re: Less strict requirement for USB_REQUEST ioctl

[ludovic coues]

2015-08-10 22:56 GMT+02:00 Martin Pieuchot :
> On 30/07/15(Thu) 12:18, Ludovic Coues wrote:
>> Right now, an USB_REQUEST ioctl will fail with an EBADF error if done
>> on a device opened as read-only. With this patch, the ioctl will fail
>> only if the USB_REQUEST is a write request.
>
> Do you need this to be able to use your usbdevs-like tool as a normal
> use with the "w" bit on a /dev/usb node?
>

In the case a user have the read right on the node without the write
right, this patch would allow the normal use of my usbdevs-like tools
for this user.

In a system with default permission, this won't change anything as
root and wheel have read + write permission on /dev/usb nodes and
everybody else have nothing.


-- 

Cordialement, Coues Ludovic
+336 148 743 42

rtfree(9)

[Martin Pieuchot]

Convert two rt->rt_refcnt-- to rtfree(rt).  In both cases the entry
is returned from rtrequest1(RTM_ADD, ...) and wont be freed because
it currently *is* in the table.

Ok?

Index: net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.217
diff -u -p -r1.217 route.c
--- net/route.c 18 Jul 2015 15:51:16 -  1.217
+++ net/route.c 10 Aug 2015 21:04:11 -
@@ -1181,7 +1181,6 @@ rt_ifa_add(struct ifaddr *ifa, int flags
 
error = rtrequest1(RTM_ADD, &info, prio, &nrt, rtableid);
if (error == 0 && (rt = nrt) != NULL) {
-   rt->rt_refcnt--;
if (rt->rt_ifa != ifa) {
printf("%s: wrong ifa (%p) was (%p)\n", __func__,
ifa, rt->rt_ifa);
@@ -1201,8 +1200,9 @@ rt_ifa_add(struct ifaddr *ifa, int flags
 * userland that a new address has been added.
 */
if (flags & RTF_LOCAL)
-   rt_sendaddrmsg(nrt, RTM_NEWADDR);
-   rt_sendmsg(nrt, RTM_ADD, rtableid);
+   rt_sendaddrmsg(rt, RTM_NEWADDR);
+   rt_sendmsg(rt, RTM_ADD, rtableid);
+   rtfree(rt);
}
return (error);
 }
Index: net/rtsock.c
===
RCS file: /cvs/src/sys/net/rtsock.c,v
retrieving revision 1.166
diff -u -p -r1.166 rtsock.c
--- net/rtsock.c18 Jul 2015 21:58:06 -  1.166
+++ net/rtsock.c10 Aug 2015 21:00:58 -
@@ -598,11 +598,11 @@ route_output(struct mbuf *m, ...)
if (error == 0 && saved_nrt) {
rt_setmetrics(rtm->rtm_inits, &rtm->rtm_rmx,
&saved_nrt->rt_rmx);
-   saved_nrt->rt_refcnt--;
/* write back the priority the kernel used */
rtm->rtm_priority = saved_nrt->rt_priority & RTP_MASK;
rtm->rtm_index = saved_nrt->rt_ifp->if_index;
rtm->rtm_flags = saved_nrt->rt_flags;
+   rtfree(saved_nrt);
}
break;
case RTM_DELETE:

Re: Less strict requirement for USB_REQUEST ioctl

[Martin Pieuchot]

On 30/07/15(Thu) 12:18, Ludovic Coues wrote:
> Right now, an USB_REQUEST ioctl will fail with an EBADF error if done
> on a device opened as read-only. With this patch, the ioctl will fail
> only if the USB_REQUEST is a write request.

Do you need this to be able to use your usbdevs-like tool as a normal
use with the "w" bit on a /dev/usb node?

> Index: sys/dev/usb/usb.c
> ===
> RCS file: /cvs/src/sys/dev/usb/usb.c,v
> retrieving revision 1.107
> diff -u -p -r1.107 usb.c
> --- sys/dev/usb/usb.c 14 Mar 2015 03:38:50 -  1.107
> +++ sys/dev/usb/usb.c 26 Jul 2015 16:16:52 -
> @@ -618,7 +618,8 @@ usbioctl(dev_t devt, u_long cmd, caddr_t
>   usbd_status err;
>   int error = 0;
>  
> - if (!(flag & FWRITE))
> + if ((flag & FWRITE) == 0
> + && (ur->ucr_request.bmRequestType & UT_READ) == 0)
>   return (EBADF);
>  
>   DPRINTF(("usbioctl: USB_REQUEST addr=%d len=%d\n", addr, len));

Really deprecate IN6_IFF_DEPRECATED

[Martin Pieuchot]

Since this backward compat' is here we can now assume that applications
have been updated to not set the IN6_IFF_DEPRECATED.  At least our base
is clean and I doubt any port still do that.

Ok?

Index: netinet6/in6.c
===
RCS file: /cvs/src/sys/netinet6/in6.c,v
retrieving revision 1.161
diff -u -p -r1.161 in6.c
--- netinet6/in6.c  18 Jul 2015 15:05:32 -  1.161
+++ netinet6/in6.c  10 Aug 2015 20:38:52 -
@@ -469,6 +469,7 @@ in6_control(struct socket *so, u_long cm
if ((ifra->ifra_flags & IN6_IFF_DUPLICATED) != 0 ||
(ifra->ifra_flags & IN6_IFF_DETACHED) != 0 ||
(ifra->ifra_flags & IN6_IFF_NODAD) != 0 ||
+   (ifra->ifra_flags & IN6_IFF_DEPRECATED) != 0 ||
(ifra->ifra_flags & IN6_IFF_AUTOCONF) != 0) {
return (EINVAL);
}
@@ -759,14 +760,6 @@ in6_update_ifa(struct ifnet *ifp, struct
 * configure address flags.
 */
ia6->ia6_flags = ifra->ifra_flags;
-   /*
-* backward compatibility - if IN6_IFF_DEPRECATED is set from the
-* userland, make it deprecated.
-*/
-   if ((ifra->ifra_flags & IN6_IFF_DEPRECATED) != 0) {
-   ia6->ia6_lifetime.ia6t_pltime = 0;
-   ia6->ia6_lifetime.ia6t_preferred = time_second;
-   }
/*
 * Make the address tentative before joining multicast addresses,
 * so that corresponding MLD responses would not have a tentative

Don't be verbose in in6_update_ifa()

[Martin Pieuchot]

In general these messages do not help.  Here we have two cases of
messages, either logged at LOG_INFO or LOG_ERR.

In the first case a proper error code is returned via ioctl(2), so
the userland application knows it has done something incorrect.

The second case correspond to a ENOMEM error, which is something that
can happen and is properly handled (goto cleanup).

Ok?

Index: netinet6/in6.c
===
RCS file: /cvs/src/sys/netinet6/in6.c,v
retrieving revision 1.161
diff -u -p -r1.161 in6.c
--- netinet6/in6.c  18 Jul 2015 15:05:32 -  1.161
+++ netinet6/in6.c  10 Aug 2015 20:38:04 -
@@ -633,17 +633,10 @@ in6_update_ifa(struct ifnet *ifp, struct
 * must be 128.
 */
if (ifra->ifra_dstaddr.sin6_family == AF_INET6) {
-   if ((ifp->if_flags & (IFF_POINTOPOINT|IFF_LOOPBACK)) == 0) {
-   /* XXX: noisy message */
-   nd6log((LOG_INFO, "in6_update_ifa: a destination can "
-   "be specified for a p2p or a loopback IF only\n"));
+   if ((ifp->if_flags & (IFF_POINTOPOINT|IFF_LOOPBACK)) == 0)
return (EINVAL);
-   }
-   if (plen != 128) {
-   nd6log((LOG_INFO, "in6_update_ifa: prefixlen should "
-   "be 128 when dstaddr is specified\n"));
+   if (plen != 128)
return (EINVAL);
-   }
}
/* lifetime consistency check */
lt = &ifra->ifra_lifetime;
@@ -703,10 +696,6 @@ in6_update_ifa(struct ifnet *ifp, struct
 */
if (ia6->ia_prefixmask.sin6_len &&
in6_mask2len(&ia6->ia_prefixmask.sin6_addr, NULL) != plen) {
-   nd6log((LOG_INFO, "in6_update_ifa: the prefix length of 
an"
-   " existing (%s) address should not be changed\n",
-   inet_ntop(AF_INET6, &ia6->ia_addr.sin6_addr,
-   addr, sizeof(addr;
error = EINVAL;
goto unlink;
}
@@ -806,14 +795,8 @@ in6_update_ifa(struct ifnet *ifp, struct
ifra->ifra_addr.sin6_addr.s6_addr32[3];
llsol.sin6_addr.s6_addr8[12] = 0xff;
imm = in6_joingroup(ifp, &llsol.sin6_addr, &error);
-   if (!imm) {
-   nd6log((LOG_ERR, "in6_update_ifa: "
-   "addmulti failed for %s on %s (errno=%d)\n",
-   inet_ntop(AF_INET6, &llsol.sin6_addr,
-   addr, sizeof(addr)),
-   ifp->if_xname, error));
+   if (!imm)
goto cleanup;
-   }
LIST_INSERT_HEAD(&ia6->ia6_memberships, imm, i6mm_chain);
 
bzero(&mltmask, sizeof(mltmask));
@@ -867,15 +850,8 @@ in6_update_ifa(struct ifnet *ifp, struct
rtfree(rt);
}
imm = in6_joingroup(ifp, &mltaddr.sin6_addr, &error);
-   if (!imm) {
-   nd6log((LOG_WARNING,
-   "in6_update_ifa: addmulti failed for "
-   "%s on %s (errno=%d)\n",
-   inet_ntop(AF_INET6, &mltaddr.sin6_addr,
-   addr, sizeof(addr)),
-   ifp->if_xname, error));
+   if (!imm)
goto cleanup;
-   }
LIST_INSERT_HEAD(&ia6->ia6_memberships, imm, i6mm_chain);
 
/*
@@ -884,11 +860,6 @@ in6_update_ifa(struct ifnet *ifp, struct
if (in6_nigroup(ifp, hostname, hostnamelen, &mltaddr) == 0) {
imm = in6_joingroup(ifp, &mltaddr.sin6_addr, &error);
if (!imm) {
-   nd6log((LOG_WARNING, "in6_update_ifa: "
-   "addmulti failed for %s on %s (errno=%d)\n",
-   inet_ntop(AF_INET6, &mltaddr.sin6_addr,
-   addr, sizeof(addr)),
-   ifp->if_xname, error));
/* XXX not very fatal, go on... */
} else {
LIST_INSERT_HEAD(&ia6->ia6_memberships,
@@ -935,14 +906,8 @@ in6_update_ifa(struct ifnet *ifp, struct
rtfree(rt);
}
imm = in6_joingroup(ifp, &mltaddr.sin6_addr, &error);
-   if (!imm) {
-   nd6log((LOG_WARNING, "in6_update_ifa: "
-   "addmulti failed for %s on %s (errno=%d)\n",
-   inet_ntop(AF_INET6, &mltaddr.sin6_addr,
-   addr, sizeof(addr)),
-   ifp->if_

vipw.8: small improvement

[Michael Reed]

Hi,

I figure that the text which this diff removes wasn't of much use
besides stating the obvious, as the meaning of list items in the
ENVIRONMENT section seems pretty consistent across the man pages.

Regards,
Michael


Index: src/usr.sbin/vipw/vipw.8
===
RCS file: /cvs/src/usr.sbin/vipw/vipw.8,v
retrieving revision 1.12
diff -u -p -r1.12 vipw.8
--- src/usr.sbin/vipw/vipw.813 Mar 2015 19:58:41 -  1.12
+++ src/usr.sbin/vipw/vipw.810 Aug 2015 19:24:26 -
@@ -77,8 +77,6 @@ Which type of cipher is used to encrypt 
 depends on the configuration in
 .Xr login.conf 5 .
 .Sh ENVIRONMENT
-If the following environment variable exists it will be utilized by
-.Nm vipw :
 .Bl -tag -width EDITOR
 .It Ev EDITOR
 The editor specified by the string

worm(6): exit earlier if given invalid arg

[Michael Reed]

Hi tech@,

I only have a very loose idea of what gets accepted or not when the tree
is "locked", so apologies if this should have been sent at a different
time.

If I launch worm(6) with an invalid argument, my terminal flashes once
before the strtonum error message is shown.  I assume this is because
various curses functions are called prior to the strtonum block, so the
patch below makes worm(6) quit sooner if an invalid argument is given.

I can reproduce this in st(1) if it's full-screened, as well as in xterm
(although it's less pronounced, not sure why).

Regards,
Michael

Index: worm.c
===
RCS file: /cvs/src/games/worm/worm.c,v
retrieving revision 1.28
diff -u -p -r1.28 worm.c
--- worm.c  9 Mar 2015 19:52:02 -   1.28
+++ worm.c  10 Aug 2015 19:06:06 -
@@ -93,6 +93,14 @@ main(int argc, char **argv)
struct pollfd pfd[1];
const char *errstr;
 
+   if (argc >= 2) {
+   start_len = strtonum(argv[1], 1, ((LINES-3) * (COLS-2)) / 3,
+   &errstr);
+   if (errstr) {
+   endwin();
+   errx(1, "length argument is %s.", errstr);
+   }
+   }
setbuf(stdout, outbuf);
signal(SIGINT, leave);
signal(SIGQUIT, leave);
@@ -110,14 +118,6 @@ main(int argc, char **argv)
growthscale = COLS * LINES / 2000;
if (growthscale == 0)
growthscale = 1;
-   if (argc >= 2) {
-   start_len = strtonum(argv[1], 1, ((LINES-3) * (COLS-2)) / 3,
-   &errstr);
-   if (errstr) {
-   endwin();
-   errx(1, "length argument is %s.", errstr);
-   }
-   }
stw = newwin(1, COLS-1, 0, 0);
tv = newwin(LINES-1, COLS-1, 1, 0);
box(tv, '*', '*');

linker error on loongson

[Matthieu Herrb]

Hi,

while trying to build a newer xserver 1.17 on loongson, I got the
folloing ld crash.

Apparently this is already using -fPIC so I don't know how to make
space for local GOT entries.

Making all in modesetting
/bin/sh ../../../../libtool  --tag=CC--mode=link gcc -std=gnu99  
-DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast 
-Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized 
-Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Werror=implicit 
-Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces 
-Werror=sequence-point -Werror=return-type -Werror=trigraphs 
-Werror=write-strings -Werror=address -Werror=int-to-pointer-cast 
-Werror=pointer-to-int-cast -fno-strict-aliasing -fno-strict-aliasing 
-I/usr/X11R6/include -D_DEFAULT_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN 
-DHAS_STICKY_DIR_BIT -I/usr/X11R6/include/X11/dri -I/usr/include/dev/pci/drm 
-I/usr/X11R6/include/pixman-1 -I/usr/X11R6/include/freetype2 
-I/usr/xenocara/xserver/include -I../../../../include 
-I/usr/xenocara/xserver/Xext -I/usr/xenocara/xserver/composite 
-I/usr/xenocara/xserver/dama!
 geext -I/usr/xenocara/xserver/xfixes -I/usr/xenocara/xserver/Xi 
-I/usr/xenocara/xserver/mi -I/usr/xenocara/xserver/miext/sync 
-I/usr/xenocara/xserver/miext/shadow  -I/usr/xenocara/xserver/miext/damage 
-I/usr/xenocara/xserver/render -I/usr/xenocara/xserver/randr 
-I/usr/xenocara/xserver/fb -I/usr/xenocara/xserver/dbe 
-I/usr/xenocara/xserver/present -fvisibility=hidden -DHAVE_XORG_CONFIG_H 
-fvisibility=hidden -I/usr/X11R6/include -I/usr/X11R6/include 
-I/usr/include/dev/pci/drm -DXF86PM -I/usr/X11R6/include -I/usr/X11R6/include 
-I/usr/include/dev/pci/drm  -Wall -Wpointer-arith -Wmissing-declarations 
-Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs 
-Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement 
-Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute 
-Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main 
-Werror=missing-braces -Werror=sequence-point -Werror=return-type 
-Werror=trigraphs -Werror=write-s!
 trings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast 
-fno-strict-aliasing -O2 -pipe -Wa,-xgot -module -avoid-version   -o 
modesetting_drv.la -rpath /usr/X11R6/lib/modules/drivers dri2.lo driver.lo 
drmmode_display.lo  dumb_bo.lo present.lo vblank.lo   -lm  
libtool: link: gcc -std=gnu99 -shared  -fPIC -DPIC -o .libs/modesetting_drv.so  
.libs/dri2.o .libs/driver.o .libs/drmmode_display.o .libs/dumb_bo.o 
.libs/present.o .libs/vblank.o   -lm  -O2  
/usr/bin/ld: not enough GOT space for local GOT entries
/usr/bin/ld: BFD 2.17 internal error, aborting at 
/usr/src/gnu/usr.bin/binutils-2.17/bfd/elfxx-mips.c line 7924 in 
_bfd_mips_elf_relocate_section

/usr/bin/ld: Please report this bug.

collect2: ld returned 1 exit status
*** Error 1 in obj/hw/xfree86/drivers/modesetting (Makefile:640 
'modesetting_drv.la')
*** Error 1 in obj/hw/xfree86/drivers (Makefile:553 'all-recursive')
*** Error 1 in obj/hw/xfree86 (Makefile:802 'all-recursive')
*** Error 1 in obj/hw/xfree86 (Makefile:598 'all')
*** Error 1 in obj/hw (Makefile:569 'all-recursive')
*** Error 1 in obj (Makefile:737 'all-recursive')
*** Error 1 in /usr/xenocara/xserver (/usr/X11R6/share/mk/bsd.xorg.mk:145 'all')

-- 
Matthieu Herrb

[Patch] Fix a typo in src/usr.sbin/relayd/relayd.conf.5

[Larry Hynes]

decleration -> declaration


Index: relayd.conf.5
===
RCS file: /cvs/src/usr.sbin/relayd/relayd.conf.5,v
retrieving revision 1.164
diff -u -p -r1.164 relayd.conf.5
--- relayd.conf.5   24 Jul 2015 15:25:08 -  1.164
+++ relayd.conf.5   10 Aug 2015 14:07:28 -
@@ -1110,7 +1110,7 @@ Forward the request to a server in the s
With this option, requests can be passed to specific backend servers.
A corresponding
.Ic forward to
-decleration in the
+declaration in the
.Sx RELAYS
section is required.
.El

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

[Theo de Raadt]

> It feels wasteful to develop a seemingly comprehensive and modular code
> scanner which will inherently find heaps of bugs, and then not release
> it or allow others to work with it.

Sam, since you think throwing opinions out there is valuable

Let me give me yours.

I think you should talk privately to Maxime and find out how much money
he wants from you, to release his tool.

Maxime, I suggest you take Sam for all he is worth.

That's my opinion in this situation.  I came to this opinion because
Sam feels so incredibly entitled.

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

[Theo de Raadt]

> I am also of the opinion that if somebody/a method can discover bugs,
> they should report them. And if they can't, that method should be
> disclosed to allow others to continue their work.

And my opinion is that Sam should back his opinions with lots of
money.

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

[Stuart Henderson]

On 2015/08/10 11:54, sam wrote:
> I am also of the opinion that if somebody/a method can discover bugs,
> they should report them. And if they can't, that method should be
> disclosed to allow others to continue their work.

So you think others "should" do work for you, right? Whether that work is in
discovering and reporting bugs, or in preparing their code for release so you
can use it (maybe tidying, writing docs, fielding bug reports, 
etc.etc.etc.)?

Like other developers who replied to this thread, I'm grateful to Maxime for
the reports in the past (also I totally understand wanting to stop spending
time on this!).

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

[sam]

On Fri, 7 Aug 2015 22:49:50 +0200
shun.obsd.t...@dropcut.net wrote:

> Hi Maxime,
> Hi Sam,
> 
> I have been following this thread (and others) for some time.
> 
> On Fri, Aug 07, 2015 at 09:55:21PM +0200, Maxime Villard wrote:
> > Well, I guess I'll have to admit that I find your attitude extremely
> > disrespectful.
> I have to agree that the emails are rather short and tend to lack the
> subtle cues of human face-to-face interaction. They can easily get
> out of hand.
> 
I'd like to agree with the sentiment here and in the rest of the mail.
The lack of body language and tone can result in misunderstandings. I
wasn't trying to be disrespectful.

It's very easy to pile on a person's comment on the internet.

It feels wasteful to develop a seemingly comprehensive and modular code
scanner which will inherently find heaps of bugs, and then not release
it or allow others to work with it.

I am of course grateful that Maxime and others report bugs, but it
feels unusual to me that it's acceptable for somebody to consistently
be able to find them with a tool, and yet nobody thinks it'd be a good
idea to have that tool shared if Maxime is willing.

As many here have acknowledged, Maxime's reports are a contribution. So
why not seek to have those contributions continue? _That_ was my point,
though it was poorly conveyed, falsely appearing to be sarcasm.

> 
> > Le 21/07/2015 12:31, sam a écrit :
> > >On Tue, 21 Jul 2015 11:31:44 +0200
> > >Maxime Villard  wrote:
> > >
> > >>Found by The Brainy Code Scanner.
> > >>
> > >>It is not the last bug Brainy has found, but it is the last one I
> > >>report. I don't have time for that.
> > >>
> > >
> > >How about you release the Brainy Code Scanner then?
> Maxime, I have to agree with Sam here. I did check your website, but
> have not found any code there. It would be of great help if you would
> release it.
> 
> > >"I have so many bugs; in fact, there are so many, I don't even
> > >have the time to report them! My scanner is so good!"
> > >
> > >Or perhaps you should report 'just' the relatively important ones?
> > 
> > I think my work does (or used to) benefit to a lot of users,
> > developers and vendors here; a lot of people, including you.
> Sam, I think Maxime has done good work so far. There is no reason to
> mock the work or the person. I thought the motto is "Shut Up and
> Hack!" and not "Ridicule and Hack!".
> 
> > Nobody supports my work, and I've never asked for anything here
> > about that. Even though I almost never receive a simple "thank you"
> > for all the bugs and vulnerabilities I've so far reported, I still
> > expect a "spiritual thank you" for my work.
> Yes, this is a common problem. Hence: Thank you Maxime! Thank you for
> all the bugs you (and Brainy) have found so far.
> 
> 
> > Developing, improving and maintaining Brainy takes time and energy,
> > as well as investigating and packaging the bugs and vulnerabilities
> > it finds.
> You could share that burden. I am willing to give it a shot.
> 
> shun
> 

regards,
sam

Re: Brainy: User-Triggerable Kernel Memory Leak in execve()

[sam]

I'm sorry, I misread you. I wasn't trying to make fun of you or
disregard your work.

Thanks for reporting this (among other bugs). 

I am also of the opinion that if somebody/a method can discover bugs,
they should report them. And if they can't, that method should be
disclosed to allow others to continue their work.

On Fri, 7 Aug 2015 21:55:21 +0200
Maxime Villard  wrote:

> Well, I guess I'll have to admit that I find your attitude extremely
> disrespectful. But I don't tend to feel particularly offended by this
> kind of things, so it probably does not matter.
> 
> 
> Le 21/07/2015 12:31, sam a écrit :
> > On Tue, 21 Jul 2015 11:31:44 +0200
> > Maxime Villard  wrote:
> >
> >> Found by The Brainy Code Scanner.
> >>
> >> It is not the last bug Brainy has found, but it is the last one I
> >> report. I don't have time for that.
> >>
> >
> > How about you release the Brainy Code Scanner then?
> >
> > "I have so many bugs; in fact, there are so many, I don't even have
> > the time to report them! My scanner is so good!"
> >
> > Or perhaps you should report 'just' the relatively important ones?
> >
> 
> I think my work does (or used to) benefit to a lot of users,
> developers and vendors here; a lot of people, including you.
> 
> Nobody supports my work, and I've never asked for anything here about
> that. Even though I almost never receive a simple "thank you" for all
> the bugs and vulnerabilities I've so far reported, I still expect a
> "spiritual thank you" for my work.
> 
> But I certainly do not expect that kind of emails you just sent,
> somehow trying to either make fun of me or disregard what I'm willing
> to spend my spare time on for you.
> 
> Developing, improving and maintaining Brainy takes time and energy, as
> well as investigating and packaging the bugs and vulnerabilities it
> finds. I've so far sent some reports here just because I'm "friendly"
> enough, and because modifying a few things for Brainy to properly
> understand the OpenBSD code does not require a Herculean work.
> 
> Now, I believe that this effort is too much for my spare time. If you
> want to say "thanks" to me for reporting this vulnerability, dear Sam,
> it's never too late.
> 
> Maxime
> 

Re: LibreSSL 2.2.2 release

[Mark Kettenis]

Jan Engelhardt schreef op 2015-08-10 10:29:

On Monday 2015-08-10 02:38, Brent Cook wrote:

On Aug 9, 2015, at 10:07 AM, Jan Engelhardt  wrote:


We have released LibreSSL 2.2.2, which will be arriving in the
LibreSSL directory of your local OpenBSD mirror soon.


The .pc files in libressl-2.2.2 upset the package mechanisms at hand, 
in

particular rpm, where ':' is used to denote the (ancient concept of)
epochs.

[   99s] Invalid version (double separator ':'): 35:0:0:
mingw32(pkg:libcrypto) = 35:0:0
[   99s] mingw32(pkg:libssl) = 35:0:0
[   99s] mingw32(pkg:libtls) = 6:0:0
[   99s] mingw32(pkg:openssl) = 2.2.2

The version: field in .pc files is (still) supposed to be the
package version number, not the ABI number, and this was not a 
problem

in libressl <= 2.2.1.


Thanks for the note, Jan.

Right or wrong, I'm fairly certain the format has not changed any time
recently, e.g. here is the libtls .pc file from 2.2.1:


So it turns out rpm does not consider it an error, just a warning (but 
it

is the first time the warning showed up on the last screenful, the one
paid most attention to).

I'm not so sure that this should be the package version number though. 
Can you

point to some further documentation here?


pkg-config(1): "Version:
This   should  be  the  most-specific-possible  package  version
string."

* x:0:0 is not specific enough, as it would not change when the ABI-API
  stays unmodified between two releases.

* the observation that all other .pc files I happen to have installed
  on my machine right now (some 194) all match \d+(\.\d+)*


Right.  Brent, looks like you used the libtool version specification 
here, which is (primarily) about encoding the ABI.  But for pkg-config 
it's
the API that's important.  Hence the tradition to simply use the package 
version number here, since that will change (by definition) when the API 
changes, but will also change when there are just some bug fixes (which 
people might want to check for).  Configure scripts will often contain 
checks
for the package version number to be larger or equal (using pkg-config 
--atleast-version) to some version that is known to have all features 
required for building the software.


So I think all the .pc files in LibreSSL should simply use the LibreSSL 
version number (2.2.2) like the openssl.pc does.  This does mean that 
checking
for individual libraries in LibreSSL version 2.2.2 and older will 
probably busted, but such is life.  Not sure how the colon-separated 
version strings

interact with --atleast-version.  Might be worth checking that out.

Cheers,

Mark

P.S. OpenBSD still ships with .pc files that have 1.0.0 as the version 
number.  We might want to change that at some point, but this should be 
coordinated with the ports people.

Re: LibreSSL 2.2.2 release

[Jan Engelhardt]

On Monday 2015-08-10 02:38, Brent Cook wrote:
>> On Aug 9, 2015, at 10:07 AM, Jan Engelhardt  wrote:
>> 
>>> We have released LibreSSL 2.2.2, which will be arriving in the
>>> LibreSSL directory of your local OpenBSD mirror soon.
>> 
>> The .pc files in libressl-2.2.2 upset the package mechanisms at hand, in 
>> particular rpm, where ':' is used to denote the (ancient concept of) 
>> epochs.
>> 
>> [   99s] Invalid version (double separator ':'): 35:0:0: 
>> mingw32(pkg:libcrypto) = 35:0:0
>> [   99s] mingw32(pkg:libssl) = 35:0:0
>> [   99s] mingw32(pkg:libtls) = 6:0:0
>> [   99s] mingw32(pkg:openssl) = 2.2.2
>> 
>> The version: field in .pc files is (still) supposed to be the
>> package version number, not the ABI number, and this was not a problem 
>> in libressl <= 2.2.1.
>
>Thanks for the note, Jan.
>
>Right or wrong, I'm fairly certain the format has not changed any time
>recently, e.g. here is the libtls .pc file from 2.2.1:

So it turns out rpm does not consider it an error, just a warning (but it
is the first time the warning showed up on the last screenful, the one
paid most attention to).

>I'm not so sure that this should be the package version number though. Can you
>point to some further documentation here?

pkg-config(1): "Version:
This   should  be  the  most-specific-possible  package  version
string."

* x:0:0 is not specific enough, as it would not change when the ABI-API
  stays unmodified between two releases.

* the observation that all other .pc files I happen to have installed
  on my machine right now (some 194) all match \d+(\.\d+)*