Re: usr.bin/man: use getlist(char *) instead of hand-rolled equivalent in config(char *)

Hi, Kent R. Spillner wrote on Wed, Jun 04, 2014 at 10:01:12AM -0500: > config(char *) contains a hand-rolled version of getlist(char *). Indeed. > The only difference is that the hand-rolled version includes a NULL > check before the strcmp. You misread the code. There is no NULL check for th

Re: Miscellaneous LibreSSL portability fixes

On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote: > >I ported libressl to my custom hobby OS and it has been a pleasant >experience. Nonetheless, I did run into some minor portability problems >that I wish to share: > >* apps/Makefile.am.tpl links libcrypto and libssl in the wrong orde

Re: Probably you already know but http://www.openbsd.org/cgi-bin/cvsweb/ is returning HTTP 403 Forbidden

On Wed, Jul 16, 2014 at 11:01 PM, patrick keshishian wrote: > On 7/16/14, Bob Beck wrote: > > I've disabled it due to persistant DOS attacks. It may come back later. > > wait ... what? > > you helping'em? :P > In the times that you've come back from 15 hours of travel to a "MUST DO NOW" list lo

Re: Probably you already know but http://www.openbsd.org/cgi-bin/cvsweb/ is returning HTTP 403 Forbidden

On 7/16/14, Bob Beck wrote: > I've disabled it due to persistant DOS attacks. It may come back later. wait ... what? you helping'em? :P --patrick > On Wed, Jul 16, 2014 at 12:11 PM, Rafael Neves > wrote: >> Hi Beck, >> >> Probably you already know is

Re: Miscellaneous LibreSSL portability fixes

Steve, sorry, but GNU/kFreeBSD is not going to happen right now. We are too busy with other things. On Wed, Jul 16, 2014 at 6:26 PM, Steven Chamberlain wrote: > Hi, > > On 16/07/14 23:02, Jonas 'Sortie' Termansen wrote: >> * Consider using _DEFAULT_SOURCE or _ALL_SOURCE as feature macros on >>

Re: Miscellaneous LibreSSL portability fixes

Hi Jonas, While you make a few good points and they will be considered, but really, "custom hobby os" is not really on our radar right now. We have our hands full enough with portable dealing with the major distros and libc's, and fending off all the haters. On Wed, Jul 16, 2014 at 4:02 PM, Jonas

Re: Miscellaneous LibreSSL portability fixes

On Thu, 17 Jul 2014, Jonas 'Sortie' Termansen wrote: > I ported libressl to my custom hobby OS and it has been a pleasant > experience. Nonetheless, I did run into some minor portability problems > that I wish to share: To respond to selected items... > * apps/Makefile.am.tpl links libcrypto and

Re: Miscellaneous LibreSSL portability fixes

Wow, this is a lot to go through, but I really do appreciate it. It may take me a bit to sort through these, Could send them to me as discrete patches (e.g. like a git send-email patch series)? That would make them easier to sort through and apply individually? On Jul 16, 2014, at 5:02 PM, Jona

Re: lynx: disable old protocols

On Wed, Jul 16, 2014 at 4:00 PM, Shawn K. Quinn wrote: > On Wed, 2014-07-16 at 13:56 -0500, patric conant wrote: > > I'd also like to point out that Shawn has broken the social contract > > here, it's well known that it's generally considered rude to direct > > developers, in this forum. > > Ever

Re: Miscellaneous LibreSSL portability fixes

Hi, On 16/07/14 23:02, Jonas 'Sortie' Termansen wrote: > * Consider using _DEFAULT_SOURCE or _ALL_SOURCE as feature macros on > unknown platforms. > * crypto/compat/issetugid_linux.c is used on non-Linux platforms. This > fail on including glibc internal headers which is hardly elegant. Thos

Re: lynx: disable old protocols

> For the rest of us who prefer to use software instead of demanding > changes, this simply means using OpenBSD in a strictly-isolated > environment becomes a bit more difficult. This statement makes no sense. Why would you strictly isolate the environment? Because you want security. In that ca

Re: lynx: disable old protocols

For the rest of us who prefer to use software instead of demanding changes, this simply means using OpenBSD in a strictly-isolated environment becomes a bit more difficult. I'm still not willing to use Linux LiveCDs in certain environments for the most part, and I'll just get used to having the

