[openssl-users] stunnel 5.28 released

[Michal Trojnara]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Users,

I have released version 5.28 of stunnel.
This is a bugfix release.  I highly recommend upgrading your stunnel.

The ChangeLog entry:

Version 5.28, 2015.12.11, urgency: HIGH
* New features
  - Build matrix (.travis.yml) extended with ./configure options.
  - mingw.mak updated to build tstunnel.exe (thx to Jose Alf.).
* Bugfixes
  - Fixed incomplete initialization.
  - Fixed UCONTEXT threading on OSX.
  - Fixed exit codes for information requests (as
in "stunnel -version" or "stunnel -help").

Home page: https://www.stunnel.org/
Download:  https://www.stunnel.org/downloads.html

SHA-256 hashes:
9a25b87b1ef0c08fa3d796edce07b4408e6a8acece23de2eb7ee9285b78852b5
stunnel-5.28.tar.gz
020b5bd8a97a1da91e9b379c0d2fa8a14606402e2b0c1eb9191fe99c7f4665f9
stunnel-5.28-installer.exe
0af65879343b37bcda89dbbde51f6cfde016a044a533f7bdec229f4e1ec25eb9
stunnel-5.28-android.zip

Best regards,
Mike
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWarN7AAoJEC78f/DUFuAUKhcQAJ62DQW+GMpAmtggO42LhaEj
NcAdpgYvCAJnemRnTj+YMHHAGGIn7MY7VQZVzIIHL0y4CS6yy8kg1WVQeDgxS7PM
zil/CViLayNQUnEaUSpoD3yFlb5i6wqofPa5/ohObAvUwTejN/XtOlyT6OMTEovF
ZWWLsqYnVTCkbrY1Usu9DNRlSWaCgGeqL5ZqhbiJHk7hDHIH5Yy8KXKw3dVuOxBZ
86uYNH0WW3qNHKJrI1z70cA+18c6Kab5/4NnzzmWG+TyYCVVLL8JVkahEHhCX5mc
yBYcMyBrSkrUoS++IdEZtOKYjwxfiEFdre0junC1m5DqtbOc+vWcvqZRGUfCszHK
bg4LlCoNs6VhaAFzY9dyXKWqFP+HvH1cqcVcagCaofcdAEaFrwP4dqwUUBKCT44z
JNhEzyrI6+coGq92SZUeSiko2bj+rQWDf3s5pY+zWQVvUe12rTo427Mhbge3sBhQ
QykwMsihtrP9s25YkDQHqlpBV85W3axq/O2veb15QlbETDM6eGfnMCFjqhxpBBMO
sSgHOr9E1E4pxN4kcokPhwKizxSe0EHVQYM27qGfNXJkzVAvHE+mz0WR2kMPpjT5
N6th9lOMgrjXGo6aTBQO3DIEkw+BB0C9OVWnNXMWqmUnsKp80QVeZKZXgK5c2t1y
Y8e0W7HH2xdaQemUQp+n
=GrPO
-END PGP SIGNATURE-
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OCSP service dependant on time valid CRLs

[Erwann Abalea]

Bonjour,

The problem with signing with a default certificate is that the response 
certainly won’t be accepted by the client (see RFC6960 section 4.2.2.2, this 
responder certificate doesn’t follow criteria 1 and 2, and certainly not 
criteria 3), so you’re performing a signature knowing it will be rejected by a 
compliant client. It is also unwise from your side, because anybody can send a 
request for free, and as a result you’ll perform a signature: non negligible 
CPU cost and the response is larger than the request. An unsigned error message 
may be better.

« Unknown » is *a* correct answer in that specific case, not the only correct 
one. « tryLater » and « internalError » are equivalently correct answers. « 
Good », « malformedRequest », and « sigRequired » are NOT correct answers. « 
unauthorized » may also be considered a correct answer, but others may 
disagree. « Revoked » may seem a correct answer also, but not quite (see below).
The meaning of those different results is explained in RFC6960 and RFC5019.
Of course, if you’re using CRLs as an authoritative source of certificate 
status, RFC5280 is to be read also.

Reading the algorithm described in RFC5280 section 6.3.3 to perform a CRL 
validation, you’ll see that:
- at step (a)(1)(ii), you don’t get a newer CRL, so you can’t continue the 
algorithm
- after the algorithm, reasons_masks is still the empty set, and cert_status 
still has the value UNREVOKED, so the revocation status has NOT been determined
- last paragraph of 6.3.3 tells you that in the end, if the revocation status 
has not been determined, return a cert_status UNDETERMINED.

