Re: rpki-client: retire log.c

On Thu, Jun 29, 2023 at 09:12:06AM +, Job Snijders wrote: > On Thu, Jun 29, 2023 at 09:30:19AM +0200, Theo Buehler wrote: > > I wrote versions of this diff several times in the past but never sent > > it out. A question by claudio encouraged me... > > > > cryptowarnx() and cryptoerrx() fail

Re: rpki-client: retire log.c

On Thu, Jun 29, 2023 at 09:30:19AM +0200, Theo Buehler wrote: > I wrote versions of this diff several times in the past but never sent > it out. A question by claudio encouraged me... > > cryptowarnx() and cryptoerrx() fail at showing openssl error stacks > in a pleasant way as no amount of

rpki-client: retire log.c

I wrote versions of this diff several times in the past but never sent it out. A question by claudio encouraged me... cryptowarnx() and cryptoerrx() fail at showing openssl error stacks in a pleasant way as no amount of lipstick can make this pig pretty. I don't think these stacks should be shown

Re: rpki-client: retire valid_cert()

On Mon, Aug 22, 2022 at 12:14:53PM +0200, Theo Buehler wrote: > rpki-client portable makes sure that libcrypto has RFC 3779 support. > Therefore the X509_verify_cert() call in valid_x509() will already > perform the checks that the RFC 3779 extensions are covered along the > chain. While

Re: rpki-client: retire valid_cert()

On Mon, Aug 22, 2022 at 12:14:53PM +0200, Theo Buehler wrote: > rpki-client portable makes sure that libcrypto has RFC 3779 support. > Therefore the X509_verify_cert() call in valid_x509() will already > perform the checks that the RFC 3779 extensions are covered along the > chain. While

rpki-client: retire valid_cert()

rpki-client portable makes sure that libcrypto has RFC 3779 support. Therefore the X509_verify_cert() call in valid_x509() will already perform the checks that the RFC 3779 extensions are covered along the chain. While valid_cert()'s errors would be nicer than the validator's, they can't be

Re: bgpd, retire F_RTLABEL flag

On Tue, Jun 07, 2022 at 05:47:52PM +0200, Theo Buehler wrote: > On Tue, Jun 07, 2022 at 05:09:30PM +0200, Claudio Jeker wrote: > > The F_RTLABEL flag does nothing. So just remove it. > > Checking the rtlabelid != 0 is equivalent. > > Doesn't twiddling the F_RTLABEL potentially change the outcome

Re: bgpd, retire F_RTLABEL flag

On Tue, Jun 07, 2022 at 05:09:30PM +0200, Claudio Jeker wrote: > The F_RTLABEL flag does nothing. So just remove it. > Checking the rtlabelid != 0 is equivalent. Doesn't twiddling the F_RTLABEL potentially change the outcome of the two if (flags != oflags) changed = 1;

bgpd, retire F_RTLABEL flag

The F_RTLABEL flag does nothing. So just remove it. Checking the rtlabelid != 0 is equivalent. -- :wq Claudio Index: bgpd.h === RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v retrieving revision 1.426 diff -u -p -r1.426 bgpd.h ---

Re: crypto: retire async crypto API

> On 23 Oct 2021, at 16:08, Tobias Heider wrote: > > Now that we have removed all the legacy crypto offloading drivers we can > simplify the crypto framework API by ripping out the async callbacks. > > The diff below removes crypto_dispatch() and crypto_done() and replaces > them with

Re: crypto: retire async crypto API

On Sat, Oct 23, 2021 at 03:08:29PM +0200, Tobias Heider wrote: > Now that we have removed all the legacy crypto offloading drivers we can > simplify the crypto framework API by ripping out the async callbacks. > > The diff below removes crypto_dispatch() and crypto_done() and replaces > them with

crypto: retire async crypto API

Now that we have removed all the legacy crypto offloading drivers we can simplify the crypto framework API by ripping out the async callbacks. The diff below removes crypto_dispatch() and crypto_done() and replaces them with crypto_invoke() which is blocking and only returns after the operation

Re: retire hifn safe ubsec

On 2021/10/21 10:02, Theo de Raadt wrote: > Stuart Henderson wrote: > > > On 2021/10/21 16:30, Alexander Bluhm wrote: > > > Hi, > > > > > > Goal is to retire the async crypto API. It is slow and adds > > > complexity which hinders MP progress in

Re: retire hifn safe ubsec

Stuart Henderson wrote: > On 2021/10/21 16:30, Alexander Bluhm wrote: > > Hi, > > > > Goal is to retire the async crypto API. It is slow and adds > > complexity which hinders MP progress in IPsec. It is used by the > > old PCI devices hifn(4), safe(4), and

