Re: pthread question

[Jonas 'Sortie' Termansen]

On 10/07/2015 12:53 PM, Stuart Henderson wrote:
>   if (pthread_kill(stat_thread, 0)) {
pthread_kill sends the specified signal to the thread, but signal 0 just
checks whether a signal can be sent and sends no signal.

fix snmpd reporting of IP-MIB::ipForwarding.0

[Stuart Henderson]

IP-MIB::ipForwarding.0 should return one of these values:

ipForwarding OBJECT-TYPE
SYNTAX INTEGER {
forwarding(1),-- acting as a router
notForwarding(2)  -- NOT acting as a router
   }

Currently we directly return the value of sysctl net.inet.ip.forwarding
which is incorrect.

OK to fix it like this?

Index: mib.c
===
RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
retrieving revision 1.76
diff -u -p -r1.76 mib.c
--- mib.c   10 Jun 2015 10:03:59 -  1.76
+++ mib.c   7 Oct 2015 21:34:27 -
@@ -2984,7 +2984,7 @@ mib_ipforwarding(struct oid *oid, struct
if (sysctl(mib, sizeofa(mib), , , NULL, 0) == -1)
return (-1);
 
-   *elm = ber_add_integer(*elm, v);
+   *elm = ber_add_integer(*elm, v ? 1 : 2);
 
return (0);
 }

Re: Bulkget & snmpd

[Stuart Henderson]

Moving post from misc@.

On 2015-10-07, Denis Fondras  wrote:
> Hello,
>
> I'm using snmpd from base on 5.8 and while playing with snmpbulkget (from
> net-snmp), I noticed a weirdness.
>
> * 'snmpbulkget -v2c -c public 10.100.200.19 iso.3.6.1.2.1.1' is ok
> * 'snmpbulkget -v2c -c public 10.100.200.19 iso.3.6.1.2.1.31.1.1' is ok
>
> By "ok", I mean it returns the correct MIB results. However,
>
> * 'snmpbulkget -v2c -c public 10.100.200.19 iso.3.6.1.2.1.31.1.1
>  iso.3.6.1.2.1.1' is not ok :
> -8<-
>  iso.3.6.1.2.1.31.1.1.1.1.1 = STRING: "em0"
>  iso.3.6.1.2.1.1.1.0 = STRING: "OpenBSD test.my.domain 5.8 GENERIC#3 i386"
>  iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.30155.23.1
>  iso.3.6.1.2.1.1.3.0 = Timeticks: (217) 0:00:02.17
>  iso.3.6.1.2.1.1.4.0 = STRING: "r...@test.my.domain"
>  iso.3.6.1.2.1.1.5.0 = STRING: "test.my.domain"
>  iso.3.6.1.2.1.1.6.0 = ""
>  iso.3.6.1.2.1.1.7.0 = INTEGER: 74
>  iso.3.6.1.2.1.1.8.0 = Timeticks: (0) 0:00:00.00
>  iso.3.6.1.2.1.1.9.1.1.1 = INTEGER: 1
>  iso.3.6.1.2.1.1.9.1.1.2 = INTEGER: 2
> -8<-
>
> As you can see, only the first sub-OID of iso.3.6.1.2.1.31.1.1 is returned.

To make it clear, that last command is meant to return 10x results starting
from iso.3.6.1.2.1.1 and 10x results starting from iso.3.6.1.2.1.31.1.1.