An OCSP service based on a CRL, given an expired CRL, running this normative 
algorithm, will get a cert_status « UNDETERMINED », and not a value stating 
that it’s revoked. Such an OCSP service, responding « Revoked », wouldn’t be 
strictly compliant.

Erwann Abalea
erwann.aba...@docusign.com

Le 10 déc. 2015 à 20:07, socket 
> a écrit :

Thanks for chiming in Erwann.  This OCSP service is CRL based. The software I 
am using has a "default signing certificate". I also have #X CA specific 
signing certificates for each CA in our lab PKI. It chooses to use the default 
signing certificate for all unknown issuers (like if someone explicitly queries 
the service for a microsoft timestamp certificate).

I appreciate your definitive response regarding  that the correct answer in 
this situation is to return unknown. I recognize your name as an authority in 
pkix, but is this documented anywhere? I would like to be able to justify to my 
customer that this is indeed the correct response.

Also, it seems weird to me that validating this certificate against the expired 
CRL returns a status of revoked, but when validating this same certificate 
against the OCSP service it says unknown. I guess i just have to get over that 
they are different and that a certificate can have a different status depending 
on who you ask.

Looking forward to any follow on thoughts...

--Dan

On Thu, Dec 10, 2015 at 2:32 PM Erwann Abalea-4 [via OpenSSL] <[hidden 
email]> wrote:
Bonsoir,

The OCSP responder can respond « unknown » if it doesn’t know the status of the 
requested certificate. « Unknown » can generally not be used when the issuer is 
not known, because such a response is signed, and if the responder doesn’t know 
about the issuer, it can’t choose its own certificate to use to sign the 
response.

If your OCSP responder is CRL based, and the CRL is not valid (badly encoded, 
wrong signature, incomplete in scope, expired, whatever…), « unknown » is a 
correct answer. « revoked » is also a correct answer if an expired CRL is found 
declaring the requested certificate as revoked. « tryLater » is also a correct 
answer, even « internalError » if we consider the CRL as part of the internal 
state of the responder.

Erwann Abalea
[hidden email]

Le 10 déc. 2015 à 18:29, socket <[hidden 
email]> a écrit :

Hi Walter,

I agree with your addition regarding the fact that it is not saying the cert is 
good, it's saying unknown. However, my understanding of the RFC is that unknown 
should be returned when the OCSP service does not know about the certificate 
issuer. I'm not sure that's the case.

Regarding the response verification, we are used the CA Designated Responder 
(Authorized Responder). meaning that the issuer of serial 0x500c8bd was the 
same issuer of the OCSP Signing response (ABC CA3 DEV). However, my testing 
shows that this only affects the "response verification (OK/FAILED)" not the 
certificate status returned (good/revoked/unknown).

--Dan

On Thu, Dec 10, 2015 at 11:36 AM Walter H. [via OpenSSL] <[hidden email]> wrote:
Hi Dan,

On 10.12.2015 16:27, daniel bryan wrote:
TEST #2: Next test was using OCSP:

[dan@canttouchthis PKI]$ openssl ocsp 

Re: [openssl-users] sign sub CA issue

[Ben Humpert]

Tell the person who created the CSR that the value of the
stateOrProvinceName field has to be HK. If that is not possible
because the subCA is in a different country you can change your
openssl.cnf to allow different values in that field so instead of
stateOrProvinceName = match you have to use at least
stateOrProvinceName = supplied

2015-12-11 15:18 GMT+01:00 Mohammad Jebran :
> Please can I have some advise on this query.
>
> Regards,
> Jebran.
>
> On Tue, Dec 8, 2015 at 11:18 AM, Mohammad Jebran  wrote:
>>
>> I have to sign a sub-CA through my current root CA using openSSLeverything
>> I have configured as per instructions but still getting an error that
>> "stateorProvanceName field needed to be the same" As mentioned below.
>>
>>
>>
>>
>>
>> root@machine:~/ImportantCACerts/intermediate# openssl ca
>> -configopenssl.cnf -extensions v3_intermediate_ca -days 3650 -notext -md
>> sha256 -in csr/subca2.csr -out certs/subca2.crt
>>
>> Using configuration from openssl.cnf
>>
>> Check that the request matches the signature
>>
>> Signature ok
>>
>> The stateOrProvinceName field needed to be the same in the
>>
>> CA certificate (HK) and the request (HK)
>>
>>
>>
>>
>>
>> Thanks & Regards,
>> Jebran.
>
>
>
> ___
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] sign sub CA issue

[Mohammad Jebran]

