On 21/02/18 01:19, Andrei Danaila wrote:
> Any insight would be greatly appreciated.
>
All OpenSSL versions before 1.1.0 provide no symbol version information.
However Debian distribute a patched version of OpenSSL that adds this -
so this is why you will see a difference between your system su
> Interesting comment :
>
>
> Solaris x86 with Sun C setups
> # There used to be solaris-x86-cc target, but it was removed,
> # primarily because vendor assembler can't assemble our modules
> # with -KPIC flag. As result it, assembly support, was not even
> # available as opt
> https://github.com/openssl/openssl/pull/5423
I wonder how come the problem with asn1_encode_test.c went unnoticed so
far. Objects on stack are customarily aligned at pointer size, even if
their declaration doesn't imply corresponding guarantee. So there are
two options here: a) it's first time i
This is very useful! Can you post an udate to the wiki?
https://wiki.openssl.org/index.php/Binaries
On 2/21/18, 8:57 AM, "Angus Robertson - Magenta Systems Ltd"
wrote:
Windows developers may be interested in our Win32 build of OpenSSL
1.1.1-pre1 (alpha), the binaries are digitally
> On Feb 21, 2018, at 5:06 AM, Andy Polyakov wrote:
>
> I wonder how come the problem with asn1_encode_test.c went unnoticed so
> far. Objects on stack are customarily aligned at pointer size, even if
> their declaration doesn't imply corresponding guarantee. So there are
> two options here: a)
I'm trying to update a crypto library for crtmpserver to work with openssl
1.1.0. The software is no longer actively maintained and my c++ skills are
somewhat rudimentary but I keep getting a compilation error for something
that seems trivial.
Here's the code snippet:
bool DHWrapper::CopyPublicKe
On 02/21/2018 10:16 AM, Robert Watson wrote:
> I'm trying to update a crypto library for crtmpserver to work with
> openssl 1.1.0. The software is no longer actively maintained and my
> c++ skills are somewhat rudimentary but I keep getting a compilation
> error for something that seems trivial.
>
On 21/02/18 16:20, Benjamin Kaduk via openssl-users wrote:
> On 02/21/2018 10:16 AM, Robert Watson wrote:
>> I'm trying to update a crypto library for crtmpserver to work with
>> openssl 1.1.0. The software is no longer actively maintained and my
>> c++ skills are somewhat rudimentary but I keep
On 21/02/18 09:14 AM, Viktor Dukhovni wrote:
On Feb 21, 2018, at 5:06 AM, Andy Polyakov wrote:
I wonder how come the problem with asn1_encode_test.c went unnoticed so
far. Objects on stack are customarily aligned at pointer size, even if
their declaration doesn't imply corresponding guarante
> On Feb 21, 2018, at 11:42 AM, Dennis Clarke wrote:
>
> On 21/02/18 09:14 AM, Viktor Dukhovni wrote:
>>> On Feb 21, 2018, at 5:06 AM, Andy Polyakov wrote:
>>>
>>> I wonder how come the problem with asn1_encode_test.c went unnoticed so
>>> far. Objects on stack are customarily aligned at poin
Thanks for suggestion, don't understand why the compiler didn't complain
about the first argument. Unfortunately, that just brings out other
problem
code:
bool DHWrapper::CopyPublicKey(uint8_t *pDst, int32_t dstLength) {
if (_pDH == NULL) {
FATAL("DHWrapper not initialized");
On 2/21/2018 8:42 AM, Dennis Clarke wrote:
Pretty sure I have done builds and tests. In fact I am certain of it.
If you added -xmemalign=8s to the SPARC compiler flags (as shown in one
of your emails from yesterday) then you would not see the problem.
-xmemalign=8s forces the compiler to use
On 21/02/18 12:11 PM, Norm Green wrote:
> On 2/21/2018 8:42 AM, Dennis Clarke wrote:
>> Pretty sure I have done builds and tests. In fact I am certain of it.
>
> If you added -xmemalign=8s to the SPARC compiler flags (as shown in one
> of your emails from yesterday) then you would not see the prob
On 2/21/2018 9:42 AM, Dennis Clarke wrote:
Which is correct way to do this on sparc systems.
Why do you say that? We've been building OpenSSL on SPARC for the past
7 years without that flag and it's worked just fine with only a few
minor changes to the compile/link flags.
Norm
--
openssl-
On 21/02/18 12:57 PM, Norm Green wrote:
On 2/21/2018 9:42 AM, Dennis Clarke wrote:
Which is correct way to do this on sparc systems.
Why do you say that? We've been building OpenSSL on SPARC for the past
7 years without that flag and it's worked just fine with only a few
minor changes to th
On 2/20/2018 9:34 AM, J Decker wrote:
> Client does a verification and passes or fails, and via the SSL layer
> I can query if the client validated the certificate.
> If it failed, provide a option for the client to get a renewed
> certificate for verification. If success, no action.
> If an actor
On 21/02/18 12:57 PM, Norm Green wrote:
On 2/21/2018 9:42 AM, Dennis Clarke wrote:
Which is correct way to do this on sparc systems.
Why do you say that? We've been building OpenSSL on SPARC for the past
7 years without that flag and it's worked just fine with only a few
minor changes to th
> So really we could do all manner of nasty things here and watch all
> manner of performance results and cool coredumps and it would be fun to
> try. However the option -xmemalign=8s will enforce "There should be no
> misaligned accesses in the program".
And "the default for all v9 architectures
I'm capturing from my DTLS client and server, with CoAP running on top.
I've been debugging some ruby-level I/O buffering issues.
I noticed this while capturing, and used tshark to get this print out.
(I've added columns for port numbers)
2 66.009171 ::2 35345 ::2 5684 DTLSv1
On 2/21/2018 12:46 PM, Andy Polyakov wrote:
And "the default for all v9 architectures is -xmemalign=8s".
I'm getting confused. Since I did not specify -xmemalign at all, why
did the test fail with SIGBUS in the first place? Seems like there
should have been no alignment problem if the compile
>> And "the default for all v9 architectures is -xmemalign=8s".
> I'm getting confused. Since I did not specify -xmemalign at all,
And not specifying -xmemalign is equivalent of specifying 8s in 64-bit
build such as one in question.
> why
> did the test fail with SIGBUS in the first place? Seem
On 21/02/18 21:38, Michael Richardson wrote:
>
> I'm capturing from my DTLS client and server, with CoAP running on top.
> I've been debugging some ruby-level I/O buffering issues.
> I noticed this while capturing, and used tshark to get this print out.
> (I've added columns for port numbers)
>
22 matches
Mail list logo