Re: retire hifn safe ubsec

On 2021/10/21 16:30, Alexander Bluhm wrote: > Hi, > > Goal is to retire the async crypto API. It is slow and adds > complexity which hinders MP progress in IPsec. It is used by the > old PCI devices hifn(4), safe(4), and ubsec(4). > > These devices are not common an

Re: retire hifn safe ubsec

On Thu, Oct 21, 2021 at 04:30:02PM +0200, Alexander Bluhm wrote: > Hi, > > Goal is to retire the async crypto API. It is slow and adds > complexity which hinders MP progress in IPsec. It is used by the > old PCI devices hifn(4), safe(4), and ubsec(4). > > These devices a

Re: retire hifn safe ubsec

On Thu, Oct 21, 2021 at 04:30:02PM +0200, Alexander Bluhm wrote: > Goal is to retire the async crypto API. It is slow and adds > complexity which hinders MP progress in IPsec. It is used by the > old PCI devices hifn(4), safe(4), and ubsec(4). > > These devices are not common

Re: Retire

On 2020-06-20, Christian Weisgerber wrote: >> Well... they something in ports might still look at them in >> >> >> Can someone from ports speak about this? > > I have started an amd64 bulk build without . There were no build failures attributable to this. The header can be removed. --

Re: Retire

On 2020-06-19, "Theo de Raadt" wrote: > Well... they something in ports might still look at them in > > Can someone from ports speak about this? I have started an amd64 bulk build without . -- Christian "naddy" Weisgerber na...@mips.inka.de

Re: Retire

Well... they something in ports might still look at them in Can someone from ports speak about this? Visa Hankala wrote: > The header has been unhooked from / > for a while, and no one has complained. Nothing seems to > reference any longer, so the following files should > be ready for

Retire

The header has been unhooked from / for a while, and no one has complained. Nothing seems to reference any longer, so the following files should be ready for removal: sys/arch/alpha/include/stdarg.h sys/arch/amd64/include/stdarg.h sys/arch/arm/include/stdarg.h sys/arch/arm64/include/stdarg.h

Retire

The header is not used any longer. Consequently, it should be safe to remove the following files: sys/arch/alpha/include/varargs.h sys/arch/hppa/include/varargs.h sys/arch/i386/include/varargs.h sys/arch/landisk/include/varargs.h sys/arch/loongson/include/varargs.h

Re: Time to retire RTM_LOSING

On Wed, Jul 11, 2018 at 10:10:50AM +0200, Martin Pieuchot wrote: > On 11/07/18(Wed) 09:55, Claudio Jeker wrote: > > On busy servers I seen multiple RTM_LOSING message per second being > > generated. This is not helpful (especially since nothing is doing > > something with it). This diff removes

Re: Time to retire RTM_LOSING

On 11/07/18(Wed) 09:55, Claudio Jeker wrote: > On busy servers I seen multiple RTM_LOSING message per second being > generated. This is not helpful (especially since nothing is doing > something with it). This diff removes the part where RTM_LOSING is > generated I'm fine with that. However what

Time to retire RTM_LOSING

On busy servers I seen multiple RTM_LOSING message per second being generated. This is not helpful (especially since nothing is doing something with it). This diff removes the part where RTM_LOSING is generated but at the same time adds some RTM_ADD / RTM_DELETE messages for the dynamic routes

retire icmp6_rip6_input

Hi, As the comment says, icmp6_rip6_input() is mostly duplicated code from rip6_input(). So lets merge these functions together and retire icmp6_rip6_input(). ok? bluhm Index: netinet6/icmp6.c === RCS file: /data/mirror/openbsd

retire ip6protosw

Hi, If I change the IPv4 pr_input function to the way IPv6 is implemented, I can get rid of struct ip6protosw and some wrapper functions. I think it more consistent to have less different structures. Most conversions are mechanical. Where the IPv4 and IPv6 fucntions were identical, I removed

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

On Thu, Nov 12, 2015 at 02:52:01PM +0800, Michael W. Bombardieri wrote: > > > ok for removing xfree from aucat? > > > > > > > yes, ok ratchov; if later this causes me merges i'll find another > > solution. Feel free to do the same in usr.bin/sndiod, as it's > > almost the same. > > > > Same

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Alexandre Ratchov wrote: > On Thu, Nov 12, 2015 at 02:52:01PM +0800, Michael W. Bombardieri wrote: > > > > ok for removing xfree from aucat? > > > > > > yes, ok ratchov; if later this causes me merges i'll find another > > > solution. Feel free to do the same in usr.bin/sndiod, as it's > > >

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Michael W. Bombardieri wrote: > > > ok for removing xfree from aucat? > > > > yes, ok ratchov; if later this causes me merges i'll find another > > solution. Feel free to do the same in usr.bin/sndiod, as it's > > almost the same. > > Same thing for sndiod... ok mmcc@ > Index: abuf.c >

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