Please can I have some advise on this query.

Regards,
Jebran.

On Tue, Dec 8, 2015 at 11:18 AM, Mohammad Jebran  wrote:

> I have to sign a sub-CA through my current root CA using openSSLeverything
> I have configured as per instructions but still getting an error that
> "stateorProvanceName field needed to be the same" As mentioned below.
>
>
>
>
>
> *root@machine:~/ImportantCACerts/intermediate# openssl ca
> -configopenssl.cnf -extensions v3_intermediate_ca -days 3650 -notext -md
> sha256 -in csr/subca2.csr -out certs/subca2.crt*
>
> *Using configuration from openssl.cnf*
>
> *Check that the request matches the signature*
>
> *Signature ok*
>
> *The stateOrProvinceName field needed to be the same in the*
>
> *CA certificate (HK) and the request (HK)*
>
>
>
>
>
>
> *Thanks & Regards,Jebran.*
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Andy Polyakov]

>>> static inline unsigned int constant_time_msb(unsigned int a) {
>>> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
>>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
>>> }
>>
>>
>> ... Both versions
>> look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
>> bits).
> 
> Hardcoded 8 is not reference to char C type, but to units in which
> sizeof(variable) is measured. For example when we say ILP32 or LP64,
> what do we mean and what role does 8 play in the drama?

Well, one can argue that language standard doesn't actually dictate the
unit of sizeof(variable) to be 8-bit wide (only that it's *at least* 8,
right?), but we do so to say live in an "ILP" world and 8 is ubiquitous.

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Andy Polyakov]

>> static inline unsigned int constant_time_msb(unsigned int a) {
>> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
>> }
> 
> 
> ... Both versions
> look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
> bits).

Hardcoded 8 is not reference to char C type, but to units in which
sizeof(variable) is measured. For example when we say ILP32 or LP64,
what do we mean and what role does 8 play in the drama?

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] OSTIF

[Matt Caswell]

Hi all

I've had some emails recently from Derek at OSTIF who has been talking
to me about their plans to do an audit (separate to the current CII one)
of OpenSSL next year. OSTIF is not associated or affiliated with
OpenSSL, but if you're interested you can learn more here:
https://ostif.org/

Regards

Matt
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Andy Polyakov
> Sent: Friday, December 11, 2015 10:07
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in
> OpenSSL 1.0.2d
> 
> >> static inline unsigned int constant_time_msb(unsigned int a) {
> >> -*return 0 - (a >> (sizeof(a) * 8 - 1));*
> >> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
> >> }
> >
> >
> > ... Both versions
> > look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
> > bits).
> 
> Hardcoded 8 is not reference to char C type, but to units in which
> sizeof(variable) is measured. For example when we say ILP32 or LP64,
> what do we mean and what role does 8 play in the drama?

The distinction you're drawing is meaningless. The result of the sizeof 
operator is defined in terms of the C char type. Please refer to the C 
specification.

For example, referring to ISO 9899:1999 (because C11 is not widely used), 
please see 6.5.3.4, "The sizeof operator", items 2 and 3, and particularly the 
first sentence of #3: "When applied to an operand that has type char, unsigned 
char, or signed char, (or a qualified version thereof) the result is 1." 
sizeof(any-char-type) is ALWAYS 1, by definition.

Also note, from 6.5.3.4 #2: "The sizeof operator yields the size (in bytes) of 
its operand". In C, "byte" is a synonym for "char". It is NOT a synonym for 
"octet". The number of bits in a char (or byte) in C is specified by CHAR_BIT 
in . CHAR_BIT must be >= 8. (See 5.42.4.2.1, etc.)

Using a literal 8 here assumes CHAR_BIT == 8. It would be better, in terms of 
portability, to include  and use CHAR_BIT here. However, my guess is 
that getting OpenSSL working on platforms where CHAR_BIT > 8 would require 
substantial effort and would likely be pointless; if no one's asking for it, no 
one's likely to use it. (Also, such platforms are generally DSPs which are not 
likely to be able to run OpenSSL anyway.)

All of these points have already been made in this thread, except for the C 
citations (and with occasional errors such as "the unit for sizeof is chars not 
bytes" - that's a contradictory statement, since "byte" is a term of art in the 
C specification and is identical to "char").

-- 
Michael Wojcik
Technology Specialist, Micro Focus

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] sign sub CA issue

[Mohammad Jebran]

Thanks guys, Its done.
​
Regards,
Jebran.

On Fri, Dec 11, 2015 at 7:18 PM, Mohammad Jebran  wrote:

