> On 4/05/2020, at 9:30 AM, Stuart Henderson wrote:
>
> On 2020/05/04 09:23, Richard Procter wrote:
>> I like it.
>>
>> Assuming a mention in tcpbench.1 - ok procter
>
> ok like this? text stolen from ping.
the server has an small edge case: it refuses to display stats
that don’t exist,
Hello JCA,
thanks for the pointers.
> about this specific piece of code in pfctl, but the "kame hack" is still
> here and you really want to double check before removing such chunks in
...so pfctl is the wrong place to start with removal.
thanks and
regards
sashan
On 2020/05/04 09:23, Richard Procter wrote:
> I like it.
>
> Assuming a mention in tcpbench.1 - ok procter
ok like this? text stolen from ping.
Index: tcpbench.1
===
RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.1,v
retrieving revi
I like it.
Assuming a mention in tcpbench.1 - ok procter
> On 4/05/2020, at 4:25 AM, Stuart Henderson wrote:
>
> Is it worth triggering this on SIGINFO? I use that often with ping(1).
>
> Index: tcpbench.c
> ===
> RCS file: /cvs/
This prevents non-interactive invocations of ftp(1) from spawning
external commands in case they are compromised. This is a significant
security benefit for sysupgrade(8).
In the future, output files (specified with -o) can be opened before
pledge(2) is called, which will improve security further
On 2020-05-03 12:18, Theo de Raadt wrote:
> Thanks Stuart.
>
>
> The lesson is clear. No pledge/unveil work unless you test *ALL PROGRAM
> BEHAVIOURS*. Doing less than the full testing is ... uhm, egotistical.
Sorry about that. Hopefully my next version will fix it.
> And it is completely norm
On 2020-05-03 12:13, Stuart Henderson wrote:
> On 2020/05/02 20:19, Demi M. Obenour wrote:
>> The following patch tightens the pledges for ftp(1).
>>
>> This guarantees that ftp(1) cannot spawn child processes when operating
>> in batch mode, which is a significant security win.
>
> It breaks inte
On Sun, May 03 2020, Alexandr Nedvedicky wrote:
> Hello,
Hi Sashan,
> the question has popped up while on recent code review of some Solaris
> specific
> bug fixes: do we still need a code in diff below or is it OK to proceed
> and commit the diff?
>
> The chunk below uses bytes 2 and 3 to deri
Hello,
the question has popped up while on recent code review of some Solaris specific
bug fixes: do we still need a code in diff below or is it OK to proceed
and commit the diff?
The chunk below uses bytes 2 and 3 to derive a scope of link local address. It
seems to me those bytes/octets are al
On Sun, May 03, 2020 at 10:31:35AM -0600, Theo de Raadt wrote:
> Theo Buehler wrote:
>
> > On Sun, May 03, 2020 at 05:25:25PM +0100, Stuart Henderson wrote:
> > > Is it worth triggering this on SIGINFO? I use that often with ping(1).
> >
> > I was going to suggest a similar diff but couldn't fig
Theo Buehler wrote:
> On Sun, May 03, 2020 at 05:25:25PM +0100, Stuart Henderson wrote:
> > Is it worth triggering this on SIGINFO? I use that often with ping(1).
>
> I was going to suggest a similar diff but couldn't figure out why this
> breaks the stats at the end with ^C.
An error in managi
That's very nice.
I should mention that signal_handler() isn't an async signal handler,
since this is a libevent program using syncronous signal_set(). Therefore
the stdio and FPU use is safe.
Stuart Henderson wrote:
> Is it worth triggering this on SIGINFO? I use that often with ping(1).
>
>
On Sun, May 03, 2020 at 05:25:25PM +0100, Stuart Henderson wrote:
> Is it worth triggering this on SIGINFO? I use that often with ping(1).
I was going to suggest a similar diff but couldn't figure out why this
breaks the stats at the end with ^C.
>
> Index: tcpbench.c
> =
Is it worth triggering this on SIGINFO? I use that often with ping(1).
Index: tcpbench.c
===
RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.c,v
retrieving revision 1.62
diff -u -p -r1.62 tcpbench.c
--- tcpbench.c 2 May 2020 22:00:29 -0
Thanks Stuart.
The lesson is clear. No pledge/unveil work unless you test *ALL PROGRAM
BEHAVIOURS*. Doing less than the full testing is ... uhm, egotistical.
And it is completely normal that as the pledges and unveils harden,
the amount of test cases to discover exceeds expectation.
Stuart He
On 2020/05/02 20:19, Demi M. Obenour wrote:
> The following patch tightens the pledges for ftp(1).
>
> This guarantees that ftp(1) cannot spawn child processes when operating
> in batch mode, which is a significant security win.
It breaks interactive mode (!ls, more somefile, get somefile "|rot13
I don't believe you were joking. I believe you are one of those
crusadors (clapping coconuts together) who want to eliminate a few named
coding-constructs even in situations where they work in a completely
safe way, and furthermore are standardized as mandatory. This is probably
due to lack of ed
Hi,
On 02/05/2020 12:41, richard.n.proc...@gmail.com wrote:
>> More assumptions are implied here. How do I measure a 2400 bps link
>> with this
>> report? The precision is lost in "%.3Lf".
> I highly doubt anyone needs to benchmark a 2400 bps link. The display is
> in any case precise to 1000 bps
On Thu, Apr 30, 2020 at 11:19:14AM +, Kevin Chadwick wrote:
> On 2020-04-30 03:28, James Jerkins wrote:
> > This patch adds two new options to sysupgrade. The first option is for
> > small box systems like an APU system that only has the base and manual sets
> > installed. The second option i
On Sun, May 03, 2020 at 04:41:13AM -0400, Chris Bennett wrote:
> The FAQ already describes exactly how to upgrade with whatever sets one
> wants to. I have used that method many, many times successfully.
> I can't see any reason whatsoever to turn an addon tool into anything
> more than what it is.
Le 03/05/2020 à 10:41, Chris Bennett a écrit :
On Sun, May 03, 2020 at 04:40:44AM +0200, Stéphane Aulery wrote:
a) Removing sets selection from the installer
b) Supporting an upgrade of the sets already installed.
The FAQ already describes exactly how to upgrade with whatever sets one
wants
On 03/05/20(Sun) 14:14, Martin Pieuchot wrote:
> Diff below should fix the following panic exposed by syzkaller [0]:
>
> panic+0x15c sys/kern/subr_prf.c:207
> m_copydata+0x17e m_getptr sys/kern/uipc_mbuf.c:1031 [inline]
> m_copydata+0x17e sys/kern/uipc_mbuf.c:722
> ip6_pullexthdr+0x16f sys
Diff below should fix the following panic exposed by syzkaller [0]:
panic+0x15c sys/kern/subr_prf.c:207
m_copydata+0x17e m_getptr sys/kern/uipc_mbuf.c:1031 [inline]
m_copydata+0x17e sys/kern/uipc_mbuf.c:722
ip6_pullexthdr+0x16f sys/netinet6/ip6_input.c:1149
ip6_savecontrol+0x373 sys/neti
On Sun, May 03, 2020 at 04:40:44AM +0200, Stéphane Aulery wrote:
>
> a) Removing sets selection from the installer
> b) Supporting an upgrade of the sets already installed.
>
The FAQ already describes exactly how to upgrade with whatever sets one
wants to. I have used that method many, many time
I know Theo, Tobias told me a few mails back. I was joking...
On Sat, May 02, 2020 at 07:32:43AM -0600, Theo de Raadt wrote:
> Stephan Mending wrote:
>
> > On 02/05/2020 02:58, Theo de Raadt wrote:
> >
> > > Stephan Mending wrote:
> > >
> > >> I don't get how this could be ?
> > > then go stu
25 matches
Mail list logo