Miscellaneous LibreSSL portability fixes

Hi, I ported libressl to my custom hobby OS and it has been a pleasant experience. Nonetheless, I did run into some minor portability problems that I wish to share: * apps/Makefile.am.tpl links libcrypto and libssl in the wrong order. The libssl library depends on libcrypto and libcrypto doesn'

Re: lynx: disable old protocols

On 07/16/14 17:00, Shawn K. Quinn wrote: On Wed, 2014-07-16 at 13:56 -0500, patric conant wrote: I'd also like to point out that Shawn has broken the social contract here, it's well known that it's generally considered rude to direct developers, in this forum. Every single free or open-source s

Re: ffs2 boot

*Bump* > On Jul 10, 2014, at 12:33, "Kent R. Spillner" wrote: > > Ping. > >> On Thu, May 01, 2014 at 01:22:56PM -0500, Kent R. Spillner wrote: >> After sending my previous reply I noticed that you already committed >> your diff, so here are my comments again in the form of a proper diff: >> >>

Re: usr.bin/man: use getlist(char *) instead of hand-rolled equivalent in config(char *)

*Bump* > On Jul 10, 2014, at 12:34, "Kent R. Spillner" wrote: > > Ping. > >> On Wed, Jun 04, 2014 at 10:01:12AM -0500, Kent R. Spillner wrote: >> config(char *) contains a hand-rolled version of getlist(char *). The only >> difference >> is that the hand-rolled version includes a NULL check b

Re: lynx: disable old protocols

On 2014/07/16 16:00, Jean-Philippe Ouellet wrote: > Oh come on... It's not like the URLs are some giant uuid-based madness > or something. All the mirrors have the same simple layout. If you install > lots of boxes regularly, it doesn't take long to memorize the name of > your closest mirror. If yo

Re: lynx: disable old protocols

>On Wed, 2014-07-16 at 13:56 -0500, patric conant wrote: >> I'd also like to point out that Shawn has broken the social contract >> here, it's well known that it's generally considered rude to direct >> developers, in this forum. > >Every single free or open-source software project I have ever use

Re: lynx: disable old protocols

On Wed, 2014-07-16 at 13:56 -0500, patric conant wrote: > I'd also like to point out that Shawn has broken the social contract > here, it's well known that it's generally considered rude to direct > developers, in this forum. Every single free or open-source software project I have ever used has

Re: improve srandomdev

> > That is false. Please read the actual code. The new variation uses > > srandomdev() as an indicator that random() gets hooked direct to > > arc4random. The guts of the algorithm are never used again. > I did, that's why "fwiw" and "needed", as in "look, you fixed a bug > without noticing".

Re: lynx: disable old protocols

On Wed, Jul 16, 2014 at 01:56:00PM -0500, patric conant wrote: > Isn't there a responsibility to disclose that, and possibly remove it > from base. It's being removed. > ... you use it to get a list of mirrors for your newly installed system, > so you can set the pkg_path. I'd love it if we inclu

Re: improve srandomdev