> Please can I have some advise on this query.
>
> Regards,
> Jebran.
>
> On Tue, Dec 8, 2015 at 11:18 AM, Mohammad Jebran 
> wrote:
>
>> I have to sign a sub-CA through my current root CA using openSSLeverything
>> I have configured as per instructions but still getting an error that
>> "stateorProvanceName field needed to be the same" As mentioned below.
>>
>>
>>
>>
>>
>> *root@machine:~/ImportantCACerts/intermediate# openssl ca
>> -configopenssl.cnf -extensions v3_intermediate_ca -days 3650 -notext -md
>> sha256 -in csr/subca2.csr -out certs/subca2.crt*
>>
>> *Using configuration from openssl.cnf*
>>
>> *Check that the request matches the signature*
>>
>> *Signature ok*
>>
>> *The stateOrProvinceName field needed to be the same in the*
>>
>> *CA certificate (HK) and the request (HK)*
>>
>>
>>
>>
>>
>>
>> *Thanks & Regards,Jebran.*
>>
>
>
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] sign sub CA issue

[Jakob Bohm]

1. Check if the certificate for your root CA specifies any
  "path restrictions" or similar that says that it cannot
  validly sign certificates outside some state or province.
   Having such restrictions in a root CA is GOOD whenever
  possible, because it limits the damage that can be done
  if the CA security is compromised, and because it limits
  the reasons other people might not want to install your
  root CA into their browsers/mail programs/computers.

2. Check if the settings in your openssl.cnf file specify
  that the "StateOrProvince" field needs to have a
  specific value when running the CA command.

If #1 is the issue, you cannot change it without
regenerating the self-signed root CA cert (using the same
key etc. for an easier transition) and then install the
new version of this cert in all the computers and programs
where the old version was installed.

If #2 is the issue, all you need to do is to find and
change that line in openssl.cnf .  That line almost
certainly says "StateOrProvince" on it, so it should
be easy to find.

On 11/12/2015 15:18, Mohammad Jebran wrote:

Please can I have some advise on this query.

Regards,
Jebran.

On Tue, Dec 8, 2015 at 11:18 AM, Mohammad Jebran > wrote:


I have to sign a sub-CA through my current root CA using
openSSLeverything I have configured as per instructions but still
getting an error that "stateorProvanceName field needed to be the
same" As mentioned below.

/root@machine:~/ImportantCACerts/intermediate# openssl ca
-configopenssl.cnf -extensions v3_intermediate_ca -days 3650
-notext -md sha256 -in csr/subca2.csr -out certs/subca2.crt/

/Using configuration from openssl.cnf/

/Check that the request matches the signature/

/Signature ok/

/The stateOrProvinceName field needed to be the same in the/

/CA certificate (HK) and the request (HK)/




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Build failure with OpenSSL version 1.0.2e in Win32 platform

[Matt Caswell]

On 11/12/15 15:46, Abdul Razik wrote:
> Hello
> 
> Can someone please help with this issue? I am trying to build version
> 1.0.2e with VS 2015 and got the following build error with 32 bit, 64
> bit builds fine ,
> 
> searching online it seems to have been resolved, not sure how to get
> the fix and which files are affected by the fix. Can someone please
> help with this?

>From INSTALL.W32:
- Netwide Assembler, a.k.a. NASM, available from
http://nasm.sourceforge.net/
  is required if you intend to utilize assembler modules. Note that NASM
  is now the only supported assembler.

See the instructions later in that file for how to use it to build OpenSSL.

Matt



___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Andy Polyakov]

>>> C does not make such a guarantee, though recent-ish POSIX does.  (This
>>> system is a windows one, thought, right?)
>> There are DSPs that only support 32 bit, they don't have a concept
>> of 8 bit.  But I think there is various code that assumes that
>> char is 8 bit, and I doubt you can get OpenSSL working on such a
>> system.
>>
> Target in question is traditional 32 bit ARM with 32 bit
> instructions and 8 bit char.
> 
> Looks like a hard to fix compiler bug to me.

While assessment that code presented in disassembler output lacks a
number of &0xFF is absolutely correct, it's not *necessarily* proof of a
compiler bug (but read to the end, please). Trouble is that since
functions are static compiler is free to trim them as it suits local
goal in any given module. For example consider disassembler output for
constant_time_eq_8 from x86_64 test/constant_time_test.o compiled by gcc
4.8:

:
xor%esi,%edi
lea-0x1(%rdi),%eax
not%edi
and%edi,%eax
sar$0x1f,%eax
retq

