On Mon, Apr 21, 2014 at 04:43, Dirk Engling wrote:
On 21.04.14 01:13, Bob Beck wrote:
this list is for diffs. post them. keep them reviewable - of
meaningful size and doing a certain thing.
(as opposed to this diff changes 15 things.. )
Find attached my patches for some memory leaks,
On Tue, Apr 22, 2014 at 18:28, Fritjof Bornebusch wrote:
Hi tech,
it's Trojan horse not Trojan horsed, right?
Fritjof
Index: security.8
===
RCS file: /cvs/src/share/man/man8/security.8,v
retrieving revision 1.23
diff -u
On Tue, Apr 22, 2014 at 15:49, pe...@petermalone.org wrote:
Hi,
Another malloc memset to calloc cleanup. This time in mountd.c
Can you be careful about whitespace? Your diffs have spaces instead of
tabs and don't apply.
The ones you've sent I can hand apply, but for future diffs please
work
On Mon, Apr 21, 2014 at 05:37, Dirk Engling wrote:
On 21.04.14 04:56, Ted Unangst wrote:
Also, can you include diffs inline please? One diff per email. Maybe
just one or two emails to start, then try sending the rest after we
see how that goes?
fix double free in d2i_ASN1_bytes by setting
On Mon, Apr 14, 2014 at 12:12, Otto Moerbeek wrote:
On Sun, Apr 13, 2014 at 06:34:17PM -0400, Ted Unangst wrote:
I took another look at the way junk works in malloc, and there's a few
improvements I'd like to make.
I have't been able to build perl reliably with this diff, but haven't
ruled
On Wed, Apr 23, 2014 at 09:05, Michael W. Bombardieri wrote:
CRYPTO_memcmp() is different to memcmp() because it can only check
for equality, not greater-than/less-than.
If we check the string in reverse order we can remove a variable
from the comparison loop.
Does this look ok?
Almost,
On Thu, Apr 24, 2014 at 00:21, Ian Mcwilliam wrote:
(cd /usr/src/lib/libcrypto/crypto/../../libssl/src/crypto/ ;
/usr/bin/perl ./x86_64cpuid.pl) x86_64cpuid.S
syntax error at ./x86_64cpuid.pl line 198, near print
Execution of ./x86_64cpuid.pl aborted due to compilation errors.
*** Error 255
On Wed, Apr 23, 2014 at 21:24, Peter Malone wrote:
Hi,
Similar to previous patches replacing malloc memset with calloc, this
time in src/bin/systrace/intercept.c
- tlnew = malloc(sizeof(struct intercept_translate));
+ tlnew = calloc(1, sizeof(struct intercept_translate));
On Wed, Apr 23, 2014 at 21:15, Peter Malone wrote:
Similar to previous patches replacing malloc memset with calloc. This
time in src/bin/cp/utils.c
Damn, I wrote this code. Thanks.
Please let me know if this doesn't paste correctly this time. I suspect
it's ok now. If not, I may just cry.
On Wed, Apr 23, 2014 at 21:38, Peter Malone wrote:
Hi,
Similar to the others. malloc memset replacement with calloc, this time
in sbin/nfsd/nfsd.c
fd_size = howmany(maxsock + 1, NFDBITS) * sizeof(fd_mask);
- sockbits = malloc(fd_size);
+ sockbits = calloc(1, fd_size);
On Thu, Apr 24, 2014 at 19:27, Peter Malone wrote:
The more I think about this. if we want to continue the select()
NULL functionality then timeout should be a negative value for poll(),
as NULL is unrecognized and zero is a zero-length timeout.
The standard way to effect no timeout for
On Sat, Apr 26, 2014 at 14:20, Héctor Luis Gimbatti wrote:
The patch removes the unreasonable use of blank lines.
If its automatically generated then the patch is useless.
About the choices of the software, yes
$HOME/.xinitrc is used IF it exists.
Shouldnt then be the right choice to let
Hi there. I'm trying to find somebody who is actually using either
Kerberos or SRP support in libssl. I'm inclined to remove support for
them. While the bulk of the code sits off to the side, the integration
requires adding several additional cases to some of the most critical
paths.
For
On Tue, Apr 29, 2014 at 08:57, Simon Perreault wrote:
Le 2014-04-28 18:43, Kenneth Westerback a écrit :
Why is the burden on everyone to provide 'valid' objections?
I know that what I proposed cannot go in at the moment. It's my end
goal. Now what I want is to have a clear picture of what
On Tue, Apr 29, 2014 at 10:04, Simon Perreault wrote:
- Run both requests in parallel.
- When one response is received, start a short timer (e.g. 200ms or so).
- If the second response is received before the timer expires, sort and
return the results as usual.
- Otherwise, kill the second
This changes getrnibble in malloc to getrbyte() for more potential
randomness.
The delayed chunk array can (should) be larger, but requires more than
a nibble of random to span it. Not changed yet, but with this diff it
can grow (or even shrink) in the future.
The bit offset in malloc_bytes
On Tue, Apr 29, 2014 at 10:18, Simon Perreault wrote:
Le 2014-04-29 10:12, Ted Unangst a écrit :
- Run both requests in parallel.
- When one response is received, start a short timer (e.g. 200ms or so).
- If the second response is received before the timer expires, sort and
return the results
Clean up a few things.
1. Drop support for no minor. This variant doesn't exist anymore.
2. Pull up the actual minor processing code into the switch that
parses it.
3. atoi is actually simpler than strtonum in this case, but check the
input beforehand so we don't get unexpected results.
4.
What's better than a freelist? Four freelists!
For each chunk size, pick one of four freelists at random. This
scatters allocations about some more and eliminates the guarantee that
consecutive allocations will always be on the same page.
Technically, there is no bound to how much memory will be
On Thu, May 01, 2014 at 15:57, Damien Miller wrote:
On Thu, 1 May 2014, Ted Unangst wrote:
What's better than a freelist? Four freelists!
Apart from moar = better, what's the motivation? Do you have a particular
attack in mind? The only thing I can think of where this change might help
Starting today, we're going to try sending patches out via email
so you don't miss them.
Several previous errata have also been recently published for OpenBSD
5.4 and 5.5. We won't be mailing them out individually since they
aren't new, but you should check the web site for details.
Refer to
On Thu, May 01, 2014 at 20:52, Marc Espie wrote:
Sorry, badly phrased reply. I didn't mean to imply it was a bad idea, but
you didn't explain at all why 4, and not 3 or 6, or 42 ? If it's good with
4, it ought to be better with more, right ? any data point or rationale for
choosing 4 ?
The
On Fri, May 02, 2014 at 15:17, enh wrote:
ideally i'd like to have no differences between Android and OpenBSD in
the shared source files, because i've seen what a mess things were
when we diverged (and how many bugs went unfixed in Android despite
having been fixed for years upstream). so
A little background. Before we issue errata, we have to decide whether
we should. That's usually pretty simple, but sometimes a bug looks
exploitable when it isn't, or is exploitable when it looks benign.
Clearly issuing zero errata isn't a workable solution, so we could issue
errata for
On Tue, May 06, 2014 at 08:36, Philip Guenther wrote:
As the person who broke this (sorry!), I think the diff should go a couple
steps further and restore the IN_ACCESS handling too and mirror
ufs_itimes() by bumping i_modrev on ctime change.
As my commit message said, it may even work. I
Don't rely on unchecked arithmetic.
Index: options.c
===
RCS file: /cvs/src/bin/pax/options.c,v
retrieving revision 1.84
diff -u -p -r1.84 options.c
--- options.c 6 Feb 2014 20:51:55 - 1.84
+++ options.c 6 May 2014
On Tue, May 06, 2014 at 21:20, Peter Malone wrote:
*/
- if ((selected = malloc(nproc)) == NULL)
+ if ((selected = calloc(1, nproc)) == NULL)
errx(STATUS_ERROR, memory allocation failure);
selected is an array of nproc chars, so I made it calloc(nproc, 1).
really,
This is wrong in several ways.
Never cast sizeof down, always cast the comparison variable up.
I'll specifically call out this change:
- if (snprintf(buf, sizeof(buf)) = (int)sizeof(buf))
+ if ((size_t)snprintf(buf, sizeof(buf)) = sizeof(buf))
The top way fails when snprintf
On Thu, May 08, 2014 at 18:43, Alexandre Ratchov wrote:
On Thu, May 08, 2014 at 12:35:56PM -0400, Ted Unangst wrote:
This is wrong in several ways.
Never cast sizeof down, always cast the comparison variable up.
I'll specifically call out this change:
-if (snprintf(buf, sizeof(buf
On Thu, May 08, 2014 at 22:39, Theo de Raadt wrote:
Your diff does not solve a problem.
Specifically, I don't think it's worth changing such code back or
forth either way, but using an extra variable to store the return value
from a function can make debugging easier. I may want to look at the
On Fri, May 09, 2014 at 18:50, Fritjof Bornebusch wrote:
But if you like OpenRCS as it is and don't want to get any diffs unless
security fixes, then just say it.
Or if you work on other stuff and you don't have time for that, then just
say it.
Personally, I don't much like to see diffs
As I learned the hard way not long ago, free() doesn't detect all
errors because of the delay mechanism. We can make two improvements.
1. Perform the sanity checking from free_bytes before we insert
something into the delay array. This detects many kinds of badness
much sooner.
2. Check that the
On Thu, May 15, 2014 at 00:14, Alexander Bluhm wrote:
On Wed, May 14, 2014 at 11:29:20PM +0200, Henning Brauer wrote:
so as discussed recently having the inet6 link-local addrs on every
interface by default is stupid and a security risk.
Connecting a computer to the internet is a security
Should be a straigtforward conversion.
Index: stack.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/stack/stack.c,v
retrieving revision 1.10
diff -u -p -r1.10 stack.c
--- stack.c 20 Apr 2014 13:54:10 - 1.10
+++ stack.c
sunos doesn't have memmove? I guess sunos won't have libressl.
Index: stack.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/stack/stack.c,v
retrieving revision 1.11
diff -u -p -r1.11 stack.c
--- stack.c 17 May 2014 17:35:04 -
On Sat, May 17, 2014 at 11:00, enh wrote:
inet_ntop4 incorrectly mixes a user-supplied size with a self-supplied
buffer:
inet_ntop4(const u_char *src, char *dst, size_t size)
...
char tmp[sizeof 255.255.255.255];
...
l = snprintf(tmp, size, fmt, src[0], src[1], src[2], src[3]);
On Sun, May 18, 2014 at 20:16, Helg wrote:
This patch forces fuse to mount a client filesystem using the realpath
when a relative path is specified for the mount point. Without this, to
unmount a filesystem you need to change directory to the same folder
you where in when you mounted it.
On Fri, May 23, 2014 at 11:16, ianmc...@tpg.com.au wrote:
Anybody else seeing this?
cc -c -O2 -pipe -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g -
DNGX_ENABLE_SYSLOG -DHAVE_CONFIG_H -DPCRE_STATIC
-DPOSIX_MALLOC_THRESHOLD=10 -I
src/core -I src/event -I src/event/modules
From http://www.openbsd.org/errata55.html:
X Font Service Protocol Font metadata file handling issues in libXfont
CVE-2014-0209: integer overflow of allocations in font metadata file parsing
CVE-2014-0210: unvalidated length fields when parsing xfs protocol replies
CVE-2014-0211:
On Sun, May 25, 2014 at 08:34, Benjamin Baier wrote:
Hi tech@
I'm just geting into the OpenBSD source code, and what better way to
learn than with real work...
Some malloc/memset to calloc changes. More to come if this kind of work
is appreciated.
Yes, but can you split future changes
On Sun, May 25, 2014 at 20:58, Benjamin Baier wrote:
Index: bn_blind.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/bn/bn_blind.c,v
retrieving revision 1.9
diff -u -p -r1.9 bn_blind.c
--- bn_blind.c8 May 2014 13:20:49
On Mon, May 26, 2014 at 21:44, Benjamin Baier wrote:
Yes, there is a xcalloc in xmalloc.h/.c.
Thanks, I think I got them all.
On Thu, May 29, 2014 at 21:00, Alexander Schrijver wrote:
I'm not sure how much, and if this breaks anything in Ports.
According to github it isn't used much.
We're going to keep this for a while. We would like to keep as much
API compatibility as possible, even when the API is mostly
On Thu, May 29, 2014 at 03:12, strake...@gmail.com wrote:
I have been writing a 9p vfs interface. Ultimately I hope to have this in
stock OpenBSD. So far it's incomplete and experimental and often faulty; I
shall hack it further when I have time, but meanwhile I post the diff here
in case
On Fri, May 23, 2014 at 16:29, Brendan MacDonell wrote:
I think this can be extended to expressions, not just identifiers:
@@
expression x;
@@
-if (x) { free(x); }
+free(x);
This catches another 47 instances. A patch against CVS follows.
Thanks, applied.
There have been some rather important fixes to smtpd since 5.5
release. If you're using smtpd on 5.5, you probably want to apply them.
(My plan is to commit to stable eventually, but since it's very
important not to introduce regressions, I'm asking for a little help
testing the backport.)
++
On Sat, May 31, 2014 at 17:00, Cameron Stewart wrote:
- change memset before free to explicit_bzero
- change ordinary memset's to bzero
Actually, memset is preferred to bzero in the ordinary case.
Another good reason to make separate diffs for separate changes. :)
On Mon, Jun 02, 2014 at 09:51, Brent Cook wrote:
Is something like this more to taste? Or maybe just a simple (void)write()
as in libc/time/zic.c ?
I think maybe we want to save this one for later. If it's not
immediately obvious what the correct fix is, move along to something
where the
On Sat, May 31, 2014 at 17:32, Brent Cook wrote:
ASN1_STRING_data returns an unsigned char *, but strlcat's second
parameter is a const char *
---
src/crypto/ts/ts_rsp_verify.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/crypto/ts/ts_rsp_verify.c
On Thu, May 08, 2014 at 22:17, Fritjof Bornebusch wrote:
Hi tech,
there is no way you can go, after usage() was called, so dont't do it.
I can't apply this because the whitespace is mangled.
On Mon, Jun 02, 2014 at 19:12, Joerg Sonnenberger wrote:
On Mon, Jun 02, 2014 at 12:33:14PM -0400, Ted Unangst wrote:
What compiler warns about this? It's perfectly fine to pass a nonconst
string to a function that takes a const string.
char * vs unsigned char *?
Oh, I guess. My feeling
On Wed, Jun 04, 2014 at 18:17, Florian Zumbiehl wrote:
Hi all,
may I draw your attention to this (my) ticket in the OpenSSL bug tracker?
http://rt.openssl.org/Ticket/Display.html?id=3226user=guestpass=guest
The patch adds various error checks and fixes an undefined return value in
case
Please note that we're having an issue with cvsync and some of the
mirrors at this time, so cvs up -rOPENBSD_5_5 may not be a reliable
way to update. Sorry about that. Please use the patches on ftp.
OpenBSD 5.4 is also affected.
untrusted comment: signature from openbsd 5.5 base secret key
Please note that we're having an issue with cvsync and some of the
mirrors at this time, so cvs up -rOPENBSD_5_5 may not be a reliable
way to update. Sorry about that. Please use the patches on ftp.
There is also a patch available for 5.4.
untrusted comment: signature from openbsd 5.5 base
On Mon, Jun 09, 2014 at 20:12, John-Mark Gurney wrote:
A better patch is probably the following which also increases the size
of the buffer to at least 64k:
Agreed.
On Mon, Jun 09, 2014 at 21:54, Theo de Raadt wrote:
A better patch is probably the following which also increases the size
of the buffer to at least 64k:
Agreed.
One thing to be aware of. That function is syncronous. It will read
as much as it can get, then it will do an atomic write
On Thu, Jun 12, 2014 at 21:30, Christian Weisgerber wrote:
New diff.
* Move all off_t variables that don't look like file sizes to
int64_t.
* Switch blockswritten to int64_t, so it won't wrap at 2TB.
* Same for blocksthisvol (deraadt@).
* Switch xferrate (tedu@) and blocksperfile from long
On Fri, Jun 13, 2014 at 10:40, sven falempin wrote:
Now soliciting diffs to change readwrite to a loop with two buffers
that poll()s in all four directions. :)
Is using kqueue ok ?
like : http://pastebin.com/F1c5Hswi
uh, maybe. the kqueue changes make it harder to review at first, but
Recently, i386 (but specifically not amd64) machines have been
observed to hang in kmthread. Probably caused (exposed) by an earlier
change to add preemption in a few places. The diff below is believed
to at least partially address the problem by having kmthread wait at
least one time through,
On Sun, Jun 15, 2014 at 23:55, Cyril Jouve wrote:
Hello,
in aes_gcm_cleanup after rev 1.21,
gctx is zero-ed before trying to free gctx-iv.
yup. thanks.
On error, set error code.
Check malloc return and cleanup.
On error, set error code and unlock.
Index: by_dir.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/x509/by_dir.c,v
retrieving revision 1.26
diff -u -p -r1.26 by_dir.c
---
A tiny patch for a giant function. This kind of looks right, based on
some other examples in the function, but it's hard to say for sure
since this one function (X509_verify_cert; is that important?) has
about a dozen different exit points which free or don't free any
number of variables, stacks,
Always explicitly compare memcmp with 0. I find this adds clarity.
Index: s3_clnt.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/s3_clnt.c,v
retrieving revision 1.71
diff -u -p -r1.71 s3_clnt.c
--- s3_clnt.c 19 Jun 2014 21:29:51 -
On Fri, Jun 20, 2014 at 13:53, Damien Miller wrote:
On Thu, 19 Jun 2014, Ted Unangst wrote:
Always explicitly compare memcmp with 0. I find this adds clarity.
If you don't care which way a different comparison points, then why
not use bcmp?
There are a couple points here.
1. we have
On Sun, Jun 22, 2014 at 17:39, Ingo Schwarze wrote:
Hi Jan,
i don't like this particular patch.
It's obvious that whole page needs a content update by a VAX expert.
Quibbling over formatting details is not going to fix it. Having
old-fashioned formatting actually makes it even more
On Fri, Jun 13, 2014 at 07:50, sven falempin wrote:
Now soliciting diffs to change readwrite to a loop with two buffers
that poll()s in all four directions. :)
Is using kqueue ok ?
Sorry. Returning to this point in the thread, I agree with Theo the
answer is no. People are running this code
On Thu, Jun 26, 2014 at 08:33, sven falempin wrote:
For a review i dislike
+ unsigned char stdinbuf[BUFSIZE];
and the memmove on it:
Dear tech savvy, isn it better to malloc a buffer like this instead of
alloca it ?
or just a static buffer would be better so it is in the program mem
On Thu, Jun 26, 2014 at 11:12, sven falempin wrote:
What is a 'good maximum' size for a buffer like this in amd64 world and
arm ?
From which amount should we consider to not use the stack. (I know it
depends the type of function,
but lets focus on this case )
Stack rlimit is 4096K, so
On Wed, Jul 02, 2014 at 12:37, Otto Moerbeek wrote:
On Tue, Jul 01, 2014 at 03:56:39PM -0400, Jared Yanovich wrote:
On Mon, Jun 30, 2014 at 11:53:04AM +0200, Otto Moerbeek wrote:
This indeed solves some problems, but I have a test file on which it
cores.
Patch relative to the original
On Mon, Jul 07, 2014 at 11:18, Matthew Dempsky wrote:
Recently guenther changed user credentials to be a per-process
resource, but kept a per-thread cache of credentials that get
refreshed at each system call entry. All of the get*[ug]id() system
calls simply access the thread cached
On Thu, Jun 26, 2014 at 13:43, Arne Becker wrote:
Hi.
Now soliciting diffs to change readwrite to a loop with two buffers
that poll()s in all four directions. :)
Good thing you made me remember I wrote just this a while ago.
This is my first OpenBSD diff, so tell me if I missed anything
On Mon, Jun 30, 2014 at 21:26, Tobias Stoeckmann wrote:
Hi,
this diff merges NetBSD's revision 1.20 into our tree: There are
some memory leaks in resetDosDirSection.
This is not a simple merge, I have added some things:
- rootDir was not properly freed in NetBSD's commit
(actually
how would you like your deadbeef? well done?
since we support variable poison values, we should invert the patterns
sometimes to find bugs where the deadbeef values hide the bugs. (we
can of course do even more with extra tricksy bit patterns, but start
with this.)
Index: subr_poison.c
On Wed, Jul 09, 2014 at 18:33, Arne Becker wrote:
atelnet uses atomicio, which depends on blocking sockets. Since we call
atelnet from readwrite, the sockets are likely non-blocking.
If we enter the for()-loop in atelnet, we set the sockets to blocking
and remember that, so we do it only once.
just like libc free(), asn1_string_free can cope with null. so don't
bother with polluting the callers with such tests.
Index: asn1/a_bytes.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/a_bytes.c,v
retrieving revision 1.14
diff
No need to cast int args to memcpy.
Index: asn1/a_bitstr.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/a_bitstr.c,v
retrieving revision 1.17
diff -u -p -r1.17 a_bitstr.c
--- asn1/a_bitstr.c 12 Jun 2014 15:49:27 -
. :)
-- Forwarded message --
From: Ted Unangst t...@cvs.openbsd.org
Date: Thu 2014/07/10 06:55 -06:00
Subject: CVS: cvs.openbsd.org: src
To: source-chan...@cvs.openbsd.org
CVSROOT:/cvs
Module name:src
Changes by: t...@cvs.openbsd.org2014/07/10 06:55:14
Modified
On Thu, Jul 10, 2014 at 10:28, Matthew Dempsky wrote:
We've found a bunch of uses for reallocarray() in userland, and I
think the idiom is worth reusing in the kernel. There are enough
places where we do malloc(x * y) that I think it makes sense to add
mallocarray(x, y).
+void
On Thu, Jul 10, 2014 at 12:02, Matthew Dempsky wrote:
+ panic(overflow);
Print the sizes here and ok with me.
panic(reallocarray overflow: %zu * %zu, num, size);
I'm not really expecting tun to provide blistering performance, but
one of the things that keeps it slower than need be is the one packet
per read/write implementation. It'd be pretty cool to have
something like readv() or writev() provide the ability to operate on
multiple packets at once.
I question the extent to which this micro optimization really matters,
given that the code would eventually be compressed, but...
Make the code simpler by only having one copy, but outlining on small
kernels. This makes things even smaller. No change for normal kernels,
but small ones shrink from
On Fri, Jul 11, 2014 at 06:31, Doug Hogan wrote:
Csh has a section of code where it NUL terminates after a strlcpy().
Strlcpy() may read past what readlink() wrote since readlink() does
not append a NUL.
applied (and smtpd sock fix), thanks.
On Fri, Jul 11, 2014 at 09:56, Stuart Henderson wrote:
On 2014/07/11 18:51, Brett Mahar wrote:
On Fri, 11 Jul 2014 09:48:12 +0100
Stuart Henderson st...@openbsd.org wrote:
| On 2014/07/11 01:18, Theo de Raadt wrote:
| I too use gopher in lynx regularly, and would miss support. There
is =
I think the proposal rampaging went one algorithm too far. sha1 is the
best algorithm supported by many clients and it's still pretty secure.
without it, a lot of clients have stopped working. temporarily alieve
the pain?
Index: myproposal.h
We don't need to hold the malloc lock when making syscalls like mmap
and munmap if we're just a little careful about the order of
operations. This will allow other threads to concurrently allocate
perhaps smaller chunks while the first thread is in the kernel.
This makes a huge difference in a
On Fri, Jul 11, 2014 at 13:56, Otto Moerbeek wrote:
On Fri, Jul 11, 2014 at 06:28:04AM -0400, Ted Unangst wrote:
We don't need to hold the malloc lock when making syscalls like mmap
and munmap if we're just a little careful about the order of
operations. This will allow other threads
On Fri, Jul 11, 2014 at 14:09, Florian Obser wrote:
usr.sbin, make sure subdirs of subdirs see usr.sbin/Makefile.inc:
Does the same thing as lpr/pac and pppd/pppstats. I have no idea if
this is the right way, but it seems to work. Cluebats welcome.
I think maybe it would be nicer to create a
1. redundant null tests
2. http decode can be linear instead of (n^2) with two pointers.
Index: cgi.c
===
RCS file: /cvs/src/usr.bin/mandoc/cgi.c,v
retrieving revision 1.1
diff -u -p -r1.1 cgi.c
--- cgi.c 11 Jul 2014 15:37:22
Another diff. HTTP headers have to be separated by CRLF.
Index: cgi.c
===
RCS file: /cvs/src/usr.bin/mandoc/cgi.c,v
retrieving revision 1.1
diff -u -p -r1.1 cgi.c
--- cgi.c 11 Jul 2014 15:37:22 - 1.1
+++ cgi.c 11
On Sat, Jul 12, 2014 at 00:22, Piotr Sikora wrote:
Hey Bob,
It's already fixed, so will be on the next tarball roll
Thanks!
I should have been more clear in my previous email, but would it be possible
to also revert OPENSSL_VERSION_NUMBER back to 0x1000107fL (or 0x1000108fL)?
This way
On Sat, Jul 12, 2014 at 01:13, Hanno Böck wrote:
I didn't know what egd was up until today, but reading what it is I
completely understand that consideration. However, this breaks a number
of packages (wget, python, ruby).
Those packages would all be better off without egd support. In the
Thanks to the ever attentive eyes of mlarkin, who spotted some unused
code to print a battleship in battleship.
Diff below enables printing the battleship, changes the name to the
S.S. Puffy, and adds my attempt at a tiny ascii blowfish to the side.
OK?
Index: bs.c
As seen in FreeBSD ASLR, we can open things up on 64-bit platforms.
effects:
alpha: limit to 1GB (maxdsiz/brksiz)
amd64 and sparc64: limit to 4gb (8gb maxdsiz)
Index: uvm_map.c
===
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving
On Sat, Jul 12, 2014 at 10:43, Hanno Böck wrote:
On Sat, 12 Jul 2014 10:29:31 +0200
Philip Guenther guent...@gmail.com wrote:
On Sat, Jul 12, 2014 at 10:20 AM, Hanno Böck ha...@hboeck.de wrote:
I had a number of compilation problems with packages when linking to
libressl that I could
On Fri, Jul 11, 2014 at 08:11, Ted Unangst wrote:
I also think there's one simple case that can be added: the MMAP call
at the bottom of map().
On further inspection, I think this needed a slight reordering to be
safe.
I have also been seeing random munmap errors running jruby:
java(3451
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
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]))
+
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
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
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:
1 - 100 of 1656 matches
Mail list logo