> > ok for removing xfree from aucat? > > > > yes, ok ratchov; if later this causes me merges i'll find another > solution. Feel free to do the same in usr.bin/sndiod, as it's > almost the same. > Same thing for sndiod... Index: abuf.c

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

> On November 9, 2015 at 5:04 AM Michael McConville wrote: > Tobias, could you split your latest diff into separate diffs for each > function type (xmalloc, xcalloc, etc.)? It'd make it easier to zero in > on the problematic hunks and fast-track the rest. I don't really see

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

On Sun, Nov 08, 2015 at 07:43:10PM -0500, Michael McConville wrote: > Maybe we should pick this off in smaller chunks so that we don't get > immobilized by a few scattered issues. > > ok for removing xfree from aucat? > yes, ok ratchov; if later this causes me merges i'll find another solution.

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Hmm yes you are right, in that case, go for it. On Sun, Nov 08, 2015 at 02:00:17PM +0100, Joerg Sonnenberger wrote: > On Sun, Nov 08, 2015 at 08:36:52AM +, Nicholas Marriott wrote: > > On Sat, Nov 07, 2015 at 08:42:14PM -0500, Ted Unangst wrote: > > > Tobias Stoeckmann wrote: > > > > Is this

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

On Sun, Nov 08, 2015 at 08:36:52AM +, Nicholas Marriott wrote: > On Sat, Nov 07, 2015 at 08:42:14PM -0500, Ted Unangst wrote: > > Tobias Stoeckmann wrote: > > > Is this okay for ssh and tmux, which are out to be very portable? > > > Nicholas mentioned that malloc is not required to set errno.

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Alexandre Ratchov wrote: > On Sun, Nov 08, 2015 at 09:56:23AM +0800, Michael W. Bombardieri wrote: > > On Thu, Nov 05, 2015 at 03:50:29PM +0100, Tobias Stoeckmann wrote: > > > On Thu, Nov 05, 2015 at 09:50:48AM +, Nicholas Marriott wrote: > > > > I don't know why cvs and rcs xmalloc.c has

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Maybe we should pick this off in smaller chunks so that we don't get immobilized by a few scattered issues. ok for removing xfree from aucat? Index: abuf.c === RCS file: /cvs/src/usr.bin/aucat/abuf.c,v retrieving revision 1.26 diff

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Michael McConville wrote: > Maybe we should pick this off in smaller chunks so that we don't get > immobilized by a few scattered issues. > > ok for removing xfree from aucat? I just realized that this one was already submitted separately. Tobias, could you split your latest diff into separate

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

This is fine with me, I think it was better without errno, but using it can't do any harm. It is an extension TO set it, not to not set it, but I am pretty sure it only happens on platforms I don't care about :-). I suggest you check with djm or dtucker for ssh in case they do care, or there are

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

On Sat, Nov 07, 2015 at 08:42:14PM -0500, Ted Unangst wrote: > Tobias Stoeckmann wrote: > > Is this okay for ssh and tmux, which are out to be very portable? > > Nicholas mentioned that malloc is not required to set errno. I've also > > checked the standard and it's just an extension. Although at

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Hi On Sat, Nov 07, 2015 at 04:39:09PM -0500, Michael McConville wrote: > Nicholas Marriott wrote: > > Looks good, ok nicm > > Reviewing now, generally looks good. > > A few things: > > I don't understand the motive for all the err() -> errx() and fatal() -> > fatalx() changes. If I came across

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Nicholas Marriott wrote: > Looks good, ok nicm Reviewing now, generally looks good. A few things: I don't understand the motive for all the err() -> errx() and fatal() -> fatalx() changes. If I came across these, I probably would have suggested the reverse. err(1, "xstrdup") is a lot cleaner

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Here's an updated diff: - use "overflow" error message for snprintf and friends - use err instead of errx for out of memory conditions - if fatal() doesn't print error string, use ": %s", strerror(errno) Is this okay for ssh and tmux, which are out to be very portable? Nicholas mentioned that

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Michael McConville wrote: > Nicholas Marriott wrote: > > Looks good, ok nicm > > Reviewing now, generally looks good. > > A few things: > > I don't understand the motive for all the err() -> errx() and fatal() -> > fatalx() changes. If I came across these, I probably would have > suggested the

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

