> OpenSSL 1.1.0 Pre 1
> Platform: Sparc Solaris 10
> Compiler: GCC 4.9.3
>
> Warnings:
>
> e_des.c: In function 'des_init_key':
> e_des.c:239:29: warning: assignment from incompatible pointer type
> dat->stream.cbc = enc ? des_t4_cbc_encrypt :
> des_t4_cbc_decrypt;
>
> You can also add some more macros to the perlasm which already translates a
> LOT of opcodes into something older assemblers won't choke on.
If it was a matter of few instructions, then absolutely. But if it's a
question about *all* vector instructions, then it becomes
counter-productive. As al
Hi,
> Per Jeremy Farrell's suggestion, specifying the "-no-asm" option worked and I
> was able to get through the build.
>
> Regarding the "stvx" instruction, here is a bit clearer set of info to map to
> why that instruction seemed to be the issue:
Original report listed even last lines in er
> It looks like in the #ifndef SIGALRM case, c[D_GHASH][0] is set, but not
> c[D_GHASH][i] for larger i.
Fixed in master.
> (Where is the no-SIGALRM code used?)
Nowhere 99.997% cares about. Originally it was used extensively on
Windows (i.e. among those majority cared about), but then even t
Hi,
> I've started playing with the ChaCha20 assembly that was recently checked
> in and found a few problems. Most of these do not affect OpenSSL as you
> only ever call ChaCha20_ctr32 on a whole number of blocks. But this isn't
> documented as a constraint in internal/chacha.h and the assembly h
>> 1. In chacha-x86_64.pl, .Ltail:
>>
>> 2. In chacha-x86_64.pl, .Loop_tail_ssse3:
>>
>> 3. In chacha-x86.pl, loop:
>
> Fix is upcoming. Thanks!
>
>> 4. The assembly versions crash if you pass in an empty input/output. The
>> generic C code handles this fine. (I'll defer to you whether this is a
Hi,
> The partial-block tail code in chacha-armv4.pl also seems to have problems.
> My colleague Steven and I made an attempt to debug it, but we're not
> familiar enough with ARM to fix it.
>
> From playing with it in a debugger, it doesn't look like @t[3] contains the
> length. We suspect somet
> The fix seems to work.
On related note, a problem was reported with poly1305-armv4 module,
which was traced down to assembler (different versions disagree about
how to treat #-1 as argument to vmov.i64). If you run into problem,
don't panic, fix is upcoming...
--
Ticket here: http://rt.openss
> There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not
> attempted to debug this, but I have attached a test file which produces
> different output in normal and AVX2 codepaths. Our existing poly1305
> implementation agrees with the former.
>
> $ OPENSSL_ia32cap=0 ./poly1305
>> There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not
>> attempted to debug this, but I have attached a test file which produces
>> different output in normal and AVX2 codepaths. Our existing poly1305
>> implementation agrees with the former.
>>
>> $ OPENSSL_ia32cap=0 ./pol
> There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not
> attempted to debug this, but I have attached a test file which produces
> different output in normal and AVX2 codepaths. Our existing poly1305
> implementation agrees with the former.
>
> $ OPENSSL_ia32cap=0 ./poly1305
Hi,
> we met crash of openssl (varely, 3 times i have seen) on linux x86_64.
> openSSL version is 1.0.1r.
>
> The stack is as below:
> Program terminated with signal 11, Segmentation fault.
> Thread 1 (Thread 0x7f0654871700 (LWP 22383)):
> #0 0x7f06a2cdddb8 in sha1_block_data_order_ssse3 ()
> Patch attached. This is just a little cleanup change to fix not everything
> using the OPENSSL_armcap constants. (Existing ones already are using them,
> so I'm assuming this is okay.)
Applied. Thanks.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4341
Please log in as guest wi
> 0x2b41740e8da7 <+2967>: je 0x2b41740e8f40
>
> 0x2b41740e8dad <+2973>: movdqa 0x40(%r11),%xmm6
> 0x2b41740e8db3 <+2979>: movdqa (%r11),%xmm9
> => 0x2b41740e8db8 <+2984>: movdqu (%r9),%xmm0
>
> If the other EVP ciphers universally allow this then I think we must treat
> this
> as a bug, because people may be relying on this behaviour. There is also
> sporadic documentation in lower-level APIs (AES source and des.pod) that the
> buffers may overlap.
>
> If it's inconsistent then, at th
>>> If the other EVP ciphers universally allow this then I think we must
>> treat this
>>> as a bug, because people may be relying on this behaviour. There is also
>>> sporadic documentation in lower-level APIs (AES source and des.pod) that
>> the
>>> buffers may overlap.
>>>
>>> If it's inconsiste
> Working from master:
>
> $ git reset --hard HEAD && git pull
> HEAD is now at e9b1c42 make errors
>
> Then:
>
> $ KERNEL_BITS=32 ./config
> ...
>
> $ make depend && make clean && make
> ...
>
>
> $ make
> ...
>
> LD_LIBRARY_PATH=..: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS
> -DO
On 03/02/16 03:54, noloa...@gmail.com via RT wrote:
> $ make depend && make clean && make
> ...
>
> $ make test
> ...
>
> ../test/recipes/80-test_tsa.t . ok
> ../test/recipes/90-test_async.t ... 1/1
> # Failed test 'running asynctest'
> # at ../test/testlib/OpenSSL/Test/Si
> OS X side steps the problems with selecting the wrong runtime library
> and RPATHs by using something called an install name. Effectively, the
> install name should be placed in libcrypto.dylib and libssl.dylib, and
> it calls out the fully qualified path name. Programs linked to a
> library with
On 03/14/16 03:58, noloa...@gmail.com via RT wrote:
> Working from Master...
>
> gentoo@Gentoo-2012 ~/openssl $ ./config
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre4-dev (0x0x1014L)
> no-crypto-mdebug [default] OPENSSL_
> Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
> 32-bit tests OK.
>
> The relevant snippets are:
>
> $ make test
> ...
> ../test/recipes/90-test_async.t ... 1/1
> # Failed test 'running asynctest'
> # at ../test/testlib/OpenSSL/Test/Simple.pm line 70.
> # Loo
>>> Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
>>> 32-bit tests OK.
>>>
>>> The relevant snippets are:
>>>
>>> $ make test
>>> ...
>>> ../test/recipes/90-test_async.t ... 1/1
>>> # Failed test 'running asynctest'
>>> # at ../test/testlib/OpenSSL/Test/Simple.p
Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit.
32-bit tests OK.
The relevant snippets are:
$ make test
...
../test/recipes/90-test_async.t ... 1/1
# Failed test 'running asynctest'
# at ../test/testlib/OpenSSL/Tes
> It looks like the ULL suffix should be safe today;
This is misleading statement. *Today* U suffix should be safe, because
standard specifies that compiler should pick type automatically
depending on value of the constant. In order words suffices beyond U are
required only if you need constant to
> Is it possible that real target is so called x32, i.e. x86_64 with
> 32-bit address space limitation? In such case linux-x32 would be the
> right target...
On side note, I'm getting make test failures for linux-x32 target. I
mean if it turns out that it's the right target for you, and you see
ma
>> OS X side steps the problems with selecting the wrong runtime library
>> and RPATHs by using something called an install name. Effectively, the
>> install name should be placed in libcrypto.dylib and libssl.dylib, and
>> it calls out the fully qualified path name. Programs linked to a
>> library
>> Is it possible that real target is so called x32, i.e. x86_64 with
>> 32-bit address space limitation? In such case linux-x32 would be the
>> right target...
>
> I don't believe this is x32 since {x86_64|amd64} and __ILP32__ are not
> defined; see preprocessor output below.
Got it. But just in
Hi,
> You know the drill. See the attached poly1305_test2.c.
>
> $ OPENSSL_ia32cap=0 ./poly1305_test2
> PASS
> $ ./poly1305_test2
> Poly1305 test failed.
> got: 2637408fe03086ea73f971e3425e2820
> expected: 2637408fe13086ea73f971e3425e2820
>
> I believe this affects both the SSE2 and AVX2 co
On 03/14/16 17:12, Andy Polyakov via RT wrote:
>> It looks like the ULL suffix should be safe today;
>
> This is misleading statement. *Today* U suffix should be safe, because
> standard specifies that compiler should pick type automatically
> depending on value of the consta
Hi,
> There are a few problems that I am facing with unified builds with arm:
>
> 1. arm_arch.h is not in the include path.
> fatal error: arm_arch.h: No such file or directory
>
> 2. The arm assembler scripts output to stdout
> (see attached output.txt)
This was addressed in a bigger sweep ad
> Attached is an updated version of the test with an additional test
> vector. This one happens on 64 bit and not on 32 bit.
Got it. It will take some time to perform cross-checks. Thanks!
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4483
Please log in as guest with password gu
> For x86-64, this seems to be the bug:
>
> $ git diff
> diff --git a/crypto/poly1305/asm/poly1305-x86_64.pl b/crypto/poly1305/asm/
> poly1305-x86_64.pl
> index 3c810c5..bc14ed1 100755
> --- a/crypto/poly1305/asm/poly1305-x86_64.pl
> +++ b/crypto/poly1305/asm/poly1305-x86_64.pl
> @@ -97,6 +97,7 @@
On 03/28/16 15:16, Viktor Dukhovni via RT wrote:
>
>> On Mar 28, 2016, at 4:38 AM, noloa...@gmail.com via RT
>> wrote:
>>
>> On Windows, the fix below also depends upon the patch from Issue 4488
>> ("The POSIX name for this item is deprecated. Instead, use the ISO C++
>> conformant name...").
>>
>> Attached is a sample code that will test various inputs for the
>> Poly1305 functions of openssl...
>
> I'm seeing compiler conversion warnings about size_t to int
> truncation.
Can you be more specific?
> Do you have any vectors that cross the 2GB boundary?
--
Ticket here: http://rt.opens
>>> In the final reduction, $h1 is all ones, so there is one more carry to
>>> propagate. Though $h2 can then overflow its two bits, I think? I expect
>>> that and the cleared bits of r mean the imulqs in poly1305_iteration are
>>> still safe, so we can pick up that slack in poly1305_emit, but I'm
>>> No, it doesn't depend on call pattern. Please confirm that attached
>>> patch solves the problem. Thanks.
>>>
>>
>> (Right, sorry, I meant that the test vectors I have seem to only with
>> their corresponding call patterns.)
And I meant that I observed failure pattern other than suggested. Nev
> The change
>
> https://github.com/openssl/openssl/commit/5384d1e4ebd58f31a06b2f5d1f6c4b28f63d72ed
>
> introduced a typo in the last line of file crypto/camellia/build.info.
Fixed. Thanks for report.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4520
Please log in as guest wi
Hi,
> The following code in the ChaCha20_ctr32 function in
> crypto/chacha/chacha_enc.c looks like you are actually using an IV=[64bit
> counter||64 bit nonce] as specified in the "original Bernstein ChaCha"
> instead of IV=[32bit counter||96bit nonce] as specified in RFC7539.
Correct. While it's
> Valgrind does not necessarily support all instructions, if there’s any
> optimized assembly, you might run into problems.
> Are you able to compile a non-assembly version of the OpenSSL library?
> Are you able to update to a newer Valgrind?
Or at least tell valgrind version, because I can't rep
>>> Valgrind does not necessarily support all instructions, if there’s
>>> any optimized assembly, you might run into problems.
>>> Are you able to compile a non-assembly version of the OpenSSL
>>> library?
>>> Are you able to update to a newer Valgrind?
>> Or at least tell valgrind version, becaus
> Hi Paul,
It doesn't seem unlike that OP is not subscribed, so he won't see
responses send to alone. To ensure delivery and or reply
to .
> I have not checked the code for the test, but I do get the expected
> values with my little test program.
But what is your host, Massimiliano? Is it also
> There is a bug in Hercules 3.12 and below as well as Hyperion.
In other words, not OpenSSL problem, cases are being dismissed.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4500
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe:
> Valgrind does not necessarily support all instructions, if
> there’s
> any optimized assembly, you might run into problems.
> Are you able to compile a non-assembly version of the OpenSSL
> library?
> Are you able to update to a newer Valgrind?
Or at least tell valgri
> Openssl-1.1.0-pre4 can't be built for linux-ppc with options no-chacha or
> no-poly1305 since crypto/ppccap.c doesn't use OPENSSL_NO_CHACHA and
> OPENSSL_NO_POLY1305.
This was fixed. Closing ticket.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4508
Please log in as guest wit
>> Right. What I meant is that a fully reduced h has $h2 < 4. Is it possible
>> that $h2, after that adc, ends up at 4, exceeding that bound? If it were,
>> that would require one more reduction.
>>
>> In the non-SIMD paths, I believe this is fine because $r0's and $r1's
>> cleared high bits mean w
> $ ./config -fsanitize=undefined
Sanitized builds might have to be complemented with -DPEDANTIC. Quoting
Configure:
# ... Incidentally -DPEDANTIC has
# to be used even in sanitized builds, because sanitizer too is
# supposed to and does take notice of non-standard behaviour.
Similar rule applie
> This seems like an odd result considering the BeagleBone Black
> processor is closer to a NEON.
Well, ./config script should add -march=armv7-a option and that is more
than enough to make it NEON-capable. In fact linux-armv4 target covers
*all* post-v4 32-bit processors, it's all about additiona
> Building openssl-1.1.0pre3 for irix-mips3-cc fails because
> struct timeval is undefined:
This was addressed recently. Case is being dismissed.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4331
Please log in as guest with password guest if prompted
--
openssl-dev mailing li
> I'm trying to build openssl 1.1.0pre3 on IRIX 6.5 with the new unified
> building system using perl 5.8.9. This fails with the error message
> below. Building without --unified works as expected. Any hints
> how to debug this or extract better logs would be appreciated.
There is minimal require
> make test fails on IRIX 6.5 with perl 5.8.9 when building for irix-mips3-cc
> and irix64-mips4-cc (the only platforms I've tried so far).
Just like with RT#4332 you've got to have at least Perl 5.10. Case is
being dismissed.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4333
P
Hi,
> I got an failure at "make test" sea end of Mail
Well, at the end of the mail it says that it failed to link. It's rather
indication of something going wrong with *your* compiler setup. We more
or less stand for correctness of code and you stand for providing sane
compiler environment it can
> Author: Leonidas Da Silva Barbosa
> ASM implementation
>
> Signed-off-by: Paulo Flabiano Smorigo
> Signed-off-by: Leonidas Da Silva Barbosa
> ---
> +my ($inp,$out,$len,$key,$tweak,$enc,$rounds,$idx)=map("r$_",(3..10));
There seem to be misunderstanding. EVP layer expects XTS "stream"
subrout
> I'm getting:
> crypto/chacha/chacha-s390x.S: Assembler messages:
> crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije'
>
>
> A full build log is available on:
> https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=s390x&ver=1.1.0~pre5-1&stamp=1464594754
It's overly easy
> I'm getting assembler errors on hppa that look like:
> crypto/aes/aes-parisc.s: Assembler messages:
> crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa'
> crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt'
> crypto/aes/aes-parisc.s:11: Error: Missing function name for .PR
> I'm seeing this on powerpc:
> ../test/recipes/01-test_ordinals.t . ok
>
> # Failed test 'check that there are no missing symbols in libcrypto.so'
> # at ../test/recipes/01-test_symbol_presence.t line 112.
> # Looks like you failed 1 test of 4.
> ../test/recipes/01-test_symbol_presenc
>>> I'm getting:
>>> crypto/chacha/chacha-s390x.S: Assembler messages:
>>> crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije'
>>>
>>>
>>> A full build log is available on:
>>> https://buildd.debian.org/status/fetch.php?pkg=openssl&arch=s390x&ver=1.1.0~pre5-1&stamp=1464594754
>>
>>
Hi,
> I'm aware it doesn't affect anything because the caller shouldn't process
> more than 2^32 * 64 bytes per key/nonce setup anyway.
>
> I was just wondering because it differs from the s390 asm implementation
> (and whether there is a particular reason to do so).
Implementation is harmonized
>> In other words
>> could you double-check attached patch instead?
>
> Thanks. Just tested and it compiles and the testsuite passes.
Committed. Thanks. Case is being dismissed.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4548
Please log in as guest with password guest if prom
> Looking over your logs, you appear to be configuring with no-asm,
"no-asm" is the culprit here, but problem is not reporter's but mine.
mem_clr.c was updated, but build was not tested with no-asm. Fix is
upcoming.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563
Please log in
bn_add.c was modernized in
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=7d6284057b66458f6c99bd65ba67377d63411090
and suggested modifications were "accumulated". Case is being dismissed.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3100
Please log in as guest with p
> It will be in 1.0.2 shortly.
Applied to 1.0.2.
> It's not relevant for 1.1 which doesn't support FIPS.
Because current 2.x version of FIPS module won't be supported with 1.1,
so that solution in 1.1 would have to be different.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=369
> Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is
> hidden, I still have to try over environment variables, which are not
> as flexible for arm as for x86).
>
>
> Anyway, it would be helpful to exclude hardware aes instructions at
> compile-time:
>
> 1) Runtime checking is
> Two more observations.
>
> OPENSSL_ia32cap_loc() alters the underlying OPENSSL_ia32cap_P, the bits not
> fitting into the expected integer size being zeroed. I do not know if it is
> practically relevant, but it is strange that a read has side effects. It
> would be a good reason for dedicate
> Thanks for the explanations.
>
> In the code I am working with, I see:
> $ sed -n '657p' openssl-1.0.2h/crypto/cryptlib.c
> unsigned long *OPENSSL_ia32cap_loc(void)
>
> You may want to verify it.
Right! Sorry about confusion, my bad! It was long in 1.0.x and in became
int in master. Anyway, po
> 1) Openssl works correctly (no crash, correct detection), as far as I
> can judge. By error-prone I mean, very defensively, that I (or
> others) could make a mistake, or that future versions of openssl
> could not work exactly the same way.
Well, this is effectively argument in favour of denying
> The following is from a CubieBoard. I verified I performed a 'make
> clean' and 'git pull'.
>
> $ git rev-parse HEAD
> 13c03c8d6da334bb1cde6ce4133e7c75b3b76947
>
> **
>
> using V=1:
>
> ../test/recipes/30-test_evp.t ..
> 1..1
> Test line 2163(aligned in-place): unexpected
>>> ../test/recipes/30-test_evp.t ..
>>> 1..1
>>> Test line 2163(aligned in-place): unexpected error VALUE_MISMATCH
>>> Expected:
>>> 000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132333435363738393A3B3C3D3E3F404142434445464748494A4B
> Here's a couple more ways things don't work as expected:
>
> # ./config CFLAGS="-mx32"
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32)
>
>
>> Here's a couple more ways things don't work as expected:
>>
>> # ./config CFLAGS="-mx32"
>> Operating system: x86_64-whatever-linux2
>> Configuring for linux-x86_64
>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
>> target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32
> you're not allowed to break the compile, regardless of whether there's
> a proper "X32" kernel.
I don't understand what do you mean by "break the compile". I'd say it's
the kind of thing that lies on both parties. We are responsible for
providing code and config lines, but you have responsibilit
> A quick question about this configuration... Should Linux-x32 enable
> ec_nistp_64_gcc_128 by default? Does anything prohibit
> ec_nistp_64_gcc_128 in this configuration?
>
> # ./Configure linux-x32
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> no-asan [default] OPE
>>> A quick question about this configuration... Should Linux-x32 enable
>>> ec_nistp_64_gcc_128 by default? Does anything prohibit
>>> ec_nistp_64_gcc_128 in this configuration?
>>>
>>> # ./Configure linux-x32
>>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
>>> no-asan [
> Fair enough, agreed.
>
> But Configure ignored my instructions:
>
> # ./config CFLAGS="-mx32"
> Operating system: x86_64-whatever-linux2
> Configuring for linux-x86_64
> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
> target already defined - linux-x86_64 (offending arg: CFLAGS=-mx
>>> # ./config -mx32
>>> Operating system: x86_64-whatever-linux2
>>> Configuring for linux-x86_64
>>>
>>> Perhaps the second case should fail at configure just like the first
>>> case. Upon failure, it would be nice to tell the user what to do:
>>> "Please configure with ./Configure linux-x32"
>>
> ... What one can discuss is to have
> ./config (not ./Configure) detect x32 environment and pass alternative
> config line to ./Configure. That's how it worked so far and I see no
> reason to change it by moving platform detection logic to ./Configure.
--
Ticket here: http://rt.openssl.org/Ti
A quick question about this configuration... Should Linux-x32 enable
ec_nistp_64_gcc_128 by default? Does anything prohibit
ec_nistp_64_gcc_128 in this configuration?
# ./Configure linux-x32
Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L)
no-asan
>> I don't know what you expect us to do. We don't use the LD variable.
>
> Right. I'm just pointing out gaps.
>
> It only gets worse for users. What happens when someone tries a
> cross-compile by setting CC, AR, RANLIB, LD and a CFLAGS with
> --sysroot? As far as I know, there is no RTFM for c
> Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
> Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
> extensions, but includes vmull and crc32 (vmull include arrangements
> other than u8). The gadget also runs Raspian, which is a 32-bit OS
> with hard floats.
> Attached is a patch that adds two Configure targets: linux-aarch32 and
> linux-aarch32hf. It might make a good starting point for Aarch32
> support.
>
> The patch enables CRC and Crypto extensions by default.
Code that utilizes crypto extensions is compiled with -march=armv7-a by
default. Or ma
> Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry
> Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto
> extensions, but includes vmull and crc32 (vmull include arrangements
> other than u8).
??? If you're referring to polynomial multiplication, then it's p8, n
Hi,
> I'm trying to set up OpenSSL on Windows 10 64-bit (i7 Skylake), having
> followed the instructions so far, after installing Visual Studio I
> attempted to nmake in the openssl directory using Visual c++ 2008 command
> prompt to get the following error:
>
> "C:\Strawberry\perl\bin\perl.
>> (gdb) bt full
>> #0 0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
>> No symbol table info available.
>> #1 0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
>> No symbol table info available.
>> #2 0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1
>> No symbol
On 7/30/2016 8:18 PM, Andy Polyakov via RT wrote:
>>> (gdb) bt full
>>> #0 0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1
>>> No symbol table info available.
>>> #1 0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1
>>> No symbo
>>> (gdb) r test/evptests.txt
>>> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library
>>> "/lib/arm-linux-gnueabihf/libthread_db.so.1".
>>>
>>> Program received signal SIGBUS, Bus error.
>>> C
> For x86, define macros for capability bits (like for arm and pcc), according
> to https://www.openssl.org/docs/manmaster/crypto/OPENSSL_ia32cap.html:
As discussed in RT#4568 and RT#4570, these are internal interfaces and
there is no intention to expose it to user, except through setting
environ
Hi,
> i had some problems on Win64 using BIO_do_handshake/BIO_should_retry in a
> loop. The compiler optimizer placed a local variable value in the xmm6
> register.
> The content of this register was destroyed after calling BIO_do_handshake. I
> debugged this and found that the xmm6/xmm7 regist
> Does current master work? I think Andy checked in a fix.
Rich was few minutes ahead. Now it's committed. Provided test case was
verified to work. Thanks for report.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted
--
Hi,
> Hi, our team have been experiencing a crash in some production
> machines (which I cannot reproduce in development machines) caused by
> the libeay32 module in 64 bits Windows 10 machines.
>
> I was able to create a simple "crash application" and was able to get
> the dump of the crash alon
Hi,
> make test stops on Solaris10 x64.
>
>
> % ./Configure solaris64-x86_64-gcc
>
> % make
> % make test
>:
> ../test/recipes/01-test_abort.t ok
> ../test/recipes/01-test_sanity.t ... ok
> ../test/recipes/01-test_symbol_presence.t .. ok
> ../test/recipes/02-te
> ( cd test; \
> SRCTOP=../. \
> BLDTOP=../. \
> PERL="perl" \
> EXE_EXT= \
> OPENSSL_ENGINES=.././engines \
> perl .././test/run_tests.pl test_afalg )
> ../test/recipes/30-test_afalg.t ..
> 1..1
> ALG_PERR: afalg_fin_cipher_aio: io_read failed : Bad address
> test_afalg_aes_128_cbc()
Hi,
> I have no time to check with debugger now,
Then no progress will be made. Problem needs to be identified first, and
since similar problem was identified earlier, I'd have to insist on
confirmation whether or not it's the same.
> but I do not think it is caused by assembler,
> because,
> -
> I tested the following command on fedora 24 and mingw64 (mingw64 installed
> via git for windows):
>
> openssl genrsa -des3 -out server.key 1024
>
> On fedora, it's instantaneous.
> On mingw64, it's stuck before asking the key:
>
> Generating RSA private key, 1024 bit long modulus
> .
Consider attached diff.
> The issue is particularly clear when we multiply the generator by
> zero. Note that in general, an application shouldn't multiply the
> generator by zero since there's no useful cryptographic purpose for
> doing so. But, this is a convenient example.
>
> In the code we h
> I'm working from the 1.0.2h tarball. The platform is Debian 8 (booted
> with syscall.x32=y, but the X32 chroot was not entered). GCC is 5.2.1.
>
> '-fPIC' was manually added after 'shared' caused the initial
> "relocation R_X86_64_32 ..." error. Omitting 'shared' does not witness
> an error.
32
> If goal actually is to execute openssl at msys command prompt, then
> openssl should be compiled *for* msys, but we don't actually support
> this configuration.
On related note it appears that reason for why the question about msys
support wasn't risen so far is because prior Windows 10, prompti
Hi,
> We are using libcurl for REST programming, which internally uses openssl
> and libcrypto.
> curl suggested to implement few callbacks related to locking, which would
> be needed for openssl below 1.1 version(which is still in beta).
>
> The following callbacks were implemented:
>
> https:/
There are two commits, one that addresses bio_enc problems and one
adding test. Please double-check.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mail
> With the current build system, user-defined CFLAGS are accepted as any
> unrecognized command line argument passed to Configure. This seems a
> little dangerous to me since it means a simple typo could end up
> getting passed to the C compiler.
Is it more dangerous than interactive access? But o
> Results:
>
>
> In short:
> - no issue with v1.0.2h on both machines
> - issue appears with:
> - XLC -O but only for 64bits
> - GCC -O for both 64bits and 32bits
> - issue disappears when building ppccap.c with -O0 .
>
> So, I think that the probability that both XLC and GCC have
> About the possible "linker quirk", the same linker is used also for version
> 1.0.2h which runs perferctly.
Yes, but 1.0.2 and 1.1 ppccap's are different.
> Also, that does not explain why simply compiling ppccap.c only with -O0 makes
> the issue to dispappear.
Bugs seldom make sense. If the
101 - 200 of 820 matches
Mail list logo