On 07/16/2014 04:28 PM, Theo de Raadt wrote: On 07/13/2014 06:31 PM, Jean-Philippe Ouellet wrote: On Sun, Jul 13, 2014 at 04:03:53PM +0200, Brent Cook wrote: On Jul 13, 2014, at 3:58 PM, Ted Unangst wrote: @@ -411,6 +404,9 @@ static long random_l(void) { int32_t i; + + if (use_a

Re: Probably you already know but http://www.openbsd.org/cgi-bin/cvsweb/ is returning HTTP 403 Forbidden

I've disabled it due to persistant DOS attacks. It may come back later. On Wed, Jul 16, 2014 at 12:11 PM, Rafael Neves wrote: > Hi Beck, > > Probably you already know is > returning HTTP 403 Forbidden. This is recent, maybe two or three days. > > Is there

Re: lynx: disable old protocols

What about the other direction, what about all the poeple who believe that lynx is the end-all, be-all choice for secure browsing, because they believe that it's the only browser that is held to the audit standards of being included in OpenBSD base. If it isn't, isn't there a responsibility to disc

[patch] sys/dev/ic/mfi.c

Hi, I think is a bug in sys/dev/ic/mfi.c noticed during "PATCH: further kernel malloc -> mallocarray" review[1] I see the mallocarray() patch seems to have been applied. Want to make sure if this is in fact a bug, that it is not overlooked. Ignore if this is noise. Cheers, --patrick [1] http:/

Re: LibreSSL portable 2.0.2 released.

> The newly-added /tests/asn1test fails to complete successfully under > Linux when built as 32-bit object, in either a 32-bit userspace > or on a multiarch. Indeed; the test was not 32-bit friendly. A length of 340 is correct in that case; I have fixed the test so that it behaves the same way on

Re: mg: [macro.c:41]: (error) Memory pointed to by 'lp1' is freed twice.

> I recently used cppcheck on mg and I got this message: > > [macro.c:41]: (error) Memory pointed to by 'lp1' is freed twice. > > Looking at the code: > > /* free lines allocated for string arguments */ > if (maclhead != NULL) { > for (lp1 = maclhead->l_fp; lp1 != maclhead; lp1 = lp2) { >

Re: LibreSSL portable 2.0.2 released.

>We have release an update, LibreSSL 2.0.2 > >This release addresses the Linux forking and pid wrap issue reported >recently in the press. The newly-added /tests/asn1test fails to complete successfully under Linux when built as 32-bit object, in either a 32-bit userspace or on a multiarch. $ .

Re: LibreSSL portable 2.0.2 released.

yep - running it now, it takes a few minutes On Wed, Jul 16, 2014 at 8:28 AM, Mark Kettenis wrote: >> From: Bob Beck >> Date: Wed, 16 Jul 2014 07:55:16 -0600 >> >> please commit that mark > > committed to cvs (with HAVE_GETAUXVAL instead of HAVE_AUXVAL) > > guess one of you can do the magic to

mg: [macro.c:41]: (error) Memory pointed to by 'lp1' is freed twice.

I recently used cppcheck on mg and I got this message: [macro.c:41]: (error) Memory pointed to by 'lp1' is freed twice. Looking at the code: /* free lines allocated for string arguments */ if (maclhead != NULL) { for (lp1 = maclhead->l_fp; lp1 != maclhead; lp1 = lp2) { lp

Re: PATCH: further kernel malloc -> mallocarray

> static __inline int > MULT_OVERFLOWS(int x, int y) > { > const intmax_t max = 1UL << sizeof(size_t) * 4; > > return ((x >= max || y >= max) && x > 0 && SIZE_MAX / x < y); > } > > (or maybe a macro version) in some public header someplace, > and associated assertions it where applica

Re: PATCH: further kernel malloc -> mallocarray

> > From: Theo de Raadt > > Date: Wed, 16 Jul 2014 08:18:34 -0600 > > > > I would really really prefer if we can keep these as const*const > > conversions instead of const, const. > > Indeed, conversion to mallocarray only makes sence if one of the > multiplication operands is a variable. That

Re: PATCH: further kernel malloc -> mallocarray

> From: Theo de Raadt > Date: Wed, 16 Jul 2014 08:18:34 -0600 > > I would really really prefer if we can keep these as const*const > conversions instead of const, const. Indeed, conversion to mallocarray only makes sence if one of the multiplication operands is a variable.

Re: LibreSSL portable 2.0.2 released.

> From: Bob Beck > Date: Wed, 16 Jul 2014 07:55:16 -0600 > > please commit that mark committed to cvs (with HAVE_GETAUXVAL instead of HAVE_AUXVAL) guess one of you can do the magic to get this into the git repo? > On Wed, Jul 16, 2014 at 3:14 AM, Mark Kettenis > wrote: > >> Date: Wed, 16 Jul

Re: improve srandomdev

> On 07/13/2014 06:31 PM, Jean-Philippe Ouellet wrote: > > On Sun, Jul 13, 2014 at 04:03:53PM +0200, Brent Cook wrote: > >> On Jul 13, 2014, at 3:58 PM, Ted Unangst wrote: > >>> @@ -411,6 +404,9 @@ static long > >>> random_l(void) > >>> { > >>> int32_t i; > >>> + > >>> + if (use_arc4random) > >>

Re: improve srandomdev

On 07/13/2014 06:31 PM, Jean-Philippe Ouellet wrote: On Sun, Jul 13, 2014 at 04:03:53PM +0200, Brent Cook wrote: On Jul 13, 2014, at 3:58 PM, Ted Unangst wrote: @@ -411,6 +404,9 @@ static long random_l(void) { int32_t i; + + if (use_arc4random) + return arc4random()

Re: PATCH: further kernel malloc -> mallocarray

I would really really prefer if we can keep these as const*const conversions instead of const, const. We will see performance losses from doing this operation at runtime. > On Wed, Jul 16, 2014 at 04:54:49AM +, Doug Hogan wrote: > > > > + if ((fake_table = mallocarray(3, sizeof(str

Re: LibreSSL portable 2.0.2 released.

please commit that mark On Wed, Jul 16, 2014 at 3:14 AM, Mark Kettenis wrote: >> Date: Wed, 16 Jul 2014 11:03:12 +0200 >> From: Martin Hecht >> >> On 07/16/2014 05:40 AM, Bob Beck wrote: >> > We have release an update, LibreSSL 2.0.2 >> > >> > This release addresses the Linux forking and pid wr

Re: LibreSSL and GOST crypto

> On Wed, Jul 16, 2014 at 12:29 PM, Dmitry Eremin-Solenikov > wrote: > > I have started looking into GOST (re)implementation for LibreSSL. > > I would like to know, how much do you want for LibreSSL to mimic > > the OpenSSL behaviour. > > I have been pointed that I did not formulate the question

Re: LibreSSL and GOST crypto

Hello, On Wed, Jul 16, 2014 at 12:29 PM, Dmitry Eremin-Solenikov wrote: > I have started looking into GOST (re)implementation for LibreSSL. > I would like to know, how much do you want for LibreSSL to mimic > the OpenSSL behaviour. I have been pointed that I did not formulate the question clearl

Re: DNS control port additions to /etc/services

On 2014/07/16 11:02, Craig R. Skinner wrote: > On 2014-07-15 Tue 16:04 PM |, Theo de Raadt wrote: > > >On Tue, Jul 15, 2014 at 12:22:37PM +0100, Craig R. Skinner wrote: > > >> > > >> Suggestion of add NSD, Unbound & BIND control ports to /etc/services: > > > > > >Makes sense to me. Anyone want to

Re: DNS control port additions to /etc/services

On 2014-07-15 Tue 16:04 PM |, Theo de Raadt wrote: > >On Tue, Jul 15, 2014 at 12:22:37PM +0100, Craig R. Skinner wrote: > >> > >> Suggestion of add NSD, Unbound & BIND control ports to /etc/services: > > > >Makes sense to me. Anyone want to OK this? > > > >> Index: etc/services > >> ==

Re: /etc/services records for squid & cvsyncd

On 2014-07-15 Tue 22:11 PM |, Antoine Jacoutot wrote: > > I run both squid and cvsyncd and never needed these entries. > Doubtful anyone _needs_ the Microsoft-SQL-* entries. > > > > > > > Index: etc/services > > === > > RCS fil

Re: Changing a running process' cmd name/argv[0]

On Wed, Jul 16, 2014 at 4:26 AM, Gustav Fransson Nyvell wrote: > > Oh, I see, that's exactly what's happened: you've hacked ksh to call a >> library that forks and your .xinitrc stopped working as a result. >> "Doctor, it hurts when I poke myself with a fork()" >> "So don't do that!" >> >> >

Re: Changing a running process' cmd name/argv[0]

Oh, I see, that's exactly what's happened: you've hacked ksh to call a library that forks and your .xinitrc stopped working as a result. "Doctor, it hurts when I poke myself with a fork()" "So don't do that!" Philip Guenther No wonder you don't have time to code. -- This e-mail is con

Re: LibreSSL portable 2.0.2 released.

> Date: Wed, 16 Jul 2014 11:03:12 +0200 > From: Martin Hecht > > On 07/16/2014 05:40 AM, Bob Beck wrote: > > We have release an update, LibreSSL 2.0.2 > > > > This release addresses the Linux forking and pid wrap issue reported > > recently in > > the press. > > > > As noted before, we welcome f

Re: Changing a running process' cmd name/argv[0]

On Wed, Jul 16, 2014 at 3:45 AM, Gustav Fransson Nyvell wrote: > On 07/16/14 10:31, Philip Guenther wrote: > > On Wed, Jul 16, 2014 at 2:53 AM, Gustav Fransson Nyvell > wrote: > >> On 07/15/14 23:55, Philip Guenther wrote: >> > ... > So let's try that question directly: what process (*not

Re: LibreSSL portable 2.0.2 released.

On 07/16/2014 05:40 AM, Bob Beck wrote: > We have release an update, LibreSSL 2.0.2 > > This release addresses the Linux forking and pid wrap issue reported recently > in > the press. > > As noted before, we welcome feedback from the broader community. > > Enjoy > > -Bob > Hi, with 2.0.2 on Xubun

Re: Changing a running process' cmd name/argv[0]

On 07/16/14 10:31, Philip Guenther wrote: On Wed, Jul 16, 2014 at 2:53 AM, Gustav Fransson Nyvell mailto:gus...@nyvell.se>> wrote: On 07/15/14 23:55, Philip Guenther wrote: On Tue, Jul 15, 2014 at 6:20 AM, Gustav Fransson Nyvell mailto:gus...@nyvell.se>> wrote: On 07/15/14

Re: Changing a running process' cmd name/argv[0]

On 07/16/14 10:31, Stuart Henderson wrote: On 2014/07/16 09:53, Gustav Fransson Nyvell wrote: Hm, no, .xinitrc itself is the process that calls fork etc since it uses a lib that does this. Do you mean that you have replaced .xinitrc, which is documented as a file that should be a shell script,

Re: Changing a running process' cmd name/argv[0]

On Wed, Jul 16, 2014 at 2:53 AM, Gustav Fransson Nyvell wrote: > On 07/15/14 23:55, Philip Guenther wrote: > > On Tue, Jul 15, 2014 at 6:20 AM, Gustav Fransson Nyvell > wrote: > >> On 07/15/14 11:13, Peter Hessler wrote: >> >>> On 2014 Jul 15 (Tue) at 10:25:49 +0200 (+0200), Gustav Fransson Ny

Re: Changing a running process' cmd name/argv[0]

On 2014/07/16 09:53, Gustav Fransson Nyvell wrote: > Hm, no, .xinitrc itself is the process that calls fork etc since it uses a > lib that does this. Do you mean that you have replaced .xinitrc, which is documented as a file that should be a shell script, with binary object code? If so, the solut

LibreSSL and GOST crypto

Hello, I have started looking into GOST (re)implementation for LibreSSL. I would like to know, how much do you want for LibreSSL to mimic the OpenSSL behaviour. Originally (thanks CryptoCom) GOST algorithms were implemented as a separate OpenSSL engine (to ease certification, to ease replacing cc

Re: Changing a running process' cmd name/argv[0]

On 07/15/14 23:55, Philip Guenther wrote: On Tue, Jul 15, 2014 at 6:20 AM, Gustav Fransson Nyvell mailto:gus...@nyvell.se>> wrote: On 07/15/14 11:13, Peter Hessler wrote: On 2014 Jul 15 (Tue) at 10:25:49 +0200 (+0200), Gustav Fransson Nyvell wrote: :On 07/15/14 09:4

Re: PATCH: further kernel malloc -> mallocarray

On Wed, Jul 16, 2014 at 04:54:49AM +, Doug Hogan wrote: > > + if ((fake_table = mallocarray(3, sizeof(struct est_op), It's not necessary to use mallocarray() for well known constants. Few examples below. > --- sys/arch/i386/i386/est.c 12 Jul 2014 18:44:41 - 1.43 > +++ s

Re: PATCH: further kernel malloc -> mallocarray

On Tue, Jul 15, 2014 at 11:34:01PM -0700, patrick keshishian wrote: > For obvious cases such as this, is it worth converting? Maybe not. I left it since it is an array. > might be safer to change this (in a separate diff) to: > > dc->dc_bs = mallocarray(ri->ri_rows, > ri->ri

Re: PATCH: further kernel malloc -> mallocarray

For the cases where it's more than just nitems * sizeof(item), maybe it wouldn't be a bad idea to have something like: static __inline int MULT_OVERFLOWS(int x, int y) { const intmax_t max = 1UL << sizeof(size_t) * 4; return ((x >= max || y >= max) && x > 0 && SIZE_MAX / x < y); }