On Sat, Nov 07, 2015 at 05:57:55PM -0500, Ted Unangst wrote: > > Also, I'm seeing a couple "could not allocate memory" messages added to > > *snprintf() functions. They write to a supplied buffer, no? > > Good catch. Will update that one, thanks. > > > > + i = vsnprintf(str, len, fmt,

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Tobias Stoeckmann wrote: > > > > > + i = vsnprintf(str, len, fmt, ap); > > > > > va_end(ap); > > > > > > > > > > - if (i == -1 || i >= (int)size) > > > > > - fatal("xsnprintf: overflow"); > > > > > + if (i < 0 || i >= (int)len) > > > > > +

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Tobias Stoeckmann wrote: > Is this okay for ssh and tmux, which are out to be very portable? > Nicholas mentioned that malloc is not required to set errno. I've also > checked the standard and it's just an extension. Although at worst, > the user sees a wrong error message... Are they portable to

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

On Thu, Nov 05, 2015 at 03:50:29PM +0100, Tobias Stoeckmann wrote: > On Thu, Nov 05, 2015 at 09:50:48AM +, Nicholas Marriott wrote: > > I don't know why cvs and rcs xmalloc.c has ended up so different. > > It's not just about cvs and rcs: > > /usr/src/usr.bin/cvs/xmalloc.c >

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Michael W. Bombardieri wrote: > On Thu, Nov 05, 2015 at 03:50:29PM +0100, Tobias Stoeckmann wrote: > > On Thu, Nov 05, 2015 at 09:50:48AM +, Nicholas Marriott wrote: > > > I don't know why cvs and rcs xmalloc.c has ended up so different. > > > > It's not just about cvs and rcs: > > > >

Re: [patch] cvs: retire xfree()

Applied, thanks. I don't know why cvs and rcs xmalloc.c has ended up so different. On Thu, Nov 05, 2015 at 11:50:51AM +0800, Michael W. Bombardieri wrote: > Hi tech@, > > Function xfree() was previously removed from rcs, so drop it from > opencvs too... > >

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

I like this a lot. There are some trivial differences in the various xmalloc.h as well, and I think you could make the style consistent within the files (eg "return i" in xasprintf and xsnprintf). On Thu, Nov 05, 2015 at 03:50:29PM +0100, Tobias Stoeckmann wrote: > On Thu, Nov 05, 2015 at

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

On Thu, Nov 05, 2015 at 03:57:26PM +, Nicholas Marriott wrote: > I like this a lot. > > There are some trivial differences in the various xmalloc.h as well, and > I think you could make the style consistent within the files (eg "return > i" in xasprintf and xsnprintf). Oh yes, forgot to

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Looks good, ok nicm On Thu, Nov 05, 2015 at 05:35:22PM +0100, Tobias Stoeckmann wrote: > On Thu, Nov 05, 2015 at 03:57:26PM +, Nicholas Marriott wrote: > > I like this a lot. > > > > There are some trivial differences in the various xmalloc.h as well, and > > I think you could make the

unify xmalloc (was Re: [patch] cvs: retire xfree())

On Thu, Nov 05, 2015 at 09:50:48AM +, Nicholas Marriott wrote: > I don't know why cvs and rcs xmalloc.c has ended up so different. It's not just about cvs and rcs: /usr/src/usr.bin/cvs/xmalloc.c /usr/src/usr.bin/diff/xmalloc.c /usr/src/usr.bin/file/xmalloc.c /usr/src/usr.bin/rcs/xmalloc.c

[patch] cvs: retire xfree()

Hi tech@, Function xfree() was previously removed from rcs, so drop it from opencvs too... http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/rcs/xmalloc.c?f=h#rev1.9 Footnote: I noticed that rcsnum_free() is just free() so maybe that could be removed also (not included in this patch). -

Re: [patch] cvs: retire xfree()

Michael W. Bombardieri wrote: > Hi tech@, > > Function xfree() was previously removed from rcs, so drop it from > opencvs too... > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/rcs/xmalloc.c?f=h#rev1.9 Good catch, thanks. My eyes glazed over a little while reviewing this, but

Re: [patch] cvs: retire xfree()

> Good catch, thanks. > > My eyes glazed over a little while reviewing this, but tentative ok > mmcc@ > > Below is what I consider a better refactoring of buf_free(). It makes it > NULL-safe and has more classic free function logic. I didn't include buf_free() in my patch but that looks good.