OpenSSL_1_0_2-stable fa2ae04 RT3140: Possibly-unit variable in pem_lib.c
HEAD 0ff3687 RT3140: Possibly-unit variable in pem_lib.c
Author: Clang via Jeffrey Walton
Date: Tue Sep 2 17:04:53 2014 -0400
RT3140: Possibly-unit variable in pem_lib.c
Can't really happen, but the flow of control isn't o
On 09/02/2014 03:34 PM, Salz, Rich wrote:
> I think there's interest for 1.0.1 and beyond.
>
> But I thought we already had a similar alias mechanism?
With the version of openssl 1.0.1i that i have in front of me, "openssl
ciphers EDH" succeeds, but "openssl ciphers DHE" fails. So i don't
think
I think there's interest for 1.0.1 and beyond.
But I thought we already had a similar alias mechanism?
For HP-UX, be sure to install the latest linker patches. +sectionmerge has
been around for a long while, so you’ve probably got a lot of patches to
install. :)
TOM
On Sep 2, 2014, at 5:45 AM, Mrunal Nerpawar wrote:
> Hi
>
> zLinux:
> 1) ./config
> Configured for linux64-s390x.
> 2) make
On Mon 2014-05-12 15:18:35 -0400, Daniel Kahn Gillmor via RT wrote:
> I'm happy that the PFS key exchange normalization changesets have been
> merged into master.
>
> I've submitted https://github.com/openssl/openssl/pull/106 for the 1.0.2
> stable branch to add similar aliasing for the library inp
> You are right - it should not break anything as the patch only affects the ts
> app.
I put this on my dev branch for post-1.0.2 release:
https://github.com/akamai/openssl/tree/rsalz-monolith
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSa
On 02 Sep 2014, at 14:42, Brian Hassink via RT wrote:
> Sorry, I see there were some earlier posts on this very subject.
>
> Also, I found the following in RFC 6083 (section 1.1)...
>
> o The maximum user message size is 2^14 bytes, which is the DTLS limit.
>
> I wonder if the authors o
> > Of no less importance is to emphasise that it adds additional "keyform"
> > parameter to functions defined in ts.c and utilized by "-reply"
> > function, that will *break* compatibility with any previously existing code.
> How does it break? We don't care about source-level compatibility wit
Hi!
I've taken on this task recently, and you definitely raise a good point.
However, to be consistent with the other supported platforms, LP_find_file
should NOT skip over directories. Its up to the application to check them and
handle them appropriately. I'm working on making the appropriate cha
Sorry, I see there were some earlier posts on this very subject.
Also, I found the following in RFC 6083 (section 1.1)...
o The maximum user message size is 2^14 bytes, which is the DTLS limit.
I wonder if the authors of RFC 6733 (section 13.1) were aware of this
limitation when they s
Partial writes do not work over UDP; by design.
As to whether or not you can use a packet as big as 16K, in depends on the
"path MTU" -- what's the maximum transmission size between you and the
destination, along the communication path. You'll have to make your packets
smaller then that. This
We do have an open question in regards to DTLS/SCTP, and that is whether it is
possible to send messages larger than 16K?
In our application, such large messages are not uncommon.
We've tried setting the SSL_MODE_ENABLE_PARTIAL_WRITE flag with no success.
Thanks,
Brian
-Original Message---
> RFC 5280 requires that serial numbers MUST be positive, negative serial
> numbers do not conform with RFC (see 4.1.2.2).
Yes, thanks for the clarification.
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
_
Hi
zLinux:
1) ./config
Configured for linux64-s390x.
2) make
Error:
making fips in crypto...
make[1]: Entering directory `/builds/openssl/openssl-fips-ecp-2.0.5/crypto'
gcc -I. -I.. -I../include -DOPENSSL_FIPSCANISTER -fPIC -DOPENSSL_PIC
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -
Rich,
your reply is wrong, but your answer is OK.
Serial Numbers are not at all unsigned, since the type of serial numbers
is INTEGER in ASN.1, which are signed.
RFC 5280 requires that serial numbers MUST be positive, negative serial
numbers do not conform with RFC (see 4.1.2.2).
The serialNumbe
15 matches
Mail list logo