| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
who uses '\0' as a null pointer constant? fix my mistake and restore
original semantics.
|
| |
|
| |
|
|
|
|
|
|
| |
unchecked malloc at the same time.
ok beck@
|
|
|
|
|
|
|
|
|
| |
frequent construct of 30 lines of pointer and strlcat insanity followed
by an ERR_add_error_data. I will sweep through here like a chubby mongol
horde in the next few days pillaging crappy ERR_add_error_data's.
Oh and while we're at it fix the nasty vdata function to use something less
hard on the eyes.
ok jsing@
|
|
|
|
|
|
| |
well...
ok beck@
|
| |
|
|
|
|
| |
I missed on the first go around.
|
| |
|
|
|
|
|
|
|
| |
signal(SIGPIPE, SIG_IGN) and apps_shutdown is a no-op. So just do that
instead.
ok beck@
|
| |
|
|
|
|
| |
ok beck@
|
|
|
|
|
|
| |
do not use lint.
ok miod@
|
|
|
|
|
|
|
|
|
| |
a small signed one to it.. Some people on OpenSSL's list
noticed - http://marc.info/?l=openssl-dev&m=139809485525663&w=2
This should fix that, and make sure we don't try to write out insane
amounts of stuff.
ok miod@ tedu@
|
| |
|
|
|
|
|
|
| |
as well ("openssl ciphers -h").
"sure" miod@
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
do_ssl3_write() is recursive. and not in the simple, obvious way, but in
the sneaky called through ssl3_dispatch_alert way. (alert level: fuchsia)
this then has a decent chance of releasing the buffer that we thought we
were going to use. check for this happening, and if the buffer has gone
missing, put another one back in place.
the direct recursive call is safe because it won't call ssl3_write_pending
which is the function that actually does do the writing and releasing.
as reported by David Ramos to openssl-dev:
http://marc.info/?l=openssl-dev&m=139809493725682&w=2
ok beck
|
| |
|
|
|
|
|
|
|
|
| |
``debug'' code from a 15+ years old bugfix and the SSL_OP_PKCS1_CHECK_*
constants have had a value of zero since ages. No production code should use
them.
ok beck@
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
very obvious use after free. this file may still be a total loss.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
#define socklen_t int
somewhere (or a typedef, whatever gives you an integer type of the size
your system expects as the 3rd argument of accept(2), really).
OpenSSL here is a bit more creative by using an union of an int and a size_t,
and extra code if sizeof(int) != sizeof(size_t) in order to recover the
proper size. With a comment mentioning that this has no chance to work on
a platform with a stack growing up and accept() returning an int, fortunately
this seems to work on HP-UX.
Switch to the light side of the force and declare and use socklen_t variables,
period. If your system does not define socklen_t, consider bringing it back
to your vendor for a refund.
ok matthew@ tedu@
|
| |
|
| |
|
|
|
|
| |
caller to crash. Fix leak and return an error instead. from Chad Loder
|
| |
|
|
|
|
| |
under __TANDEM systems and compilers, using hardcoded octal numbers. NOT.
|
| |
|
|
|
|
|
| |
lacking an explicit `case 0:' construct. But Ultrix has been dead for more than
15 years, really. Don't give it any reason to move out of its coffin.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
<machine/endian.h>, rather than writing 1 to a 32-bit variable and checking
whether the first byte is nonzero.
tweaks and ok matthew@; ok beck@ tedu@
|
|
|
|
|
|
|
| |
we always junk small chunks now, and the first part of pages,
but only after free. J still does the old thing. j disables everything.
Consider experimental as we evaluate performance in the real world.
ok otto
|
|
|
|
|
|
|
| |
unnecessary. Remove the temporary ugly casts - the comments even call them
that!
ok guenther@
|
|
|
|
|
|
| |
people do.
ok beck@ (although he wanted #Arrrrrrrgv instead).
|
|
|
|
| |
okay otto@
|
|
|
|
| |
Should improve sparc64 and other be archs. ok matthew@ miod@
|
|
|
|
| |
ok miod@
|
|
|
|
| |
from Dirk Engling <erdgeist@erdgeist.org>
|
|
|
|
|
| |
for the size of a fixed size array.
From Dirk Engling <erdgeist@erdgeist.org>
|
|
|
|
| |
than 32 bits.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
little gem called OPENSSL_indirect_call(), supposedly to be ``handy under
Win32''.
In my view, this is a free-win ROP entry point. Why try and return to libc
when you can return to libcrypto with an easy to use interface?
Better not give that much attack surface, and remove this undocumented
entry point.
ok beck@ tedu@
|
|
|
|
|
| |
instead of garbage, and add this to the libcrypto regress. Note these tests
are incomplete, as they always use the default IV.
|