> 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
> 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
>
> - 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
> 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
>> - 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
> 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
> 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.
___
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
> 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.
> 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...
___
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
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).
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
> 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
> 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."
> ... 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
> 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
>> 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
> 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,
> 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
>>> 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, ,
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, , inp++, 1);
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
>> 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
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
29 matches
Mail list logo
