On Tue, Oct 20, 2015 at 09:04:51PM +0100, Ricardo Mestre wrote:
> Let's give some pledge(2) love to hangman(6)!
>
> It seems to work fine for me with the patch mentioned below, nevertheless
> please be aware that I don't consider myself a developer, just a mere
> OpenBSD user with 'security uncle
On Sat, Oct 10, 2015 at 08:17:13AM +0200, Martijn van Duren wrote:
> I am however curious to this patch. By pledging ksh with exec it appears to
> me that once a pledged process is execve(2)d it looses it's already made
> pledges. (how else could applications spawned from the shell and still get
>
On Wed, Aug 26, 2015 at 09:15:13AM +0200, Sebastien Marie wrote:
> The following patch remove #ifdef OK_TO_WRITE_DISK which isn't used by
> default.
>
> Additionnally, few disambiguisations suggested by cc(1) are added:
> - parentheses around && within ||
> - explicit braces to avoid ambiguous
On Sat, Aug 01, 2015 at 07:31:58PM +0100, Mark Latimer wrote:
> reading through the compiler warnings I believe there is a potential issue
> in /usr/src/sys/kern/kern_ktrace.c At first glance it appears to free
> an uninitialized pointer memp.
I agree.
Index: sys/kern/kern_ktrace.c
=
We have received several emails asking if we are impacted by the
latest CVE-2015-1793. We are not impacted. The code related to that
CVE was added after we forked 1.0.1g and we did not merge these changes
from upstream. This CVE only concerns newer OpenSSL releases.
Patches are now available to fix a few issues in LibreSSL's libcrypto.
CVE-2015-1788 - Malformed ECParameters causes infinite loop
CVE-2015-1789 - Exploitable out-of-bounds read in X509_cmp_time
CVE-2015-1792 - CMS verify infinite loop with unknown hash function
Note that CMS was already disabled
We have two new lists for LibreSSL:
libre...@openbsd.org - public list for technical discussion about
LibreSSL on any operating system.
libressl-secur...@openbsd.org - private list for reporting severe
vulnerabilities in OpenSSL or LibreSSL to the core LibreSSL team.
See http://www.openbsd.org/
On Sun, Feb 15, 2015 at 08:53:08PM +, Miod Vallat wrote:
> This ought to fix this problem:
This looks reasonable but needs a tweak if you want to keep the existing
behavior. In the existing code, it has this section above the copyout():
rw_enter_write(&sc->sc_lock);
On Sat, Nov 01, 2014 at 03:07:24AM +0100, Jan Klemkow wrote:
> Index: tls_client.c
> ===
> RCS file: /cvs/src/lib/libtls/tls_client.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 tls_client.c
> --- tls_client.c 31 Oct 2014 13:46
On Thu, Sep 18, 2014 at 09:28:41AM +0100, bytevolc...@safe-mail.net wrote:
> Revised diffbelow:
You are inheriting some bugs in here by reusing newfs code. :)
I agree with the comments from others. Additional comments:
> #include
> +#include
...
> + args.ta_root_mode = modeset ? mode : s
On Fri, Sep 12, 2014 at 02:23:34PM -0600, Todd C. Miller wrote:
> No objection here. I'd go a step farther and nuke all the FOO_END
> macros as well. They add nothing and just make code harder to read.
In preparation for that, this replaces all _END macro calls.
Since we're not calling CIRCLEQ_*
On Thu, Sep 11, 2014 at 11:05:02PM -0500, Kent R. Spillner wrote:
> While reviewing tedu@'s libressl config cleanup diffs I noticed we're
> not explicitly freeing ressl_config in ftp(1).
...
> Index: fetch.c
> ===
...
> if (ssl !
On Sun, Aug 31, 2014 at 10:46:50PM +0200, Alexander Bluhm wrote:
> Move the handlers for the poll events into separate functions. They
> will become the libevent callbacks later.
...
> @@ -631,23 +606,65 @@ main(int argc, char *argv[])
>
> for (i = 0; i < nfunix; i++) {
>
On Tue, Jul 22, 2014 at 02:51:17AM -0400, Jean-Philippe Ouellet wrote:
> That is misleading in the M_CANFAIL case.
>
> I'm not terribly good at wording things, but I suggest something
> more like this instead:
Hmm I think it's only misleading in the M_CANFAIL case. I think this
diff makes it a l
BUF_MEM_free() only has one parameter and it returns immediately
if it is NULL.
Index: src/crypto/asn1/a_d2i_fp.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/a_d2i_fp.c,v
retrieving revision 1.11
diff -u -p -d -r1.11 a_d2i_fp.c
BIO_free() returns immediately when the sole input is NULL.
Index: lib/libssl/src/apps/apps.c
===
RCS file: /cvs/src/lib/libssl/src/apps/apps.c,v
retrieving revision 1.68
diff -u -p -d -r1.68 apps.c
--- lib/libssl/src/apps/apps.c 19
Use reallocarray() in a few places in sys.
Index: sys/arch/hppa/stand/mkboot/mkboot.c
===
RCS file: /cvs/src/sys/arch/hppa/stand/mkboot/mkboot.c,v
retrieving revision 1.18
diff -u -p -d -r1.18 mkboot.c
--- sys/arch/hppa/stand/mkboot/
Make it clear what check implies for mallocarray. Thanks to dlg@ for
pointing this behavior out.
Index: share/man/man9/malloc.9
===
RCS file: /cvs/src/share/man/man9/malloc.9,v
retrieving revision 1.56
diff -u -p -d -r1.56 malloc.9
On Sat, Jul 19, 2014 at 06:40:54PM -0700, Philip Guenther wrote:
> Nice job! Committed (except for the microcode/bwi file where your diff
> revealed another existing bug that we can fix at the same time...)
Thanks! Here's the patch with the existing bug fixed. I checked other
places for err/war
regress/sys/kern/extent is failing because of the userland definitions
in sys/kern/subr_extent.c.
Even though subr_extent.c includes sys/pool.h, the struct pool definition
is guarded for _KERNEL and _LIBKVM. I added a simple struct pool
definition that meets the needs of the dummy pool_* function
Strings changed in the warning message.
Index: regress/gnu/egcs/gcc-builtins/stpcpy-1.c.exp
===
RCS file: /cvs/src/regress/gnu/egcs/gcc-builtins/stpcpy-1.c.exp,v
retrieving revision 1.2
diff -u -p -d -r1.2 stpcpy-1.c.exp
--- regress/
On Sat, Jul 19, 2014 at 06:55:02PM +, Miod Vallat wrote:
> What flags were you using? As its name implies, this test causes a lot
> of memory to be allocated, so malloc flags such as F and G will take a
> toll...
I was using G since I had S enabled.
> > I think that was the cause of the kqueu
On Sat, Jul 19, 2014 at 06:59:14PM +, Miod Vallat wrote:
> Ah, I see; you're running `make regress' ; simply running `make' should
> work correctly (it implies building, and the running the regress target,
> when Makefile includes ).
That would fix it for the local case inside of /usr/src/regr
On Sat, Jul 19, 2014 at 06:16:56PM +, Miod Vallat wrote:
> > Added t-exhaust as slow because it takes > 90 minutes on my recent CPU.
>
> That's odd. This test only takes a few seconds on an amd64 system. Do
> you have any local changes to libc, or any particular /etc/malloc.conf
> settings, wh
On Sat, Jul 19, 2014 at 06:03:18PM +, Miod Vallat wrote:
> They do; the magic to build libaa comes from
> regress/libexec/ld.so/randomdata/Makefile.inc .
>
> There are no regress tests to run in the libaa directory itself, but it
> needs to be in SUBDIR to get the obj directory and symlink cre
REGRESS_SKIP_SLOW didn't work as intended. Default is no yet it checks
for !empty.
Added t-exhaust as slow because it takes > 90 minutes on my recent CPU.
Index: regress/lib/libc/regex/Makefile
===
RCS file: /cvs/src/regress/lib/li
Index: regress/sys/kern/rcvtimeo/rcvtimeo.c
===
RCS file: /cvs/src/regress/sys/kern/rcvtimeo/rcvtimeo.c,v
retrieving revision 1.4
diff -u -p -r1.4 rcvtimeo.c
--- regress/sys/kern/rcvtimeo/rcvtimeo.c2 Sep 2003 23:52:17 -
Initfirst needs the same fix as randomdata.
Index: regress/libexec/ld.so/initfirst/test2/libaa/Makefile
===
RCS file: /cvs/src/regress/libexec/ld.so/initfirst/test2/libaa/Makefile,v
retrieving revision 1.1
diff -u -p -d -r1.1 Makefil
The regression tests under randomdata do not work. They must build
libaa before running. libaa doesn't have a target for regress so
even though it's a SUBDIR in ../Makefile, it doesn't do anything.
Index: regress/libexec/ld.so/randomdata/libaa/Makefile
==
On Sat, Jul 19, 2014 at 12:28:17PM +0100, Stuart Henderson wrote:
> Personally I remember a few nearby mirror URLs, but I do think this could
> be improved - we could add a sample pkg.conf file to /etc/examples with
> a list of mirrors updated from mirrors.dat. Unless there are objections to
> that
Ran into this while running the regression suite for another patch.
The regression test for open_memstream causes a SIGBUS because it closes
the stream too early.
Replaced fclose with fflush since they both update pbuf and psize.
Added a similar check for fclose at the end.
Index: regress/lib/li
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
On Wed, Jul 02, 2014 at 10:36:25PM -0700, Matthew Dempsky wrote:
> According to the "Intel 64 and IA-32 Architectures Software
> Developer's Manual", CPUID.8001H:EDX.Page1GB [bit 26] indicates
> whether 1-GByte pages are supported with IA-32e paging.
>
> I think the diff below adds support for
This patch is generated by coccinelle, but I reviewed it. I changed the
lpr patch to use warnc() so it has less code executing inside
PRIV_START.
I targeted if statements where it modifies errno before warn or err is
called. It checked a list of functions that are typically used in error
handlin
On Fri, Jul 11, 2014 at 07:29:06PM +0200, Marc Espie wrote:
> I don't like that part. The logic is a bit wrong. Especially since
> unlink(fname) is always called for fd != -1, so I feel there should be one
> single call.
Ok
Index: usr.bin/m4/eval.c
===
On Fri, Jul 11, 2014 at 12:19:22PM +0200, Philip Guenther wrote:
> This should call warn() before unlink() or close() to guarantee that the
> correct errno value is reported.
...
> This and several other need to save errno and use errc(), ala:
Updated patch. Updated mktemp.3 this time.
Index: b
On Fri, Jul 11, 2014 at 12:19:22PM +0200, Philip Guenther wrote:
> This should call warn() before unlink() or close() to guarantee that the
> correct errno value is reported.
Philip,
I see what you are saying. I was following the man page example in
mkstemp(3) which calls warn() after unlink/clo
Index: bin/csh/dol.c
===
RCS file: /cvs/src/bin/csh/dol.c,v
retrieving revision 1.17
diff -u -p -d -r1.17 dol.c
--- bin/csh/dol.c 12 Aug 2010 02:00:27 - 1.17
+++ bin/csh/dol.c 11 Jul 2014 09:12:11 -
@@ -829,7
Another patch will handle some of the fdopen error handling leaks
that are combined with missing unlink calls when using mkstemp.
Index: games/atc/log.c
===
RCS file: /cvs/src/games/atc/log.c,v
retrieving revision 1.17
diff -u -p -d
On Fri, Jul 11, 2014 at 01:03:54AM -0600, Anthony J. Bentley wrote:
> In addition to what jmc said, if you document these flags they need to
> be marked up with the Cm macro instead of ASCII single quotes.
My mistake. Fixed version:
Index: lib/libc/stdlib/malloc.3
==
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.
Index: bin/csh/dir.c
===
RCS file: /cvs/src/bin/csh/dir.c,v
retrieving revisio
I don't think the current man page has enough detail for what the
malloc.conf settings do.
Index: lib/libc/stdlib/malloc.3
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
retrieving revision 1.78
diff -u -p -d -r1.78 malloc.3
--- l
socket() returns -1 on error.
Index: usr.sbin/smtpd/table_socketmap.c
===
RCS file: /cvs/src/usr.sbin/smtpd/table_socketmap.c,v
retrieving revision 1.4
diff -u -p -d -r1.4 table_socketmap.c
--- usr.sbin/smtpd/table_socketmap.c8 J
43 matches
Mail list logo