There are two parameters involved in GetBulkReq, "non-repeaters"
(snmpbulkget -Cn# which defaults to 0) and "max-repetitions"
(-Cr# defaulting to 10).

The response should be single results for the first "non-repeaters"
requests (allowing you to fetch e.g. the uptime and maybe some other
individual values of interest without a bunch of unwanted extras),
followed by "maxrep" number of values for any subsequent requests.

$ snmpbulkget -Cn2 -Cr4 -v2c -c public 127.0.0.1 SNMPv2-MIB::sysDescr 
IP-MIB::ipForwarding IF-MIB::ifName IF-MIB::ifInOctets
SNMPv2-MIB::sysDescr.0 = STRING: some host description
IP-MIB::ipForwarding.0 = INTEGER: notForwarding(2)
IF-MIB::ifName.1 = STRING: em0
IF-MIB::ifName.2 = STRING: em1
IF-MIB::ifName.3 = STRING: enc0
IF-MIB::ifName.4 = STRING: lo0
IF-MIB::ifInOctets.1 = Counter32: 4019922211
IF-MIB::ifInOctets.2 = Counter32: 0
IF-MIB::ifInOctets.3 = Counter32: 0
IF-MIB::ifInOctets.4 = Counter32: 1433448428

(the answers don't have to be in the same order as the query, I have
just formatted them that way for the example to make it clearer).

> It seems that the loop surrounding mps_getbulkreq() in snmpe.c is breaking
> the return of multiple OIDs but I can't find where exactly lies the bug.
>
> Can anyone help ?

One bug is that there's no support for non-repeaters yet;
msg->sm_nonrepeaters is filled in correctly from the request but
it isn't handled at all.

The getBulk request is processed within the outer loop in
snmpe_parsevarbinds(). There is one run of the inner loop for each
requested variable in the request which calls mps_getbulkreq() each
time.

I think something like the diff below (*NOT FOR COMMIT*) might be
part of the answer, there are problems though:

- "tooBig" error return when nonreps is set to anything other
than 0 (I can't even figure out where this is sent from..)

- still doesn't fix your problem where repetitions are broken
for all but the last requested variable. I've been looking at it and
trying things but haven't figured it out yet.

- not new, but the len counting in mps_getbulkreq only relates to
the individual call of that function, but in reality the response is
being built up from multiple calls to that function. so I think len
needs to be passed in as a pointer so that it can totalled up and
stop adding vars when the whole response packet is too full.

Anyway perhaps this gives some more ideas..

Index: snmpe.c
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
retrieving revision 1.40
diff -u -p -r1.40 snmpe.c
--- snmpe.c 16 Jan 2015 00:05:13 -  1.40
+++ snmpe.c 7 Oct 2015 22:28:05 -
@@ -335,7 +335,7 @@ snmpe_parsevarbinds(struct snmp_message 
struct snmp_stats   *stats = >sc_stats;
char buf[BUFSIZ];
struct ber_oid   o;
-   int  ret = 0;
+   int  bulk_oid = 0, ret = 0, nreps;
 
msg->sm_errstr = "invalid varbind element";
 
@@ -408,8 +408,12 @@ snmpe_parsevarbinds(struct snmp_message 
goto varfail;
 
case SNMP_C_GETBULKREQ:
+   nreps = bulk_oid <
+   msg->sm_nonrepeaters ?
+   1 : msg->sm_maxrepetitions;
+   bulk_oid++;
ret = mps_getbulkreq(msg, >sm_c,
-   , msg->sm_maxrepetitions);
+   , nreps);
if 

Re: Bulkget & snmpd

[Stuart Henderson]

On 2015/10/07 23:41, Stuart Henderson wrote:
> Moving post from misc@.
> 
> On 2015-10-07, Denis Fondras  wrote:
> > Hello,
> >
> > I'm using snmpd from base on 5.8 and while playing with snmpbulkget (from
> > net-snmp), I noticed a weirdness.
> >
> > * 'snmpbulkget -v2c -c public 10.100.200.19 iso.3.6.1.2.1.1' is ok
> > * 'snmpbulkget -v2c -c public 10.100.200.19 iso.3.6.1.2.1.31.1.1' is ok
> >
> > By "ok", I mean it returns the correct MIB results. However,
> >
> > * 'snmpbulkget -v2c -c public 10.100.200.19 iso.3.6.1.2.1.31.1.1
> >  iso.3.6.1.2.1.1' is not ok :
> > -8<-
> >  iso.3.6.1.2.1.31.1.1.1.1.1 = STRING: "em0"
> >  iso.3.6.1.2.1.1.1.0 = STRING: "OpenBSD test.my.domain 5.8 GENERIC#3 i386"
> >  iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.30155.23.1
> >  iso.3.6.1.2.1.1.3.0 = Timeticks: (217) 0:00:02.17
> >  iso.3.6.1.2.1.1.4.0 = STRING: "r...@test.my.domain"
> >  iso.3.6.1.2.1.1.5.0 = STRING: "test.my.domain"
> >  iso.3.6.1.2.1.1.6.0 = ""
> >  iso.3.6.1.2.1.1.7.0 = INTEGER: 74
> >  iso.3.6.1.2.1.1.8.0 = Timeticks: (0) 0:00:00.00
> >  iso.3.6.1.2.1.1.9.1.1.1 = INTEGER: 1
> >  iso.3.6.1.2.1.1.9.1.1.2 = INTEGER: 2
> > -8<-
> >
> > As you can see, only the first sub-OID of iso.3.6.1.2.1.31.1.1 is returned.
> 
> To make it clear, that last command is meant to return 10x results starting
> from iso.3.6.1.2.1.1 and 10x results starting from iso.3.6.1.2.1.31.1.1.
> 
> There are two parameters involved in GetBulkReq, "non-repeaters"
> (snmpbulkget -Cn# which defaults to 0) and "max-repetitions"
> (-Cr# defaulting to 10).
> 
> The response should be single results for the first "non-repeaters"
> requests (allowing you to fetch e.g. the uptime and maybe some other
> individual values of interest without a bunch of unwanted extras),
> followed by "maxrep" number of values for any subsequent requests.
> 
> $ snmpbulkget -Cn2 -Cr4 -v2c -c public 127.0.0.1 SNMPv2-MIB::sysDescr 
> IP-MIB::ipForwarding IF-MIB::ifName IF-MIB::ifInOctets
> SNMPv2-MIB::sysDescr.0 = STRING: some host description
> IP-MIB::ipForwarding.0 = INTEGER: notForwarding(2)
> IF-MIB::ifName.1 = STRING: em0
> IF-MIB::ifName.2 = STRING: em1
> IF-MIB::ifName.3 = STRING: enc0
> IF-MIB::ifName.4 = STRING: lo0
> IF-MIB::ifInOctets.1 = Counter32: 4019922211
> IF-MIB::ifInOctets.2 = Counter32: 0
> IF-MIB::ifInOctets.3 = Counter32: 0
> IF-MIB::ifInOctets.4 = Counter32: 1433448428
> 
> (the answers don't have to be in the same order as the query, I have
> just formatted them that way for the example to make it clearer).

O. And now I find Gerhard Roth's post

https://marc.info/?l=openbsd-tech=143375327425321=2

In a nutshell: the mps_getbulkreq() calls subsequent to the first one
link the elements to the *first* element of the previous call, not the
last element. Gerhard's diff passes in the address of the last element
so it can be linked correctly.

I'll look at it again tomorrow but that looks correct for the -Cr case,
nonreps and I think also len counting are still a problem but I'll look
at those again on top of Gerhard's diff.

Re: fix snmpd reporting of IP-MIB::ipForwarding.0

[Masao Uebayashi]

Thanks for spotting this.  Looks correct, but if I were to fix this:

(v == 0) ? 2 : 1

Either case, OK uebayasi@

On Wed, Oct 07, 2015 at 10:39:17PM +0100, Stuart Henderson wrote:
> IP-MIB::ipForwarding.0 should return one of these values:
> 
> ipForwarding OBJECT-TYPE
> SYNTAX INTEGER {
> forwarding(1),-- acting as a router
> notForwarding(2)  -- NOT acting as a router
>}
> 
> Currently we directly return the value of sysctl net.inet.ip.forwarding
> which is incorrect.
> 
> OK to fix it like this?
> 
> Index: mib.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/mib.c,v
> retrieving revision 1.76
> diff -u -p -r1.76 mib.c
> --- mib.c 10 Jun 2015 10:03:59 -  1.76
> +++ mib.c 7 Oct 2015 21:34:27 -
> @@ -2984,7 +2984,7 @@ mib_ipforwarding(struct oid *oid, struct
>   if (sysctl(mib, sizeofa(mib), , , NULL, 0) == -1)
>   return (-1);
>  
> - *elm = ber_add_integer(*elm, v);
> + *elm = ber_add_integer(*elm, v ? 1 : 2);
>  
>   return (0);
>  }
> 

Re: pthread question

[Mark Kettenis]

> X-Virus-Scanned: by XS4ALL Virus Scanner
> Date: Wed, 7 Oct 2015 12:47:35 +0100
> From: Stuart Henderson 
> 
> Thanks. And I suppose in the case of a more complex program it couldn't
> be guaranteed that the thread ID hasn't been reused by another thread
> elsewhere in the program after the first one has exited.
> 
> So I think a better approach for the check_disk program would be to
> pass in a pointer to a struct that includes a marker that the child
> thread can set when it's finished, and check that from the main
> thread, does that make sense?

Yes, properly protected by a mutex and perhaps using a condition
variable.

Cheers,

Mark

Re: pthread question

[Stuart Henderson]

On 2015/10/07 11:52, Stuart Henderson wrote:
> monitoring-plugins has a program that checks available space on partitions.
> Before doing this it does a stat() to check that the requested directory
> exists and is accessible. In their devel tree they have moved to doing
> this stat() in a thread - commit log was "don't let check_disk hang on
> hanging file systems". However this code doesn't work for us.
> 
> I've attached a stripped-down test program based on their code that works
> as expected on Linux but fails on OpenBSD. I can always patch to use the
> non-pthread code, but I wondered if anyone has an idea what's up and
> whether the bug is theirs or ours - is pthread_kill(thread, 0) working
> as expected?
> 
> $ make thread LDFLAGS=-lpthread
> cc -O2 -pipe   -lpthread -o thread thread.c
> 
> $ ./thread
> 4
> child
> 3
> 2
> 1
> 0
> child thread did not return within 5s

oops, I added some extra bits while I was playing around, the test
program was meant to be this simpler version.
#include 
#include 
#include 
#include 
#include 

void do_something();
void *child(void *);

int
main(int argc, char **argv)
{
do_something();
}

void do_something()
{
pthread_t stat_thread;
int done = 0;
int timer = 5;
struct timespec req, rem;

req.tv_sec = 0;
pthread_create(_thread, NULL, child, NULL);
while (timer-- > 0) {
printf("%u\n", timer);
req.tv_nsec = 1000;
nanosleep(, );
if (pthread_kill(stat_thread, 0)) {
done = 1;
break;
} else {
printf("e %u\n", errno);
req.tv_nsec = 99000;
nanosleep(, );
}
}
if (done == 1) {
pthread_join(stat_thread, NULL);
} else {
pthread_detach(stat_thread);
printf("child thread did not return within 5s\n");
}
}

void *child(void *in)
{
printf("child\n");
}

pthread question

[Stuart Henderson]

monitoring-plugins has a program that checks available space on partitions.
Before doing this it does a stat() to check that the requested directory
exists and is accessible. In their devel tree they have moved to doing
this stat() in a thread - commit log was "don't let check_disk hang on
hanging file systems". However this code doesn't work for us.

I've attached a stripped-down test program based on their code that works
as expected on Linux but fails on OpenBSD. I can always patch to use the
non-pthread code, but I wondered if anyone has an idea what's up and
whether the bug is theirs or ours - is pthread_kill(thread, 0) working
as expected?

$ make thread LDFLAGS=-lpthread
cc -O2 -pipe   -lpthread -o thread thread.c

$ ./thread
4
child
3
2
1
0
child thread did not return within 5s

#include 
#include 
#include 
#include 
#include 

void do_something();
void *child(void *);

int
main(int argc, char **argv)
{
do_something();
}

void do_something()
{
pthread_t stat_thread;
int done = 0;
int timer = 5;
struct timespec req, rem;

req.tv_sec = 0;
pthread_create(_thread, NULL, child, NULL);
while (timer-- > 0) {
printf("%u\n", timer);
req.tv_nsec = 1000;
nanosleep(, );
if (pthread_kill(stat_thread, 0)) {
done = 1;
break;
} else {
printf("e %u\n", errno);
req.tv_nsec = 99000;
nanosleep(, );
}
}
if (done == 1) {
pthread_join(stat_thread, NULL);
} else {
pthread_detach(stat_thread);
printf("child thread did not return within 5s\n");
}
}

void *child(void *in)
{
struct timespec xeq, xem;
xeq.tv_nsec = 959000;
printf("child1\n");
nanosleep(, );
printf("child2\n");
}

[PATCH] usbdev for ASUS USB-AC56

[Renaud Allard]

Hello,

Here is a small patch to add the USB-AC56 from Asus to usbdevs

ID 0b05:17d2 ASUSTek Computer, Inc.
dmesg gives a somewhat misleading name:
ugen0 at uhub2 port 6 "Realtek 802.11n NIC" rev 2.00/0.00 addr 5

I know that chipset is not supported yet, so do what you think is best.

Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.659
diff -u -p -r1.659 usbdevs
--- usbdevs 29 Sep 2015 09:01:00 -  1.659
+++ usbdevs 7 Oct 2015 11:21:22 -
@@ -1042,6 +1042,7 @@ product ASUS USBN66   0x17ad  USB-N66
 product ASUS RTL8192CU_2   0x17ba  RTL8192CU
 product ASUS RTL8192CU_3   0x17c0  RTL8192CU
 product ASUS MYPAL_A7300x4202  MyPal A730
+product ASUS RTL8212AU 0x17d2  USB-AC56

 /* ASUSTeK Computer products */
 product ASUSTEK WL140  0x3300  WL-140


Regards



smime.p7s
Description: S/MIME Cryptographic Signature

Re: pthread question

[Stuart Henderson]

Thanks. And I suppose in the case of a more complex program it couldn't
be guaranteed that the thread ID hasn't been reused by another thread
elsewhere in the program after the first one has exited.

So I think a better approach for the check_disk program would be to
pass in a pointer to a struct that includes a marker that the child
thread can set when it's finished, and check that from the main
thread, does that make sense?

Re: pthread question

[Mark Kettenis]

> Date: Wed, 7 Oct 2015 11:53:32 +0100
> From: Stuart Henderson 
> 
> On 2015/10/07 11:52, Stuart Henderson wrote:
> > monitoring-plugins has a program that checks available space on partitions.
> > Before doing this it does a stat() to check that the requested directory
> > exists and is accessible. In their devel tree they have moved to doing
> > this stat() in a thread - commit log was "don't let check_disk hang on
> > hanging file systems". However this code doesn't work for us.
> > 
> > I've attached a stripped-down test program based on their code that works
> > as expected on Linux but fails on OpenBSD. I can always patch to use the
> > non-pthread code, but I wondered if anyone has an idea what's up and
> > whether the bug is theirs or ours - is pthread_kill(thread, 0) working
> > as expected?
> > 
> > $ make thread LDFLAGS=-lpthread
> > cc -O2 -pipe   -lpthread -o thread thread.c
> > 
> > $ ./thread
> > 4
> > child
> > 3
> > 2
> > 1
> > 0
> > child thread did not return within 5s

My reading of the POSIX standard is that our implementation of
pthread_kill(3) is correct and that the program's expectations are
wrong.

POSIX says that in the "General Information" section on threads:

  The lifetime of a thread ID ends after the thread terminates if it
  was created with the detachstate attribute set to
  PTHREAD_CREATE_DETACHED or if pthread_detach() or pthread_join() has
  been called for that thread.

At the point where the program calls pthread_kill(), pthread_join()
has not been called yet.  So the thread ID is still "alive".

The pthread_exit() page says:

  As in kill(), if sig is zero, error checking shall be performed but
  no signal shall actually be sent.

The only "shall fail" is EINVAL for passing a bogus signal number.
The "informative" RATIONALE section mentions an additional error
condition:

  If an implementation detects use of a thread ID after the end of its
  lifetime, it is recommended that the function should fail and report
  an [ESRCH] error.

But since the thread ID is still "alive", that doesn't apply.

Also note that POSIX explicitly mentions kill() here.  And for kill()
POSIX says (again in the RATIONALE section):

  Existing implementations vary on the result of a kill() with pid
  indicating an inactive process (a terminated process that has not
  been waited for by its parent). Some indicate success on such a call
  (subject to permission checking), while others give an error of
  [ESRCH]. Since the definition of process lifetime in this volume of
  POSIX.1-2008 covers inactive processes, the [ESRCH] error as
  described is inappropriate in this case. In particular, this means
  that an application cannot have a parent process check for
  termination of a particular child with kill(). (Usually this is done
  with the null signal; this can be done reliably with waitpid().)

Which strongly suggests that using pthread_kill(..., 0) on a
non-detached, unjoined thread should not return ESRCH.

> #include 
> #include 
> #include 
> #include 
> #include 
> 
> void do_something();
> void *child(void *);
> 
> int
> main(int argc, char **argv)
> {
>   do_something();
> }
> 
> void do_something()
> {
>   pthread_t stat_thread;
>   int done = 0;
>   int timer = 5;
>   struct timespec req, rem;
> 
>   req.tv_sec = 0;
>   pthread_create(_thread, NULL, child, NULL);
>   while (timer-- > 0) {
>   printf("%u\n", timer);
>   req.tv_nsec = 1000;
>   nanosleep(, );
>   if (pthread_kill(stat_thread, 0)) {
>   done = 1;
>   break;
>   } else {
>   printf("e %u\n", errno);
>   req.tv_nsec = 99000;
>   nanosleep(, );
>   }
>   }
>   if (done == 1) {
>   pthread_join(stat_thread, NULL);
>   } else {
>   pthread_detach(stat_thread);
>   printf("child thread did not return within 5s\n");
>   }
> }
> 
> void *child(void *in)
> {
>   printf("child\n");
> }

Re: FreeType-2.6.1 !!header files layout changed again!!

[David Coppa]

On Wed, Oct 7, 2015 at 2:12 PM, David Coppa  wrote:
>
> Hi!
>
> New freetype version, new header file layout :( :(
>
> Now, all header files except 'ft2build.h' are (again) into
> /usr/X11R6/include/freetype2/freetype/.
>
> Luckily, no ABI changes this time.
>
> So, to apply the patches:
>
>
> $ cd /usr/src/
> $ patch -NE -i /path/to/mtree.diff
>
> -> as root <-
> # cat /usr/src/etc/mtree/BSD.x11.dist > /etc/mtree/BSD.x11.dist
> # rm -rf /usr/X11R6/include/freetype2
>
> $ cd /usr/xenocara/
> $ make bootstrap
> $ cd /usr/xenocara/lib/freetype
> $ mkdir -p include/freetype/config
> $ mkdir -p include/freetype/internal/services
> $ patch -NEp0 -i /path/to/freetype-2.6.1.diff
> $ make depend
> $ make clean ; make
>
> -> as root <-
> # cd /usr/xenocara/lib/freetype ; make install
>
>
>
> Obviously, I'm expecting some fallouts from a bulk build with this...
>
> Cheers,
> David

This update is also security related, addressing some CVEs:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9745

http://seclists.org/bugtraq/2015/Oct/41

http://www.openwall.com/lists/oss-security/2015/09/11/4

Ciao!
David

Re: FreeType-2.6.1 !!header files layout changed again!!

[Stuart Henderson]

On 2015/10/07 14:40, David Coppa wrote:
> On Wed, Oct 7, 2015 at 2:12 PM, David Coppa  wrote:
> >
> > Hi!
> >
> > New freetype version, new header file layout :( :(
> >
> > Now, all header files except 'ft2build.h' are (again) into
> > /usr/X11R6/include/freetype2/freetype/.
> >
> > Luckily, no ABI changes this time.
> >
> > So, to apply the patches:
> >
> >
> > $ cd /usr/src/
> > $ patch -NE -i /path/to/mtree.diff
> >
> > -> as root <-
> > # cat /usr/src/etc/mtree/BSD.x11.dist > /etc/mtree/BSD.x11.dist
> > # rm -rf /usr/X11R6/include/freetype2
> >
> > $ cd /usr/xenocara/
> > $ make bootstrap
> > $ cd /usr/xenocara/lib/freetype
> > $ mkdir -p include/freetype/config
> > $ mkdir -p include/freetype/internal/services
> > $ patch -NEp0 -i /path/to/freetype-2.6.1.diff
> > $ make depend
> > $ make clean ; make
> >
> > -> as root <-
> > # cd /usr/xenocara/lib/freetype ; make install
> >
> >
> >
> > Obviously, I'm expecting some fallouts from a bulk build with this...
> >
> > Cheers,
> > David
> 
> This update is also security related, addressing some CVEs:
> 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9745
> 
> http://seclists.org/bugtraq/2015/Oct/41
> 
> http://www.openwall.com/lists/oss-security/2015/09/11/4
> 
> Ciao!
> David

*grmbl* somebody slap them, please

Maybe backport the security fixes first? It'll need doing anyway if they
are to go into -stable..

Re: unbreak trunk(4)

[Mike Belopuhov]

On Wed, Oct 07, 2015 at 15:41 +0200, Mike Belopuhov wrote:
> Hi,
> 
> If you have noticed recent problems with trunk(4) please try the
> diff below as it fixes a subtle issue (not introduced by my changes!)
> with setting lladdr on non primary trunk ports: trunk_port_ioctl
> needs to be able to lookup the trunk port, but we didn't put it on
> the list yet, doh!
> 
> OK's are welcome as well.
> 

boo hoo, it clashes with some uncommitted changes, here's a rebased version.


diff --git sys/net/if_trunk.c sys/net/if_trunk.c
index 8678fe4..2aaa339 100644
--- sys/net/if_trunk.c
+++ sys/net/if_trunk.c
@@ -358,18 +358,18 @@ trunk_port_create(struct trunk_softc *tr, struct ifnet 
*ifp)
tr->tr_primary = tp;
tp->tp_flags |= TRUNK_PORT_MASTER;
trunk_lladdr(>tr_ac, tp->tp_lladdr);
}
 
-   /* Update link layer address for this port */
-   trunk_port_lladdr(tp,
-   ((struct arpcom *)(tr->tr_primary->tp_if))->ac_enaddr);
-
/* Insert into the list of ports */
SLIST_INSERT_HEAD(>tr_ports, tp, tp_entries);
tr->tr_count++;
 
+   /* Update link layer address for this port */
+   trunk_port_lladdr(tp,
+   ((struct arpcom *)(tr->tr_primary->tp_if))->ac_enaddr);
+
/* Update trunk capabilities */
tr->tr_capabilities = trunk_capabilities(tr);
 
/* Add multicast addresses to this port */
trunk_ether_cmdmulti(tp, SIOCADDMULTI);

unbreak trunk(4)

[Mike Belopuhov]

Hi,

If you have noticed recent problems with trunk(4) please try the
diff below as it fixes a subtle issue (not introduced by my changes!)
with setting lladdr on non primary trunk ports: trunk_port_ioctl
needs to be able to lookup the trunk port, but we didn't put it on
the list yet, doh!

OK's are welcome as well.

diff --git sys/net/if_trunk.c sys/net/if_trunk.c
index a97741a..9a3dbb5 100644
--- sys/net/if_trunk.c
+++ sys/net/if_trunk.c
@@ -356,18 +356,18 @@ trunk_port_create(struct trunk_softc *tr, struct ifnet 
*ifp)
tr->tr_primary = tp;
tp->tp_flags |= TRUNK_PORT_MASTER;
trunk_lladdr((struct ifnet *)>tr_ac, tp->tp_lladdr);
}
 
-   /* Update link layer address for this port */
-   trunk_port_lladdr(tp,
-   ((struct arpcom *)(tr->tr_primary->tp_if))->ac_enaddr);
-
/* Insert into the list of ports */
SLIST_INSERT_HEAD(>tr_ports, tp, tp_entries);
tr->tr_count++;
 
+   /* Update link layer address for this port */
+   trunk_port_lladdr(tp,
+   ((struct arpcom *)(tr->tr_primary->tp_if))->ac_enaddr);
+
/* Update trunk capabilities */
tr->tr_capabilities = trunk_capabilities(tr);
 
/* Add multicast addresses to this port */
trunk_ether_cmdmulti(tp, SIOCADDMULTI);

Re: FreeType-2.6.1 !!header files layout changed again!!

[David Coppa]

On Wed, Oct 7, 2015 at 3:01 PM, Stuart Henderson  wrote:
> On 2015/10/07 14:40, David Coppa wrote:
>> On Wed, Oct 7, 2015 at 2:12 PM, David Coppa  wrote:
>> >
>> > Hi!
>> >
>> > New freetype version, new header file layout :( :(
>> >
>> > Now, all header files except 'ft2build.h' are (again) into
>> > /usr/X11R6/include/freetype2/freetype/.
>> >
>> > Luckily, no ABI changes this time.
>> >
>> > So, to apply the patches:
>> >
>> >
>> > $ cd /usr/src/
>> > $ patch -NE -i /path/to/mtree.diff
>> >
>> > -> as root <-
>> > # cat /usr/src/etc/mtree/BSD.x11.dist > /etc/mtree/BSD.x11.dist
>> > # rm -rf /usr/X11R6/include/freetype2
>> >
>> > $ cd /usr/xenocara/
>> > $ make bootstrap
>> > $ cd /usr/xenocara/lib/freetype
>> > $ mkdir -p include/freetype/config
>> > $ mkdir -p include/freetype/internal/services
>> > $ patch -NEp0 -i /path/to/freetype-2.6.1.diff
>> > $ make depend
>> > $ make clean ; make
>> >
>> > -> as root <-
>> > # cd /usr/xenocara/lib/freetype ; make install
>> >
>> >
>> >
>> > Obviously, I'm expecting some fallouts from a bulk build with this...
>> >
>> > Cheers,
>> > David
>>
>> This update is also security related, addressing some CVEs:
>>
>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9745
>>
>> http://seclists.org/bugtraq/2015/Oct/41
>>
>> http://www.openwall.com/lists/oss-security/2015/09/11/4
>>
>> Ciao!
>> David
>
> *grmbl* somebody slap them, please
>
> Maybe backport the security fixes first? It'll need doing anyway if they
> are to go into -stable..

Ehm... Nevermind, these security bugs were already fixed in freetype-2.6.0.

Sorry for the noise!

Btw, this is the changelog for freetype-2.6.1:

http://sourceforge.net/projects/freetype/files/freetype2/2.6.1/

The request for a bulk build with freetype-2.6.1 is still valid :)

ciao
David

Re: dedup in_pcbbind() port scan loop

[Martin Pieuchot]

On 01/10/15(Thu) 19:40, Vincent Gross wrote:
> Although the sysctls controlling the port range are labelled "port(hi)?first" 
> and
> "port(hi)?last", no ordering is enforced and you can have portfirst > 
> portlast.
> in_pcbbind() (and in6_pcbsetport()) work around this by duplicating the loop 
> looking
> for an available port.

What about a small regress test?

> This diff introduce temporary bounds and compare them to guarantee that
> first <= last, thus allowing deduplication of the port scan loop.

Makes sense to me, I'd keep the comment though.

> 
> Tested on my laptop with a narrow port range and heavy cheezburger browsing, 
> no fault
> detected. Deeper testing welcome.
> 
> Should I include in6_pcbsetport() changes right now or should ipv4 be 
> validated first ?

I prefer when both version are keep in sync, so yes a in6_pcbsetport()
diff would be nice.  Plus if it's possible to have a regress test it
would be awesome.

Re: FreeType-2.6.1 !!header files layout changed again!!

[David Coppa]

On Wed, Oct 7, 2015 at 3:01 PM, Stuart Henderson  wrote:
> On 2015/10/07 14:40, David Coppa wrote:
>> On Wed, Oct 7, 2015 at 2:12 PM, David Coppa  wrote:
>> >
>> > Hi!
>> >
>> > New freetype version, new header file layout :( :(
>> >
>> > Now, all header files except 'ft2build.h' are (again) into
>> > /usr/X11R6/include/freetype2/freetype/.
>> >
>> > Luckily, no ABI changes this time.
>> >
>> > So, to apply the patches:
>> >
>> >
>> > $ cd /usr/src/
>> > $ patch -NE -i /path/to/mtree.diff
>> >
>> > -> as root <-
>> > # cat /usr/src/etc/mtree/BSD.x11.dist > /etc/mtree/BSD.x11.dist
>> > # rm -rf /usr/X11R6/include/freetype2
>> >
>> > $ cd /usr/xenocara/
>> > $ make bootstrap
>> > $ cd /usr/xenocara/lib/freetype
>> > $ mkdir -p include/freetype/config
>> > $ mkdir -p include/freetype/internal/services
>> > $ patch -NEp0 -i /path/to/freetype-2.6.1.diff
>> > $ make depend
>> > $ make clean ; make
>> >
>> > -> as root <-
>> > # cd /usr/xenocara/lib/freetype ; make install
>> >
>> >
>> >
>> > Obviously, I'm expecting some fallouts from a bulk build with this...
>> >
>> > Cheers,
>> > David
>>
>> This update is also security related, addressing some CVEs:
>>
>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9745
>>
>> http://seclists.org/bugtraq/2015/Oct/41
>>
>> http://www.openwall.com/lists/oss-security/2015/09/11/4
>>
>> Ciao!
>> David
>
> *grmbl* somebody slap them, please
>
> Maybe backport the security fixes first? It'll need doing anyway if they
> are to go into -stable..

I'm going to have a look in a minute...

mg(1) honour C-u 0

[Mark Lumsden]

Calling an mg command with zero iterations (C-u 0) seems non-sensical
but what should happen if you did? Currently some commands honour the
0 [ie. do nothing], others do not, they partially complete or complete
as if 1 had been passed. For example try and insert 0 characters via:

C-u 0 a

The function that inserts characters has an 'if' statement that
handles 0 being passed and returns before any characters are
inserted. Now try to move to the beginning of a line:

C-u 0 C-a

The case for zero iterations isn't handled and the cursor goes to the
beginning of the line. Now try tranposing 0 paragraphs:

C-u 0 M-x tranpose-paragraphs

The cursor moves to the end of the current paragraph and no
transposing is completed.

This diff makes functions that honour multiple* iterations but
currently do not honour zero iterations, honour 0 iterations.
Comments/oks? 

-lum

* Functions that do not honour multiple (or non-single) iterations are
not included, e.g: M-<. 
Also the tranpose-chars (C-t) function doesn't honour multiple
iterations, but probably should so it has been included in this diff. 

Index: basic.c
===
RCS file: /cvs/src/usr.bin/mg/basic.c,v
retrieving revision 1.46
diff -u -p -u -p -r1.46 basic.c
--- basic.c 26 Sep 2015 21:51:58 -  1.46
+++ basic.c 7 Oct 2015 14:19:24 -
@@ -28,6 +28,9 @@
 int
 gotobol(int f, int n)
 {
+   if (n == 0)
+   return (TRUE);
+
curwp->w_doto = 0;
return (TRUE);
 }
@@ -72,6 +75,9 @@ backchar(int f, int n)
 int
 gotoeol(int f, int n)
 {
+   if (n == 0)
+   return (TRUE);
+
curwp->w_doto = llength(curwp->w_dotp);
return (TRUE);
 }
Index: paragraph.c
===
RCS file: /cvs/src/usr.bin/mg/paragraph.c,v
retrieving revision 1.40
diff -u -p -u -p -r1.40 paragraph.c
--- paragraph.c 26 Sep 2015 15:03:15 -  1.40
+++ paragraph.c 7 Oct 2015 14:19:25 -
@@ -142,6 +142,9 @@ fillpara(int f, int n)
struct line *eopline;   /* pointer to line just past EOP
*/
char wbuf[MAXWORD]; /* buffer for current word  */
 
+   if (n == 0)
+   return (TRUE);
+
undo_boundary_enable(FFRAND, 0);
 
/* record the pointer to the line just past the EOP */
@@ -267,6 +270,9 @@ killpara(int f, int n)
 {
int lineno, status;
 
+   if (n == 0)
+   return (TRUE);
+
if (findpara() == FALSE)
return (TRUE);
 
@@ -298,6 +304,9 @@ markpara(int f, int n)
 {
int i = 0;
 
+   if (n == 0)
+   return (TRUE);
+
clearmark(FFARG, 0);
 
if (findpara() == FALSE)
@@ -325,6 +334,9 @@ transposepara(int f, int n)
 {
int i = 0, status;
charflg;
+
+   if (n == 0)
+   return (TRUE);
 
/* find a paragraph, set mark, then goto the end */
gotobop(FFRAND, 1);
Index: util.c
===
RCS file: /cvs/src/usr.bin/mg/util.c,v
retrieving revision 1.36
diff -u -p -u -p -r1.36 util.c
--- util.c  29 Sep 2015 03:19:24 -  1.36
+++ util.c  7 Oct 2015 14:19:25 -
@@ -117,6 +117,9 @@ twiddle(int f, int n)
struct line *dotp;
int  doto, cr;
 
+   if (n == 0)
+   return (TRUE);
+
dotp = curwp->w_dotp;
doto = curwp->w_doto;
 

Re: syslogd TLS accept

[Bob Beck]

sure. ok

On Tuesday, 6 October 2015, Alexander Bluhm  wrote:

> On Fri, Sep 25, 2015 at 11:27:49PM +0200, Alexander Bluhm wrote:
> > If syslogd is started with -S, it accepts TLS connections to receive
> > encrypted traffic.  The server certificates are taken from /etc/ssl
> > like relayd does.
>
> Anyone?
>
> bluhm
>
> Index: usr.sbin/syslogd/evbuffer_tls.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/evbuffer_tls.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 evbuffer_tls.c
> --- usr.sbin/syslogd/evbuffer_tls.c 20 Sep 2015 21:49:54 -  1.8
> +++ usr.sbin/syslogd/evbuffer_tls.c 6 Oct 2015 16:10:11 -
> @@ -260,6 +260,19 @@ buffertls_set(struct buffertls *buftls,
>  }
>
>  void
> +buffertls_accept(struct buffertls *buftls, int fd)
> +{
> +   struct bufferevent *bufev = buftls->bt_bufev;
> +
> +   event_del(>ev_read);
> +   event_del(>ev_write);
> +   event_set(>ev_read, fd, EV_READ, buffertls_handshakecb,
> buftls);
> +   event_set(>ev_write, fd, EV_WRITE, buffertls_handshakecb,
> +   buftls);
> +   bufferevent_add(>ev_read, bufev->timeout_read);
> +}
> +
> +void
>  buffertls_connect(struct buffertls *buftls, int fd)
>  {
> struct bufferevent *bufev = buftls->bt_bufev;
> Index: usr.sbin/syslogd/evbuffer_tls.h
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/evbuffer_tls.h,v
> retrieving revision 1.4
> diff -u -p -r1.4 evbuffer_tls.h
> --- usr.sbin/syslogd/evbuffer_tls.h 10 Sep 2015 18:32:06 -  1.4
> +++ usr.sbin/syslogd/evbuffer_tls.h 6 Oct 2015 16:10:11 -
> @@ -31,6 +31,7 @@ struct buffertls {
>
>  void   buffertls_set(struct buffertls *, struct bufferevent *, struct tls
> *,
>  int);
> +void   buffertls_accept(struct buffertls *, int);
>  void   buffertls_connect(struct buffertls *, int);
>
>  #endif /* _EVBUFFER_TLS_H_ */
> Index: usr.sbin/syslogd/privsep.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/privsep.c,v
> retrieving revision 1.54
> diff -u -p -r1.54 privsep.c
> --- usr.sbin/syslogd/privsep.c  7 Jul 2015 17:53:04 -   1.54
> +++ usr.sbin/syslogd/privsep.c  6 Oct 2015 16:10:11 -
> @@ -184,6 +184,8 @@ priv_init(char *conf, int numeric, int l
> close(fd_bind);
> if (fd_listen != -1)
> close(fd_listen);
> +   if (fd_tls != -1)
> +   close(fd_tls);
> for (i = 0; i < nunix; i++)
> if (fd_unix[i] != -1)
> close(fd_unix[i]);
> Index: usr.sbin/syslogd/syslogd.8
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.8,v
> retrieving revision 1.38
> diff -u -p -r1.38 syslogd.8
> --- usr.sbin/syslogd/syslogd.8  7 Jul 2015 21:43:35 -   1.38
> +++ usr.sbin/syslogd/syslogd.8  6 Oct 2015 16:10:11 -
> @@ -45,6 +45,7 @@
>  .Op Fl f Ar config_file
>  .Op Fl m Ar mark_interval
>  .Op Fl p Ar log_socket
> +.Op Fl S Ar listen_address
>  .Op Fl s Ar reporting_socket
>  .Op Fl T Ar listen_address
>  .Op Fl U Ar bind_address
> @@ -108,6 +109,25 @@ the symbolic local host name.
>  Specify the pathname of an alternate log socket to be used instead;
>  the default is
>  .Pa /dev/log .
> +.It Fl S Ar listen_address
> +Create a TLS listen socket for receiving encrypted messages and
> +bind it to the specified address.
> +A port number may be specified using the
> +.Ar host:port
> +syntax.
> +The syslog server will attempt to look up a private key in
> +.Pa /etc/ssl/private/host:port.key
> +and a public certificate in
> +.Pa /etc/ssl/host:port.crt ,
> +where
> +.Ar host
> +is the specified host name or IP address and
> +.Ar port
> +is the specified port if given on the command line.
> +If these files are not present, syslogd will continue to look in
> +.Pa /etc/ssl/private/host.key
> +and
> +.Pa /etc/ssl/host.crt .
>  .It Fl s Ar reporting_socket
>  Specify path to an
>  .Dv AF_LOCAL
> Index: usr.sbin/syslogd/syslogd.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
> retrieving revision 1.190
> diff -u -p -r1.190 syslogd.c
> --- usr.sbin/syslogd/syslogd.c  29 Sep 2015 03:19:23 -  1.190
> +++ usr.sbin/syslogd/syslogd.c  6 Oct 2015 16:10:11 -
> @@ -50,7 +50,7 @@
>   * extensive changes by Ralph Campbell
>   * more extensive changes by Eric Allman (again)
>   * memory buffer logging by Damien Miller
> - * IPv6, libevent, sending over TCP and TLS by Alexander Bluhm
> + * IPv6, libevent, syslog over TCP and TLS by Alexander Bluhm
>   */
>
>  #define MAXLINE8192/* maximum line length */
> @@ -219,9 +219,13 @@ char   *bind_host = NULL;  /* 

Re: pkg_(add|delete|info): fix synopses

[Jason McIntyre]

On Sun, Oct 04, 2015 at 02:11:49PM -0400, Michael Reed wrote:
> The use of an ellipsis in manuals usually seems to already imply
> optional arguments, e.g., `.Op Ar file ...', so constructs like
> `Ar pkg-name Op Ar ...' seem redundant to me.
> 
> While here, also denote the `pkg-name' argument to pkg_delete
> as optional, since you can do things like `pkg_delete -nX'.
> 

fixed, thanks.
jmc

> 
> 
> Index: pkg_add.1
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/pkg_add.1,v
> retrieving revision 1.132
> diff -u -p -r1.132 pkg_add.1
> --- pkg_add.1 16 Apr 2015 20:01:39 -  1.132
> +++ pkg_add.1 4 Oct 2015 17:54:40 -
> @@ -31,7 +31,7 @@
>  .Op Fl L Ar localbase
>  .Op Fl l Ar file
>  .Op Fl P Ar type
> -.Ar pkg-name Op Ar ...
> +.Ar pkg-name ...
>  .Ek
>  .Sh DESCRIPTION
>  The
> Index: pkg_delete.1
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/pkg_delete.1,v
> retrieving revision 1.50
> diff -u -p -r1.50 pkg_delete.1
> --- pkg_delete.1  8 Apr 2015 17:25:58 -   1.50
> +++ pkg_delete.1  4 Oct 2015 17:54:40 -
> @@ -26,7 +26,7 @@
>  .Op Fl acIimnqsvXx
>  .Op Fl B Ar pkg-destdir
>  .Op Fl D Ar name Ns Op = Ns Ar value
> -.Ar pkg-name Op Ar ...
> +.Op Ar pkg-name ...
>  .Sh DESCRIPTION
>  The
>  .Nm
> Index: pkg_info.1
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/pkg_info.1,v
> retrieving revision 1.50
> diff -u -p -r1.50 pkg_info.1
> --- pkg_info.18 Sep 2014 01:27:55 -   1.50
> +++ pkg_info.14 Oct 2015 17:54:40 -
> @@ -30,8 +30,7 @@
>  .Op Fl l Ar str
>  .Op Fl Q Ar query
>  .Op Fl r Ar pkgspec
> -.Op Ar pkg-name
> -.Op Ar ...
> +.Op Ar pkg-name ...
>  .Ek
>  .Sh DESCRIPTION
>  The
> Index: OpenBSD/PkgAdd.pm
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgAdd.pm,v
> retrieving revision 1.87
> diff -u -p -r1.87 PkgAdd.pm
> --- OpenBSD/PkgAdd.pm 30 Jun 2015 19:20:08 -  1.87
> +++ OpenBSD/PkgAdd.pm 4 Oct 2015 17:54:40 -
> @@ -107,7 +107,7 @@ sub handle_options
>   my $state = shift;
>   $state->SUPER::handle_options('ruUzl:A:P:',
>   '[-acinqrsUuvxz] [-A arch] [-B pkg-destdir] [-D name[=value]]',
> - '[-L localbase] [-l file] [-P type] pkg-name [...]');
> + '[-L localbase] [-l file] [-P type] pkg-name ...');
>  
>   $state->{arch} = $state->opt('A');
>  
> Index: OpenBSD/PkgDelete.pm
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgDelete.pm,v
> retrieving revision 1.34
> diff -u -p -r1.34 PkgDelete.pm
> --- OpenBSD/PkgDelete.pm  29 Nov 2014 10:42:51 -  1.34
> +++ OpenBSD/PkgDelete.pm  4 Oct 2015 17:54:40 -
> @@ -101,7 +101,7 @@ sub handle_options
>  {
>   my $state = shift;
>   $state->SUPER::handle_options('X',
> - '[-acimnqsvXx] [-B pkg-destdir] [-D name[=value]] pkg-name [...]');
> + '[-acimnqsvXx] [-B pkg-destdir] [-D name[=value]] [pkg-name ...]');
>  
>   my $base = $state->opt('B') // $ENV{'PKG_DESTDIR'} // '';
>   if ($base ne '') {
> Index: OpenBSD/PkgInfo.pm
> ===
> RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgInfo.pm,v
> retrieving revision 1.35
> diff -u -p -r1.35 PkgInfo.pm
> --- OpenBSD/PkgInfo.pm6 Apr 2015 12:19:35 -   1.35
> +++ OpenBSD/PkgInfo.pm4 Oct 2015 17:54:40 -
> @@ -559,7 +559,7 @@ sub parse_and_run
>   $state->{no_exports} = 1;
>   $state->handle_options('cCdfF:hIKLmPQ:qr:RsSUe:E:Ml:aAt',
>   '[-AaCcdfIKLMmPqRSstUv] [-D nolock][-E filename] [-e pkg-name] ',
> - '[-l str] [-Q query] [-r pkgspec] [pkg-name] [...]');
> + '[-l str] [-Q query] [-r pkgspec] [pkg-name ...]');
>  
>   if ($state->opt('r')) {
>  
>