similar to: [BUG] OpenSSL function has been deprecated

Patch v2 --- a/src/lib-ssl-iostream/iostream-openssl-params.c +++ b/src/lib-ssl-iostream/iostream-openssl-params.c @@ -13,10 +13,19 @@ generate_dh_parameters(int bitsize, buffer_t *output, const char **error_r) { DH *dh; unsigned char *p; - int len, len2; + int len, len2, success; +#if OPENSSL_VERSION_NUMBER >= 0x00908000L + success = DH_generate_parameters_ex(dh, bitsize,

> On April 26, 2017 at 3:15 PM Peter van der Does <peter at avirtualhome.com> wrote: > > > Patch v2 > > --- a/src/lib-ssl-iostream/iostream-openssl-params.c > +++ b/src/lib-ssl-iostream/iostream-openssl-params.c > @@ -13,10 +13,19 @@ generate_dh_parameters(int bitsize, buffer_t *output, const char **error_r) > { > DH *dh; > unsigned char *p;

Based on the recent found weaknesses in DH key exchange, http://weakdh.org/ I increased ssl_dh_parameters_length to 2048 bits, and found waited for 5+ minutes for dovecot to come back online after a restart. Unless you got a fast machine, the initialization of DH parameters can exceed your patience. Regeneration may not be a problem (if ssl_parameters_regenerate=0 or if Dovecot uses old

> On Apr 25, 2017, at 4:30 PM, Peter van der Does <peter at avirtualhome.com> wrote: > > The problem with making the Dovecot check for libmysqlclient.so.20 would > be that you have have to make sure older/newer packages are also > supported. The 20 extension is subject to changes. > > If I check the Oracle DEB file for Debian 9, it seems they do use the > name

> On Apr 25, 2017, at 5:37 PM, KT Walrus <kevin at my.walr.us> wrote: > > Also, I spotted a deprecation warning that you might want to look into since it has to do with building against OpenSSL 1.1 (which is the default version for Debian 9). Oops!!! Forgot to attach the warning: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I../../src/lib-test

Thank you, Clayton. It works now! Our debugger server responds "name:J28;generic:fp;bitsize:32;encoding:uint;format:hex;gcc:60;dwarf:60". And I also set other "generic" attributes like sp, pc, ra, arg1~arg8 to related registers. I dig a little and find llvm dwarf generator uses TargetRegisterInfo::getFrameRegister() to obtain frame base, and uses

This patch protects against redefinitions of size_t. There are currently at least two different definitions provided with klibc: unistd.h -> stddef.h -> bits32/bitsize/stddef.h sys/times.h -> linux/times.h -> linux/types.h both define size_t, causing gcc to complain. I suspect ptrdiff_t has a similar problem; not covered by this patch. Regards, Erik diff -urN

make -r -C /mlsyslinux -f /mlsyslinux/Makefile SRC="/mlsyslinux" \ OBJ=/mlsyslinux objdir=/mlsyslinux bios make[1]: Entering directory `/mlsyslinux' make -r -C /mlsyslinux/bios -f /mlsyslinux/Makefile SRC="/mlsyslinux" \ objdir=/mlsyslinux/bios OBJ=/mlsyslinux/bios HAVE_FIRMWARE=1 \ ARCH=i386 LDLINUX=ldlinux.c32 all make[2]:

Hi, In case of tl;dr: I fixed a bug in TLS support for LMTP which caused chained certificates not to work, and another one which caused certificate read errors to be ignored; the patches are attached to this email. While testing LMTP with TLS and certificate verification by Postfix I discovered that certificate chains are not exchanged properly when using LMTP, even though everything works fine

Thank you, Clayton. This is very helpful. We use the LLDB specific GDB remote extensions, and our debugger server supports "qRegisterInfo" package. "reg 0x3c" is the frame pointer. In the example mentioned above, we have SP = FP - 40 for current call frame. And variable "a" is stored at address (FP + -24) from asm instruction [FP + -24] = R3;; Thus we can conclude

Adrian Prantl via llvm-dev wrote on Mon, 02 Nov 2015: > Looking at the code in clang CGDebugInfo just passes through the > width of the type as it is described by the TypeInfo, which in turn > is defined by the Target. At the moment I do not understand why an > x86_fp80 is reported to be 128 bits wide. The x86-64 and Darwin/i386 ABI define the size of the 80 bits extended

Hi, I'm with a team using 16-bit bytes for an out-of-tree target. The AsmPrinter framework's implementation of the DWARF debugging format is not very good at distinguishing between target-sized bytes (which is the more common use) and 8-bit-bytes. The DWARF standard itself seems not very good in this regard, actually. So we have had to hack our way around this. I.e., at some call-sites of

/klibc/klibc/include/bits32/bitsize/stdint.h:8: error: redefinition of `int8_t' /klibc/linux/include/linux/types.h:109: error: `int8_t' previously declared here The copy in stdint.h is not protected by: #ifndef __BIT_TYPES_DEFINED__ #define __BIT_TYPES_DEFINED__ #endif /* !(__BIT_TYPES_DEFINED__) */ ===== Jon Smirl jonsmirl@yahoo.com __________________________________ Do you Yahoo!?

It's x86 arch.The reason of compiling pxelinux only is that i want to add tcp support, not http and ftp. ? 2014-05-08 18:09:15?"Gene Cumm" <gene.cumm at gmail.com> ??? On May 7, 2014 11:54 PM, "??" <muliu92 at 163.com> wrote: > make[4]: Entering directory `/mlsyslinux/bios/com32/libupload' > gcc -Wp,-MT,cpio.o,-MD,./.cpio.o.d -std=gnu99 -m32

I'm having an issue with Thunderbird (and Opera) and Dovecot SSL on a Solaris 10. My OS is Solaris 10 6/06 x86 (running in 64-bit mode) using ZFS (disk mirror) as the filesystem for my users. Dovecot version is 1.0rc7 (logs below are from 1.0rc6). First the connection asks if the SSL-certificate should be accepted, accepting it seems to work but then nothing happens. Thunderbird is

The *.shared targets require -shared on powerpc, and -R leads to linker errors. This patch makes the -R an arch define. ia64 at least requires -R. --- ash/Makefile +++ ash/Makefile 2003/11/27 15:04:02 @@ -36,7 +36,7 @@ $(STRIP) $(PROG) $(PROG).shared: $(OBJS) $(LIBS) - $(LD) $(LDFLAGS) -o $(PROG).shared -e main $(KLIBSRC)/interp.o $(OBJS) -R $(KLIBSRC)/libc.so $(LIBGCC) + $(LD) $(LDFLAGS)

Hello James, I've some doubts about what you are proposing... > A suggestion: > Define/describe each address space in the lower layer of LLVM. <- all > the target specific info. > E.g. Address space 0 is 64bits and needs specific instructions to access it. > The LLVM IR can query the lower layer when it needs to know a > description of address space 0 during an

On Mon, Feb 24, 2003 at 05:26:32PM -0800, H. Peter Anvin wrote: > Greg has taken on the job of integrating klibc with the kernel, but > please post klibc bug reports to the klibc mailing list at > <klibc@zytor.com>. To avoid annoying warning from gcc I had to check for compatibility with -falign-* like we do in arch/i386/Makefile. check_usergcc located in top-level makefile to

On 8 August 2013 21:29, Eric Christopher <echristo at gmail.com> wrote: > On Thu, Aug 8, 2013 at 1:26 PM, Michele Scandale > <michele.scandale at gmail.com> wrote: >> On 08/08/2013 09:59 PM, Eric Christopher wrote: >>> >>> I don't believe so, no. Metadata should not be required for correct >>> program behavior. It can be necessary for fast

Hello Leslie, The errors coming from the gnu assembler are due to the file being assembled in Arm state, to get rid of the errors you'll either need to put a .thumb directive in the file, or pass -mthumb to the assembler via arm-linux-gnu-gcc -Wa,-mthumb (I think). I'm not able to explain what you are seeing in your print out as it doesn't quite match the map file. Looking at your