> Multiline conditionals, such as in an if, should be broken before the
> logical connector and indented an extra tabstop. For example:
>
>
>
> while (this_is_true
> && that_is_not_false) {
> frobit();
> more_stuff();
> }
One has to recognize that this is
> - Don't use else after return?
I'd argue against making it an absolute requirement. To give an example.
You don't a problem with returns in switch, so why should it be a
problem with returns from switch-like if-elseif chain?
___
openssl-project mailing
> What else needs to be updated?
Relax requirement that argument names in function definition has to
match function declaration to permit adding 'unused_' prefix prior
unused arguments.
___
openssl-project mailing list
openssl-project@openssl.org
https:/
>> - Use size_t for sizes of things
>
> How do you feel about ssize_t?
One has to keep in mind that ssize_t is not part of C language
specification, but POSIX thing. C specification defines ptrdiff_t with
[presumably] desired properties. However, there is natural ambiguity
originating from fact t
> Multiline conditionals, such as in an if, should be broken before the
> logical connector and indented an extra tabstop. For example:
One can wonder if it would be appropriate to explicitly say that
preferred way to organize multi-line conditionals with same chain
condition per line even if pai
> I think this belongs in CHANGES or NEWS, not with every single
> reconfigure build
>
>
> Creating Makefile
>
>
> NOTE: Starting with OpenSSL 1.1.1, 'Configure' doesn't display all the
> disabled
> options or the "make variables" with their values. Instead, you must use
> 'configdata.pm' as a
> In master and OpenSSL_1_1_0-stable we have:
>
> commit df8c39d52256c2e5327a636928b6d1ed05f695a2
> Author: Rich Salz
> Date: Tue Sep 30 17:30:19 2014 -0400
>
> RT3549: Remove obsolete files in crypto
>
> Reviewed-by: Andy Polyakov
>
> c
> apps/enc.c:568:54: error: format specifies type 'uintmax_t' (aka
> 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned
> long long') [-Werror,-Wformat]
> BIO_printf(bio_err, "bytes written: %8ju\n",
> BIO_number_written(out));
>
>> apps/enc.c:568:54: error: format specifies type 'uintmax_t' (aka
>> 'unsigned long') but the argument has type 'uint64_t' (aka 'unsigned
>> long long') [-Werror,-Wformat]
>> BIO_printf(bio_err, "bytes written: %8ju\n",
>> BIO_number_written(out));
>>
For the record. I don't generally appreciate fast commits, but I feel
like 100 times stronger when it comes to public headers [naturally in
supported or minor release] and I can't qualify 19 minutes turnaround
for merge request as appropriate.
___
openssl
> (side note: I've just started compiling the ia64 code on VMS. It currently
> bombs for reasons I haven't fathomed yet, but am thinking it's a pointer size
> thing...
You ought to generate assembly listing for 'int foo(int *p) {return
*p;}' with different flags and send it to me. I told you tha
Hi,
A word of clarification about recently introduced x25519-x86_64 module.
Specifically in the context of an apparently common shift toward
auto-generated C such fiat-crypto or hacl64. As far as I'm concerned
problem with just mentioned auto-generated C implementations is that
while being verifie
> Just a reminder to everyone that we are doing the alpha2 release
> tomorrow, so we will be freezing the repo soon (in about an hour or so).
master is read at https://travis-ci.org/openssl/openssl/branches since
https://github.com/openssl/openssl/commit/b38ede8043439d99a3c6c174f17b91875cce66ac.
a
> ssh openssl-...@git.openssl.org freeze openssl matt
done.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
Hi,
I'd like to request more opinions on
https://github.com/openssl/openssl/pull/5427. Key dispute question is
whether or not following fragment should work
unsigned char *inp = buf, *out = buf;
for (i = 0; i < sizeof(buf); i++) {
EVP_EncryptUpdate(ctx, out, &outl, inp++, 1);
> Collateral question also is whether or not it would
> be appropriate to make this kind of change in minor release.
One can wonder if this is actually more burning question. But keep in
mind that ...
> ... there is no
> contradiction, as fixing the bug doesn't have to mean that specific
> corner
>>> I'd like to request more opinions on
>>> https://github.com/openssl/openssl/pull/5427. Key dispute question is
>>> whether or not following fragment should work
>>>
>>> unsigned char *inp = buf, *out = buf;
>>>
>>> for (i = 0; i < sizeof(buf); i++) {
>>> EVP_EncryptUpdate(ctx, out, &o
>>> I'd like to request more opinions on
>>> https://github.com/openssl/openssl/pull/5427. Key dispute question is
>>> whether or not following fragment should work
>>>
>>> unsigned char *inp = buf, *out = buf;
>>>
>>> for (i = 0; i < sizeof(buf); i++) {
>>> EVP_EncryptUpdate(ctx, o
> Related
> thing to recognize in the context is that *disputable* condition, the
> one that triggered this discussion, is exercised only when
> ctx->block_size is larger than 1, because then ctx->buf_len remains 0.
I naturally meant "because *otherwise* ctx->buf_len remains 0". In other
words ctx
> Andy pointed out that my last e-mail was probably not clear enough.
>
> I want to drop the current partially overlapping checks
> on the WRAP mode ciphers (which were ineffective anyways).
>
> And allow the following additional use case for any cipher
>
> unsigned char *in = buf + sizeof(buf)
>> Note: this mail follows the discussion on github started here:
>> https://github.com/openssl/openssl/pull/5742#discussion_r176919954
In the light of the new evidence presented in
https://github.com/openssl/openssl/pull/5745 one can argue in favour of
splitting -pthread flag to cppflags and ldfl
> appro> We already touched this in Windows context, one option (more suitable
> in
> appro> my mind) is toolchain-specific *rules*. I.e. instead of trying to fit
> appro> cube into circular hole, just make square hole on the side. For example
> appro> *if* target has ldonly attribute, just emit l
> Note: this mail follows the discussion on github started here:
> https://github.com/openssl/openssl/pull/5742#discussion_r176919954
> That discussion started as a simple side note, but I should probably
> have known better... it ends up derailing a PR that shouldn't really
> be affected, so I'm
> appro> > Another side thing that I've been thinking of for quite a while, and
> I
> appro> > think you may have argued for even though I feel a bit unsure, and
> appro> > that's to support command line attributes as an alternative to that
> appro> > increasing amount of specialised attributes, s
> appro> How about this. We have touched this when discussing windows-makefile.
> I
> appro> mean when I called it VC-specific, you disagreed, and I said that
> appro> embedding manifest effectively makes it VC-specific. In the context I
> appro> also suggested post-link stage, a command one could
On 03/09/18 17:13, Bernd Edlinger wrote:
> On 03/08/18 12:06, Andy Polyakov wrote:
>>
>>> Andy pointed out that my last e-mail was probably not clear enough.
>>>
>>> I want to drop the current partially overlapping checks
>>> on the WRAP mode ciphers
> Once again:
> - This PR *recognizes* the fact that special cases do in fact *exist*.
??? Is there application that heavily relies on some specific overlap
percentage?
> - The EVP layer has to be more aware of special cases anyhow.
Where does it come from? Why does it *have to* be more aware of
> This is one reason why keeping around old assembly code can have a cost. :(
>
> https://github.com/openssl/openssl/pull/5320
There is nothing I can add to what I've already said. To quote myself.
"None of what I say means that everything *has to* be kept, but as
already said, some of them serve
Hi,
I'd like to hear *more* opinions in light of recent comments to
https://github.com/openssl/openssl/pull/4793. (Strangely enough I get
"This page is taking way too long to load" if attempt to access it when
I'm logged on[!?]. But I have no problems opening requests from the
middle, long closed.
> 2. Make TLSv1.2 the absolutely maximum TLS version available for
>programs linked with libssl 1.1.0. This is what's done in this PR:
>https://github.com/openssl/openssl/pull/5945
>This makes sense insofar that it's safe, it works within the known
>parameters for the library these
> When I link posttls-finger with the OpenSSL 1.1.1 library, I see:
Just in case for reference, one can reproduce all this with 1.1.1
s_client. Below case is -starttls smtp -noservername. "Fun" part is that
OU for the self-signed certificate reads "No SNI provided; please fix
your client." Another
> ... what does not make any sense to me is what Google is doing. Snatching
> defeat from the jaws of victory by needlessly forcing clients to downgrade to
> TLS 1.2. Is there a justification for this?
It can either be a probe just to see if it's reasonable to demand it, or
establish a precede
> I think that the gist of the difference of opinion is whether it's OK
> to use locale dependent functions such as mbstowcs in libcrypto or
> not.
>
> The main arguments against allowing such functions in libcrypto is
> that we should push applications to run with an UTF-8 input method
> (whether
> This PR has been blocked, forcing a vote:
>
> https://github.com/openssl/openssl/pull/6392
>
> Background: we have been sloppy when producing PKCS#12 files, creating
> objects that aren't interoperable. This can only happen with non-UTF8
> input methods, so this PR adds a higher level of c
> Regarding general use of other libraries, please think carefully before
> voting, 'cause this *is* tricky. If you have a look, you will see that we
> *currently* depend on certain standard libraries, such as, for example, libdl.
One has to recognize that each dependency has to be justified. So
> Regarding general use of other libraries, please think carefully before
> voting, 'cause this *is* tricky. If you have a look, you will see that we
> *currently* depend on certain standard libraries, such as, for example,
> libdl. And perhaps we should also mention the pile of libraries used w
> Forthcoming OpenSSL releases
>
I have some RSA hardening fixes in pipeline...
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
>>> Forthcoming OpenSSL releases
>>>
>>
>> I have some RSA hardening fixes in pipeline...
>
> Do you have PR numbers for them?
"in pipeline" kind of means "not yet [but I'll intensify the work to put
them out]". In other words it's a pre-heads-up thing...
___
>>> Forthcoming OpenSSL releases
>>>
>>
>> I have some RSA hardening fixes in pipeline...
>
> Do you suggest we wait with a release on that, or can we just put
> it in the next release?
I should be able to pull it off in before release. What I'm saying is
that it woul
> Should not be changed period. Even across major release boundaries.
> This is not an ABI compatibility issue, it is a source compatibility
> issue, and should avoided all the time. If we want to write a *new*
> function that skips the NULL checks it gets a new name.
While I admittedly crossed
> Forthcoming OpenSSL releases
>
I have some RSA hardening fixes in pipeline...
>>>
>>> Do you suggest we wait with a release on that, or can we just put
>>> it in the next release?
>>
>> I should be able to pull it off in before release. What I'm sayi
It would be appropriate to merge
https://github.com/openssl/openssl/pull/6916 (1.0.2, commit message
would need adjustment for merged from) and
https://github.com/openssl/openssl/pull/6596 (1.1.0, was marked "pending
for 2nd" but it's apparently ready).
_
I'm dropping out in a week time. It's not some single recent thing, but
combination. I don't see that my perception of project spirit aligns
with current state of affairs. This goes for both technical aspects and
policies (lack of, and/or their applications). One can probably say that
these are mis
As once said, what matters at the end of the day is whether or not
versioning scheme is *accepted* by "downstream". And by "accepted" I
mean to degree that ROBOT wouldn't have happened to Facebook. In other
words first question should not be how to arrange digits and letters,
but rather how to miti
>> Another contributing factor is lack of opportunities to pursue
>> so to say "fundamental" goals, formal validation of assembly code being
>> one example.
>
> Formal validation of the assembly code is something I would
> actually like to see, and even talked with some people about it.
> But I do
45 matches
Mail list logo