Note no mask either! [Note that it even replaced 0-(a>>(sizeof(a)*8-1))
with arithmetic shift!] However! This does *not* mean that suggestion
about compiler bug is rejected, it only means that you can't use lack of
&0xFF in presented disassembler output as definitive proof.

constant_time_msb was pinpointed as culprit. But I can certify that
binary code generated for 0 - (a >> (sizeof(a) * 8 - 1)) *alone* is
actually correct. It should be and is

mov rX, rY, lsr #31
rsb rZ, rX, #0

[Unless compiler recognizes it as equivalent of arithmetic shift, like
gcc did above]. But as it gets inlined in *real* usage cases, compiler
will subject it to all possible kind of optimizations and in process can
loose track of things, which would be definition of compiler bug. In
other words one can't dismiss the suggestion that it is a compiler
bug... More reliable to way to tell if it's indeed a compiler bug is to
disable optimizations. So I'd suggest to do that. Not to do that and
leave it like that if it works, but to *determine* if we are looking at
compiler bug or not.

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Build failure with OpenSSL version 1.0.2e in Win32 platform

[Abdul Razik]

Hello

Can someone please help with this issue? I am trying to build version
1.0.2e with VS 2015 and got the following build error with 32 bit, 64
bit builds fine ,

searching online it seems to have been resolved, not sure how to get
the fix and which files are affected by the fix. Can someone please
help with this?



perl crypto\sha\asm\sha1-586.pl win32 /MT /Ox /O2 /Ob2
-DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo
-DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_C

RT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES

_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_NO_RC5
-DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE
-DOPENSSL_NO_DYNAMIC_ENGINE >tmp32\sha1-586.asm

ml /nologo /Cp /coff /c /Cx /Zi /Fotmp32\sha1-586.obj tmp32\sha1-586.asm

Assembling: tmp32\sha1-586.asm

tmp32\sha1-586.asm(1432) : error A2070:invalid instruction operands

tmp32\sha1-586.asm(1576) : error A2070:invalid instruction operands

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 14.0\VC\BIN\ml.EXE"' : return code '0x1'

Stop.



Thanks

Razik


-- 
Abdul Razik
Mobile: 512 550 4282
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Andy Polyakov]

On 12/11/15 17:41, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
>> Of Andy Polyakov
>> Sent: Friday, December 11, 2015 10:07
>> To: openssl-users@openssl.org
>> Subject: Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in
>> OpenSSL 1.0.2d
>>
 static inline unsigned int constant_time_msb(unsigned int a) {
 -*return 0 - (a >> (sizeof(a) * 8 - 1));*
 + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1;
 }
>>>
>>>
>>> ... Both versions
>>> look reasonable to me (ignoring the hardcoded 8 - implying a char is 8
>>> bits).
>>
>> Hardcoded 8 is not reference to char C type, but to units in which
>> sizeof(variable) is measured. For example when we say ILP32 or LP64,
>> what do we mean and what role does 8 play in the drama?
> 
> The distinction you're drawing is meaningless.

Right, I've let practical myself talk too soon, sorry. Yet we do adhere
to ILP notion when describing platform requirement, so 8 is kind of
implied anyway. But in case one chooses to switch to CHAR_BIT. I want to
remind that not all platforms OpenSSL [still] supports are sufficiently
standard compliant. There are platforms that are *partially* compliant
or stuck between standards. But I'd say that it would be safe to assume
that if CHAR_BIT is not defined, then it's 8.

> (Also, such platforms are generally DSPs which are not likely to be
> able to run OpenSSL anyway.)

As fun fact, OpenSSL does run on TI C6000 series DSP and even optimized
for C64x+ and forward.

Anyway, this has little to do with problem at hand, as all assumptions
made implicitly or explicitly do apply to the platform in question. If
it turns to be compiler bug, then no argument about standard compliance
would justify it. And we'll face the usual dilemma, do we give in and
arrange a kludge (e.g. with #ifdef _MSC_VER), or send user to said
compiler vendor... Latter is kind of counter-productive, former is
...

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

[Jeffrey Walton]

> 3. The compiler wasn't written by a fanatic who put
>   the "right shift of negative signed values is
>   undefined" rule above common sense.
>
> This is only implementation-defined behavior, not undefined behavior.  It is
> not permitted to crash the system or launch the missiles.  (n1256.pdf 6.5.7
> paragraph 5.)

The potential problem with implementation defined is its not
guaranteed to produce consistent results. Different compilers or
different versions of the same compiler may arrive at different
results.

In this light, the crash might be welcomed to make it easy to find the
trouble spot :)
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users