Hi,
Bit of a programming question/inquiry...
I'm looking at 5.5-current. I'm forking inside a lib and I want to
change the forks cmd or argv[0]. I mean, what you see as "command" in ps
or top. I've looked at setproctitle. And I lurked around kvm_getprocs
and kvm_getargv, but these functions o
On Jul 13, 2014, at 5:45 PM, Jan Engelhardt wrote:
> On Sunday 2014-07-13 17:36, Brent Cook wrote:
This release includes a number of portability fixes based on the
initial feedback we have received from the community.
>>>
>>> I was looking at Solaris documentation and found tha
> On Sun, Jul 13, 2014 at 17:52, Theo de Raadt wrote:
> >> And some others from exec that follow a slightly different pattern.
> >
> > This is the pattern I have been following as well.
> >
> > As for the final diff, I've been giving up on the "known constant"
> > scenario. It seems expensive.
>
On Sun, Jul 13, 2014 at 17:52, Theo de Raadt wrote:
>> And some others from exec that follow a slightly different pattern.
>
> This is the pattern I have been following as well.
>
> As for the final diff, I've been giving up on the "known constant"
> scenario. It seems expensive.
Meh. :) I thin
> And some others from exec that follow a slightly different pattern.
This is the pattern I have been following as well.
As for the final diff, I've been giving up on the "known constant"
scenario. It seems expensive.
> Index: exec_script.c
>
On Sun, Jul 13, 2014 at 11:14, Ted Unangst wrote:
> sprinkle malloc array in the kern directory.
And some others from exec that follow a slightly different pattern.
Index: exec_elf.c
===
RCS file: /cvs/src/sys/kern/exec_elf.c,v
retri
It takes a void *, not a char *.
Index: getentropy.2
===
RCS file: /cvs/src/lib/libc/sys/getentropy.2,v
retrieving revision 1.4
diff -u -p -r1.4 getentropy.2
--- getentropy.215 Jun 2014 07:24:19 - 1.4
+++ getentropy.2
> > Index: kern_sched.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_sched.c,v
> > retrieving revision 1.32
> > diff -u -p -r1.32 kern_sched.c
> > --- kern_sched.c4 May 2014 05:03:26 - 1.32
> > +++ kern_sched.c13 Jul
Hello,
I am playing with 86duino EduCake, and I found pciide(4) did not support DMA
of Vortex86EX SoC (RDC R1012).
I tried to port NetBSD's rdcide(4) and it seems to work.
Here is the diff, and please tell me how to test more verbose.
At least there is no problem to build -current kernel, but po
> Date: Sun, 13 Jul 2014 13:12:46 -0700
> From: Matthew Dempsky
>
> As the name suggests, remrunqueue(p) removes p from its run queue, and
> I believe that makes TAILQ_FOREACH() here unsafe. Instead of actually
> removing all threads from the processor, we'll only remove the first
> from each of
As the name suggests, remrunqueue(p) removes p from its run queue, and
I believe that makes TAILQ_FOREACH() here unsafe. Instead of actually
removing all threads from the processor, we'll only remove the first
from each of its run queues.
Diff below replaces TAILQ_FOREACH with the safe/idiomatic
On 13/07/14 4:22 PM, frantisek holop wrote:
hmm, on Sun, Jul 13, 2014 at 02:21:06PM -0400, Brad Smith said that
On 13/07/14 2:16 PM, frantisek holop wrote:
hmm, on Sun, Jul 13, 2014 at 05:37:51PM +0200, Denis Fondras said that
>from the user's PoV, there shouldn't be more needed than
ifc
hmm, on Sun, Jul 13, 2014 at 02:21:06PM -0400, Brad Smith said that
> On 13/07/14 2:16 PM, frantisek holop wrote:
> >hmm, on Sun, Jul 13, 2014 at 05:37:51PM +0200, Denis Fondras said that
> >>>
> >>>from the user's PoV, there shouldn't be more needed than
> >>> ifconfig inet autoconf
> >>> ifc
Updated for mallocarray() and free(size).
On Thu, Jul 10, 2014 at 04:13:38PM -0400, Jean-Philippe Ouellet wrote:
> This diff adds another struct between filedesc and file to store
> process-local per-descriptor information. Currently, the only thing in
> this struct is the file pointer and some fl
On Sun, Jul 13, 2014 at 11:29:22AM -0600, dera...@cvs.openbsd.org wrote:
> This is the first pass of mallocarray() in sys/dev. Please proofread.
[...]
> ===
> RCS file: /cvs/src/sys/dev/softraid.c,v
> retrieving revision 1.334
> diff
> > Index: ic/malo.c
> > - ring->data = malloc(count * sizeof (struct malo_rx_data), M_DEVBUF,
> > - M_NOWAIT);
> > + ring->data = mallocarray(count, sizeof (struct malo_rx_data),
> > + M_DEVBUF, M_NOWAIT);
>
> Might as well s/sizeof (/sizeof(/ while you're here.
And fix the inter
And some cosmetic things:
> Index: ic/malo.c
> - ring->data = malloc(count * sizeof (struct malo_rx_data), M_DEVBUF,
> - M_NOWAIT);
> + ring->data = mallocarray(count, sizeof (struct malo_rx_data),
> + M_DEVBUF, M_NOWAIT);
Might as well s/sizeof (/sizeof(/ while you're her
On Sunday 2014-07-13 13:07, Bob Beck wrote:
>We have released an update, LibreSSL 2.0.1
>As noted before, we welcome feedback from the broader community.
Something that I have noticed is that the shared libraries generated
by the portable libressl tarball are installed to their final
location (i
On 13/07/14 2:16 PM, frantisek holop wrote:
hmm, on Sun, Jul 13, 2014 at 05:37:51PM +0200, Denis Fondras said that
from the user's PoV, there shouldn't be more needed than
ifconfig inet autoconf
ifconfig inet6 autoconf
aka inet/inet6 autoconf in hostname.if.
I'm curious to see what w
hmm, on Sun, Jul 13, 2014 at 05:37:51PM +0200, Denis Fondras said that
> >
> > from the user's PoV, there shouldn't be more needed than
> > ifconfig inet autoconf
> > ifconfig inet6 autoconf
> > aka inet/inet6 autoconf in hostname.if.
> >
>
> I'm curious to see what will come out of it as
On Sun, Jul 13, 2014 at 11:29:22AM -0600, dera...@cvs.openbsd.org wrote:
> - ldp = malloc(sizeof(*ldp) + (k-1), M_DEVBUF, M_NOWAIT);
> + ldp = mallocarray(k-1, sizeof(*ldp), M_DEVBUF, M_NOWAIT);
Are you sure k-1 can never be small enough such that a*b is less than a+b?
This is the first pass of mallocarray() in sys/dev. Please proofread.
Index: rd.c
===
RCS file: /cvs/src/sys/dev/rd.c,v
retrieving revision 1.7
diff -u -p -u -r1.7 rd.c
--- rd.c12 Jul 2014 18:48:51 - 1.7
+++ rd.c
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() & 0x7fff;
>
> return arc4random()
I would like this.
On Sun, Jul 13, 2014 at 8:06 AM, Ted Unangst wrote:
> for reference, i use this. faster query interval and when not idle, slam
> high immediately.
>
> Index: apmd.c
> ===
> RCS file: /cvs/src/usr.sbin/apmd/apmd.c,v
On Sunday 2014-07-13 17:36, Brent Cook wrote:
>>>
>>> This release includes a number of portability fixes based on the
>>> initial feedback we have received from the community.
>>
>> I was looking at Solaris documentation and found that -lrt may be
>> needed for some versions as well. A test ha
>
> from the user's PoV, there shouldn't be more needed than
> ifconfig inet autoconf
> ifconfig inet6 autoconf
> aka inet/inet6 autoconf in hostname.if.
>
I'm curious to see what will come out of it as I cannot envision any
added value of these autoconf compared to dhclient.
Denis
On Jul 13, 2014, at 4:36 PM, Jan Engelhardt wrote:
> On Sunday 2014-07-13 13:07, Bob Beck wrote:
>>
>> This release includes a number of portability fixes based on the
>> initial feedback
>> we have received from the community.
>
>
> I was looking at Solaris documentation and found that -lrt m
sprinkle malloc array in the kern directory.
Index: exec_subr.c
===
RCS file: /cvs/src/sys/kern/exec_subr.c,v
retrieving revision 1.36
diff -u -p -r1.36 exec_subr.c
--- exec_subr.c 12 Jul 2014 18:43:32 - 1.36
+++ exec_subr.c
Stop using n_long and remove ?
ok?
Index: lib/libsa/arp.c
===
RCS file: /cvs/src/sys/lib/libsa/arp.c,v
retrieving revision 1.11
diff -u -p -r1.11 arp.c
--- lib/libsa/arp.c 11 Aug 2003 06:23:09 - 1.11
+++ lib/libsa/arp.c
before I forget half of what we talked about here and to share it,
here's how I think the network autoconfig stuff should work in the
future.
from the user's PoV, there shouldn't be more needed than
ifconfig inet autoconf
ifconfig inet6 autoconf
aka inet/inet6 autoconf in hostname.if.
for i
On Sunday 2014-07-13 13:07, Bob Beck wrote:
>
>This release includes a number of portability fixes based on the
>initial feedback
>we have received from the community.
I was looking at Solaris documentation and found that -lrt may be needed
for some versions as well. A test has not been conducte
for reference, i use this. faster query interval and when not idle, slam
high immediately.
Index: apmd.c
===
RCS file: /cvs/src/usr.sbin/apmd/apmd.c,v
retrieving revision 1.63
diff -u -p -r1.63 apmd.c
--- apmd.c 13 Nov 2013 04:50
On 07/13/2014 03:42 PM, Brent Cook wrote:
> Hi Jean,
>
> We enabled more aggressive warnings in the 2.0.1 release from 2.0.0.
>
> Our team looked at these warnings before the release and, while we can
> potentially make them go away, they are harmless.
>
> - Brent
Hi Brent,
Cool, nothing to
Some people have reported that apmd -A makes their machines hang.
Could those people try the diff below and see whether it helps?
Index: acpicpu.c
===
RCS file: /home/cvs/src/sys/dev/acpi/acpicpu.c,v
retrieving revision 1.60
diff -u -
On Jul 13, 2014, at 3:58 PM, Ted Unangst wrote:
> If the user calls srandomdev(), they are asking for an unpredictable
> sequence, even one that could not normally be produced. So give them
> one. Use arc4random in that case.
>
>
> Index: stdlib/random.c
> =
If the user calls srandomdev(), they are asking for an unpredictable
sequence, even one that could not normally be produced. So give them
one. Use arc4random in that case.
Index: stdlib/random.c
===
RCS file: /cvs/src/lib/libc/stdlib
now that we have an uncontaminated, err, inet6-free system by default,
IFXF_NOINET6 just doesn't make sense any more.
fully go for no inet6 by default, get rid of the IFXF_NOINET6 guarded
attachments etc.
introduce IFAFATTACH and IFAFDETACH ioctls. note that they are NOT
inet6 specific; the kernel
On Jul 13, 2014, at 2:48 PM, Jean Paul Galea wrote:
> Hello,
>
> I compiled LibreSSL 2.0.1 on my Debian machine, and while doing so,
> noticed some compiler warnings.
>
> I'm not competent to understand what's going on, but perhaps someone
> here wants to pick this up.
>
> Thank you for the h
We have to support a seed, but if we don't start with one, use
arc4random() instead.
This also makes the linker warnings a little nicer and more localized:
update.o(.text+0xbfd): In function `setseed':
: warning: srandom() seed choices are invariably poor
update.o(.text+0x259): In function `addpla
Hello,
I compiled LibreSSL 2.0.1 on my Debian machine, and while doing so,
noticed some compiler warnings.
I'm not competent to understand what's going on, but perhaps someone
here wants to pick this up.
Thank you for the hard work your team is putting into this fork.
Jean Paul
jean@thinkpad:
Also starting with this release the directory includes SHA256
signatures which are signed using signify.
The signify public key for libressl is:
untrusted comment: LibreSSL Portable public key
RWQg/nutTVqCUVUw8OhyHt9n51IC8mdQRd1b93dOyVrwtIXmMI+dtGFe
On Sun, Jul 13, 2014 at 5:07 AM, Bob Beck wr
We have released an update, LibreSSL 2.0.1
This release includes a number of portability fixes based on the
initial feedback
we have received from the community. This includes among other things
two new configure options to set OPENSSLDIR and ENGINESDIR. We have
removed a few hardcoded compiler o
On Sun, Jul 13, 2014 at 02:58:04AM -0500, Shawn K. Quinn wrote:
| On Sun, 2014-07-13 at 01:38 -0600, Theo de Raadt wrote:
| > With your attitude, I beg you to please go run some other
| > operating system.
|
| The plan is when the first Bitrig release comes out, I'm done and switch
| to that. The
1. md5crypt isn't support anymore
2. if you want des passwords, go use vipw
I kept auto and blowfish instead of just hard coding blowfish because
there's some bits that allow fiddling with the salt. (that needs
improvement too, but not this diff)
Index: adduser.perl
==
Here is the latest diff with the bullshit removed and the loop replaced with
strchr.
Index: bin/dd/args.c
===
RCS file: /cvs/src/bin/dd/args.c,v
retrieving revision 1.25
diff -u -b -w -p -r1.25 args.c
--- bin/dd/args.c 21 May
Sorry, the libssl patch was unintentional. I forgot to cvs up -C that one.
On 7/13/2014 2:05 AM, Ted Unangst wrote:
On Sun, Jul 13, 2014 at 01:52, William Orr wrote:
Hey,
I sent a patch similar to this almost a month ago with no response.
Feedback? Interest?
Yes.
- num = strtoul(val,
On Sun, Jul 13, 2014 at 01:52, William Orr wrote:
> Hey,
>
> I sent a patch similar to this almost a month ago with no response.
>
> Feedback? Interest?
Yes.
>
> - num = strtoul(val, &expr, 0);
> - if (num == SIZE_T_MAX) /* Overflow. */
> + while (isspace(vp[0]))
>
On Sun, 2014-07-13 at 02:23 -0600, Theo de Raadt wrote:
> You demand us to do work?
>
> Please leave immediately.
No, I'm asking why there's been no exploit, not necessarily for you to
write one. In fact, Theo, I'd really rather you not try to write one,
since apparently you're averse to the idea
Hey,
I sent a patch similar to this almost a month ago with no response.
Feedback? Interest?
This patch fixes the following:
- Takes negative values
- When SIZE_T_MAX was passed, returns undefined error
Index: bin/dd/args.c
===
RC
On Sat, Jul 12, 2014 at 21:43, Shawn K. Quinn wrote:
> For now, I'm going to make sure my Lynx still has full functionality if
> I have to manually unfuck the Makefile myself everytime after I update
> my sources. In the future? Maybe I (and the other users who actually
> give a shit about having
You demand us to do work?
Please leave immediately.
> On Sun, 2014-07-13 at 02:01 -0600, Theo de Raadt wrote:
> > Why haven't you left yet Shawn?
>
> Because for the moment, I still am an OpenBSD user. And you haven't
> answered my question why there's been no exploit of this "poor quality"
> c
On Sun, 2014-07-13 at 02:01 -0600, Theo de Raadt wrote:
> Why haven't you left yet Shawn?
Because for the moment, I still am an OpenBSD user. And you haven't
answered my question why there's been no exploit of this "poor quality"
code (in the entire history of Lynx going back to 1992, no less).
I
Here's an updated version of a diff I sent some months ago.
It removes the dependency on for the network
headers by substituting n_time, n_long and n_short by their equivalent
u_int_* types.
This will allows to stop including in all the
files pulling or . Here's what I
said in my previous mai
Why haven't you left yet Shawn?
On Sun, Jul 13, 2014 at 02:26:10AM -0500, Shawn K. Quinn wrote:
> On Sat, 2014-07-12 at 23:58 -0700, William Orr wrote:
> > wrt. auditing it, should we send patches here? Or upstream?
>
> I'd send them both places, if they apply cleanly to both sets of code.
> Otherwise, send them here. I'd love
On Sun, 2014-07-13 at 01:38 -0600, Theo de Raadt wrote:
> With your attitude, I beg you to please go run some other
> operating system.
The plan is when the first Bitrig release comes out, I'm done and switch
to that. The donations I was going to make to your project later this
year? Not anymore.
Why haven't you left?
Please leave.
> On Sat, 2014-07-12 at 23:58 -0700, William Orr wrote:
> > wrt. auditing it, should we send patches here? Or upstream?
>
> I'd send them both places, if they apply cleanly to both sets of code.
> Otherwise, send them here. I'd love to be proven wrong about th
On Sat, 2014-07-12 at 23:58 -0700, William Orr wrote:
> wrt. auditing it, should we send patches here? Or upstream?
I'd send them both places, if they apply cleanly to both sets of code.
Otherwise, send them here. I'd love to be proven wrong about the
maintainers not really giving a shit about the
With your attitude, I beg you to please go run some other
operating system.
On 7/11/2014 2:03 AM, Theo de Raadt wrote:
If lynx was removed from base, and only available in ports... how many of
you would even know of it's existance and use it?
I absolutely would use it if it were only available in ports.
I only complain about gopher support being removed because lynx h
60 matches
Mail list logo
