Re: [openssl-project] dropping out

2018-10-12 Thread Andy Polyakov
>> 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

[openssl-project] speaking of versioning schemes

2018-10-12 Thread Andy Polyakov
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

[openssl-project] dropping out

2018-10-12 Thread Andy Polyakov
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

Re: [openssl-project] Please freeze the repo

2018-08-13 Thread Andy Polyakov
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).

Re: [openssl-project] Forthcoming OpenSSL releases

2018-08-13 Thread Andy Polyakov
> 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

Re: [openssl-project] Removal of NULL checks

2018-08-09 Thread Andy Polyakov
> 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

Re: [openssl-project] Forthcoming OpenSSL releases

2018-08-07 Thread Andy Polyakov
>>> 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...

Re: [openssl-project] Forthcoming OpenSSL releases

2018-08-07 Thread Andy Polyakov
> 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

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-10 Thread Andy Polyakov
> 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

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Andy Polyakov
> 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.

Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Andy Polyakov
> 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

Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-01 Thread Andy Polyakov
> 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 >

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-18 Thread Andy Polyakov
> ... 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

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-18 Thread Andy Polyakov
> 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."

Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-15 Thread Andy Polyakov
> 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

[openssl-project] SM2

2018-04-09 Thread Andy Polyakov
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

Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

2018-04-06 Thread Andy Polyakov
> 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

Re: [openssl-project] rule-based building attributes

2018-03-27 Thread Andy Polyakov
> 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

Re: [openssl-project] rule-based building attributes (Re: cppflags, cflags and ldflags)

2018-03-26 Thread Andy Polyakov
> 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,

Re: [openssl-project] cppflags, cflags and ldflags

2018-03-25 Thread Andy Polyakov
>> 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

Re: [openssl-project] to fully overlap or not to

2018-03-01 Thread Andy Polyakov
> 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

Re: [openssl-project] to fully overlap or not to

2018-02-28 Thread Andy Polyakov
>>> 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, ,

[openssl-project] to fully overlap or not to

2018-02-28 Thread Andy Polyakov
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);

Re: [openssl-project] Freezing the repo soon

2018-02-26 Thread Andy Polyakov
> 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

Re: [openssl-project] Freezing the repo soon

2018-02-26 Thread Andy Polyakov
> 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.

[openssl-project] x25519-x86_64

2018-02-21 Thread Andy Polyakov
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

Re: [openssl-project] OS/X builds failing

2018-02-09 Thread Andy Polyakov
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. ___

Re: [openssl-project] OS/X builds failing

2018-02-09 Thread Andy Polyakov
>> 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)); >>

Re: [openssl-project] OS/X builds failing

2018-02-09 Thread Andy Polyakov
> 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)); >

Re: [openssl-project] Style guide updates

2018-01-28 Thread Andy Polyakov
> 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

Re: [openssl-project] Style guide updates

2018-01-27 Thread Andy Polyakov
>> - 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

Re: [openssl-project] Style guide updates

2018-01-26 Thread Andy Polyakov
> 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

Re: [openssl-project] Style guide updates

2018-01-26 Thread Andy Polyakov
> - 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