libressl-2.6.2 is susceptible to an out-of-bounds read:
#include
int main(void) {
char salt[3] = {0xf8, 0xd0, 0x00};
char out[32];
DES_fcrypt("foo", salt, out);
}
Place in libressl's fcrypt.c:
x=ret[0]=((salt[0] == '\0')?'A':salt[0]);
Eswap0=con_salt[x]<<
On Wednesday 2015-08-12 20:29, Mark Kettenis wrote:
>
>One possible reason to deviate from using the LibreSSL release version
>would be if we want to continue to be a drop-in replacement for
>OpenSSL. In that case continuing to adevrtise a reasonable OpenSSL
>version number for openssl.pc, libcry
On Tuesday 2015-08-11 03:39, Brent Cook wrote:
>
>> So I think all the .pc files in LibreSSL should simply use the LibreSSL
>> version number (2.2.2) like the openssl.pc does. This does mean that
>> checking
>> for individual libraries in LibreSSL version 2.2.2 and older will probably
>> busted,
On Monday 2015-08-10 02:38, Brent Cook wrote:
>> On Aug 9, 2015, at 10:07 AM, Jan Engelhardt wrote:
>>
>>> We have released LibreSSL 2.2.2, which will be arriving in the
>>> LibreSSL directory of your local OpenBSD mirror soon.
>>
>> The .pc files in l
>We have released LibreSSL 2.2.2, which will be arriving in the
>LibreSSL directory of your local OpenBSD mirror soon.
The .pc files in libressl-2.2.2 upset the package mechanisms at hand, in
particular rpm, where ':' is used to denote the (ancient concept of)
epochs.
[ 99s] Invalid versi
On Saturday 2014-12-13 00:08, Brent Cook wrote:
>> On Dec 12, 2014, at 5:04 PM, Jan Engelhardt wrote:
>>
>> To solve that, simply add
>>
>> libcrypto_la_LDFLAGS = -no-undefined
>> [same for libssl,libtls]
>>
>> Without this, the DLLs wo
With libressl 2.1.2, I observe:
> ldd -r /usr/lib64/libtls.so.1
linux-vdso.so.1 (0x7ffe5462e000)
libc.so.6 => /lib64/libc.so.6 (0x7ffe5405f000)
/lib64/ld-linux-x86-64.so.2 (0x7ffe5463)
undefined symbol: GENERAL_NAME_free (/usr/lib64/libtls.so.1)
undefin
On Monday 2014-08-04 01:36, Bob Beck wrote:
>We have released LibreSSL 2.0.4, which should be arriving n the
>LibreSSL directory of an OpenBSD mirror near you very soon.
>
>This version includes more portability changes, as well as other work.
>most noticable may be the deletion of the of the SRP
On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote:
>
>* The build system defaults --program-transform-name to the host triplet
> when cross-compiling. It shouldn't do that as the library doesn't have
> a target and is not a cross-compiler (as far as I know). It certainly
> doesn't ma
On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote:
>
>* ioctl(FIONBIO) is used in a few files to make sockets non-blocking
> rather than using fcntl to set the the standard O_NONBLOCK bit. The
> files apps/s_client.c and apps/s_server.c should use BIO_socket_nbio()
> instead of direc
On Thursday 2014-07-17 00:02, Jonas 'Sortie' Termansen wrote:
>
>I ported libressl to my custom hobby OS and it has been a pleasant
>experience. Nonetheless, I did run into some minor portability problems
>that I wish to share:
>
>* apps/Makefile.am.tpl links libcrypto and libssl in the wrong orde
>We have release an update, LibreSSL 2.0.2
>
>This release addresses the Linux forking and pid wrap issue reported
>recently in the press.
The newly-added /tests/asn1test fails to complete successfully under
Linux when built as 32-bit object, in either a 32-bit userspace
or on a multiarch.
$ .
On Monday 2014-07-14 20:34, Bob Beck wrote:
>What problem are you trying to solve here.
>> Pristine libtool does not pass -m 644, and default (GNU) install
>> defaults to mode 755 when not specifying anything else.
I am trying to figure out why OpenBSD would be patching libtool
and adding
+
On Monday 2014-07-14 20:16, Toni Mueller wrote:
>Hi Jan,
>
>On Sun, Jul 13, 2014 at 08:30:38PM +0200, Jan Engelhardt wrote:
>> On Sunday 2014-07-13 13:07, Bob Beck wrote:
>> >We have released an update, LibreSSL 2.0.1
>> >As noted before, we welcome fe
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 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
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
> CCLD openssl
>../crypto/.libs/libcrypto.so: undefined reference to `clock_gettime'
>collect2: ld returned 1 exit status
>make[1]: *** [openssl] Error 1
>
>Setting LDFLAGS to -lrt fixes the issue.
Rather than LDFLAGS, it should be in LDADD/LIBADD.
--8<--
Subject: build: resolve link-time fa
>The first release of LibreSSL portable has been released. LibreSSL
>can be found in the LibreSSL directory of your favorite OpenBSD
>mirror.
>
>http://ftp.openbsd.org/pub/OpenBSD/LibreSSL has it, and other
>mirrors will soon.
>
>libressl-2.0.0.tar.gz has been tested to build on various versions
>
19 matches
Mail list logo
