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 don't have the time to actually get this done.

To clarify. As far as *this* specific remark goes, it's not like I feel
constrained, by policies or anything of the sort. It's rather about
"chronic" failure to find opportunity to put things aside and devote a
concentrated effort. The remark belongs in "what future holds" part. (As
most should know by now, I'm not on good terms with words.)
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[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 mitigate the apparent tendency to deviate from "upstream".
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[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 misguided expectations, but that's where I draw line for
myself. Another contributing factor is lack of opportunities to pursue
so to say "fundamental" goals, formal validation of assembly code being
one example. Just in case, I don't know what future holds exactly, but
it's not end of "crypto programming" for me, it's just that I won't be
lending my expertise directly/solely to this project on general basis.

As for my e-mail address. I'd like to argue that it would be appropriate
if it remains working for a while after, at the very least to see
through some of ongoing threads. I promise not to use it in context
other than purely technical.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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).
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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 saying is
>> that it would probably be appropriate to review them as they appear.
> 
> Is it #6915 you're talking about?

Updates to blinding are coming shortly.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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 a line, I would actually argue against
drawing the line as categorically as above. In sense that NULL checks
*can* be excessive, and thing is that such checks can jeopardize
application security. And in such case it wouldn't be totally
inappropriate to remove them, excessive checks, *without* renaming
function as suggested above. It would be kind of equivalent of changing
one undefined behaviour pattern for another undefined one. Or rather for
more "honest" undefined behaviour pattern:-)

As for jeopardizing application security, taking this case as an
example. What worked so far? Create stack without paying attention to
result[!], dump things into stack even if it's NULL, pull nothing if
it's NULL. Now imagine that this stack was some kind of deny list. If
entry producer didn't pay attention to error when creating stack and
putting things into it, consumer would be led to belief that there is
nothing to deny and let through the requests that are supposed to be
denied. This is kind of not-quite-right example in the context, because
it implies that *all* NULL checks should have been removed, thus making
*every* caller to pay attention, including consumer. While I left checks
in some of the consume operations reckoning that at least those who will
be putting things into NULL stack will have to pay attention and will
cancel whole operation hopefully without getting to pull-nothing step.
So that those entry producers who are not *currently* paying attention
would actually be caught. Which actually would be a positive thing!

Oh! Triggering factor was quite a number of unchecked pushes in apps.
Yes, you can sense contradiction in sense that one can't "fix" those
unchecked pushes with removal of NULL checks in questions. But they were
just something that made me look at stack.c and wonder above questions.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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...

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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 with 
> windows.
> 
> In my mind, this makes that more general vote ridiculous,

It certainly is, the vote should not be about such general principle.
It's way too general and most importantly *too natural* to vote about.
In sense that there are things that can't be voting matter. For example
"humans need air to breath" is not, and so is assertion that OpenSSL
needs libraries. And it's all but utterly natural to *minimize*
dependencies and make *minimum* assumptions. This means that one can
only vote on specifics, i.e. do we want specific dependency (at specific
level) or make specific assumption (at specific level). That's why
ballot should not be formulated "such as iconv", but *be* about iconv.

As for iconv per se. One has to recognize that it was standardized by
POSIX and one can expect it to be available on compliant system. Trick
is to reliably identify the said systems, and possibly by version, not
just by being X. So it's as important to have a fall-back to handle the
exclusions. As there will be exclusions. I can even name one already,
Android. And once again, I argue that there is even timing issue. It's
not right moment to make too broad assumptions about iconv availability
arguing that one is prepared to deal with issues. One can only argue
that it might be appropriate to enable it in cases one can actually
verify and confirm.
___
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-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. Sometimes
you don't have a choice. For example if you want to talk network on
Solaris, you have to link with -lsocket -lnsl. It's just part of the
game. But in cases one has a choice, well, one has a choice to *make*.
And key question is how do you anchor it. It's only natural to have as
little dependencies as possible, so question is what would justify extra
dependency.

> And perhaps we should also mention the pile of libraries used with windows.

It's not about amount, but ubiquity and stability. Windows is bad
example in the context, because it's rather "mono-cultural" environment.
But *otherwise* thing is that we already *know* that those extra
libraries work. Or at least know what to expect and how to deal with
them on different platforms. They were effectively proven to work by
lasting through several releases and years-long bug ironing. This *is*
factor too. And that's what made me pose "is b) part of vote" in my last
post.
___
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-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 control in the
> openssl application, so that it will do the best it can to make sure a
> pass phrase encoded with something other than UTF-8 gets correctly
> re-encoded, and failing that, try and make the user aware that they
> are about to create a non-interoperable object.  This triggered the
> use of the iconv API, and in the case of Mac OS/X, the use of the
> separate libiconv library.

I find the reference to Mac OS X a bit misleading, because it suggests
that assessment was made on limited amount of data points. Basically on
how does it look on *contemporary* Linux/Unix platforms and Mac OS X.
But question runs deeper than that and should cover all platform that we
consider supporting. Which covers even ranges of older versions, in
sense that judging on latest version alone is hardly sufficient. For
example do we know *when* was libiconv introduced to Mac OS X? One can
naturally say that we are not obliged to care about *that* old versions,
but this is no excuse for not making thorougher assessment? I mean it's
only appropriate if we can answer the question how old does system have
to be for us to say "we don't care". And same question applies even to
other platforms, OpenBSD, FreeBSD, Android, Cygwin, Solaris, AIX, HP-UX,
DJGPP, Tru64, IRIX, ... One can argue that iconv was actually
standardized, and in such case it would be appropriate to make it
conditional on _POSIX_VERSION. [Though it doesn't seem to be part of
pull request in question. Why not?] But as far as _POSIX_VERSION goes,
we kind of know that some systems by *default* offer lower version,
presumably in order to facilitate backward portability. So that it would
mean that we would have to explicitly rise the bar in some cases. Which
ones? And how high? This brings us to following question. Is *this*
actually right moment to introduce that kind of *multi-variable*
problem? In other words the problem kind of has two sides: a) principal,
to do or not to do; b) *when* would it be appropriate to start, is minor
release right moment? Is b) part of the vote?
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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
> (whether that's provided by the terminal driver, or the process
> holding the terminal, or the application itself...) rather than have
> them call setlocale() with appropriate arguments (which is needed for
> mbstowcs to work right).

Assertion is rather that we can't/shouldn't rely on application to call
setlocale and with argument suitable for specific purpose [of accessing
PKCS#12 in this case]. And since we can't do that, we would be better
off not calling mbstowcs. Because it adds a variable we have no control
over. Given some specific input it would be more honest/appropriate to
return error to application than to make outcome conditional on whether
or not application called setlocale and with which argument. One can
also view it as following: all applications get exactly same treatment.
Pushing applications and users toward UTF-8 input method is merely a
consequence of the suggestion to give all applications same treatment,
it's not alternative by itself.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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 precedent that they can refer to saying "it was always like
that, *your* application is broken, not ours." Also note that formally
speaking you can't blame them for demanding it. But you can blame them
for demanding it wrong. I mean they shouldn't try to communicate through
OU of self-signed certificate, but by terminating connection with
missing_extension alert, should they?
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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." Another "fun" part is that they don't seem to be concerned
with SNI value, it can be literally whatever.

>   posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25 
> CommonName invalid2.invalid
>   posttls-finger: certificate verification failed for
> gmail-smtp-in.l.google.com[173.194.66.26]:25:
> self-signed certificate
>   posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25:
> subject_CN=invalid2.invalid, issuer_CN=invalid2.invalid
>   posttls-finger: Untrusted TLS connection established to
> gmail-smtp-in.l.google.com[173.194.66.26]:25:
> TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)

Below case is -starttls smtp -tls1_2 [with of without servername].

> The same command with OpenSSL 1.1.0 yields (no CAfile/CApath
> so authentication fails where it would typically succeed):
> 
>   posttls-finger: certificate verification failed for
> gmail-smtp-in.l.google.com[173.194.66.27]:25:
> untrusted issuer /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
>   posttls-finger: gmail-smtp-in.l.google.com[173.194.66.27]:25:
> subject_CN=gmail-smtp-in.l.google.com,
> issuer_CN=Google Internet Authority G3,
>   posttls-finger: Untrusted TLS connection established to
> gmail-smtp-in.l.google.com[173.194.66.27]:25:
> TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)
> 
> This is a substantial behaviour change from TLS 1.2, and a rather
> poor decision on Google's part IMHO, though I'm eager to learn why
> this might have been a good idea.
> 
> In the mean-time, Richard's objection to automatic TLS 1.3 use
> after shared-library upgrade is starting to look more compelling?

Question is what would be users' expectation. If we arrange it so that
application compiled with 1.1.0 simply won't negotiate 1.3, then would
it be reasonable of them to expect that it will start working if they
simply recompile application? I.e. without changing application code!
But in such case it wouldn't actually help for example this case, but
only make things more confusing. I mean you end up with "all I wanted
1.3 and now it doesn't work at all". I'd say that it would be more
appropriate to make user ask "I want 1.3 but don't get it, why? it keeps
working with 1.2 though." With this in mind, wouldn't it be more
appropriate to simply not offer 1.3 capability if application didn't
provide input for SNI?
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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 these programs were built for.

Here is a thing. If we assume that 110/test/sslapitest.c is
*representative* example of an 1.1.0 application, then it's not at all
given that #5945 would actually solve anything. Indeed, observing the
first failing test, recompiled 110/test/sslapitest.c would still fail,
because it makes assumption that session id is available right after
negotiation, something that doesn't hold true for TLS 1.3. This gives
you either a) no 1.1.0 application goes safe, recompiled[!] or not; b)
110/test/sslapitest.c is not representative example. Well, as far as
first failing test goes, I'd say it's b), which means that it should be
adjusted in one way or another or failing check omitted. [It's b),
because it's unnatural to put session id you've just got back to id
cache, the test is ultimately synthetic.] This naturally doesn't answer
all the questions, but it does show that above mentioned premise is
somewhat flawed. I mean "programs were built for [1.1.0]" would still
work if recompiled with #5945.

>It also makes sense if we view TLSv1.3 as new functionality, and
>new functionality is usually only available to those who
>explicitely build their programs for the new library version.
>TLSv1.3 is unusual in this sense because it's at least it great
>part "under the hood", just no 100% transparently so.

In such case it should rather be #ifdef OPENSSL_ENABLE_TLS1_3 instead of
#ifndef OPENSSL_DISABLE_TLS1_3. And we don't want that.

To summarize, failing tests in 110 should be revisited to see if they
are actually representative, before one can consider as drastic measures
as #5945.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[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 closed.) As for my opinion I found myself objecting the way
SM2 is hammered into ec_pmeth.c, and it's irregardless concerns risen in
4793, which merely enforced the opinion. Concern is that we risk being
stuck with maintaining quirky behaviour for long time. It should really
be up to application to choose the scheme (as suggested in 4793) or SM2
methods should be parameterizeable. This means that I'd like to raise a
voice in favour of removal the hacks. If it means missing release, I'd
argue that it's better to miss it than to get stuck with something that
would be problematic to support.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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 serve meaningful purpose..."

Well, I also said that "I'm *not* saying that bit-rot is not a concern,
only that it's not really assembly-specific." And I can probably add
something here, in addition to already mentioned example of legacy code
relying on formally undefined or implementation-specific behaviour. It's
not actually that uncommon that *new* C code is committed[!!!]
"bit-rotten". So one can *just as well* say that supporting another
operating system has a cost, and so does using another compiler... Why
not get "angry" about that? What's the difference really? Relevant
question is what's more expensive, supporting multiple compilers?
multiple OSes? multiple assembly? To give a "tangible" example in the
context of forwarded message [that mentions PA-RISC assembly code.] How
long time did it take me to figure out what's wrong and verify that
problem is resolved? Couple of hours (mostly because old systems are
slw and it takes time to compile our stuff). How long time did it
take me to resolve HP-UX problems triggered by report on 20th of March?
I'm presumably[!] done by about now... To summarize, one can make same
argument about multiple things, yet we do them. Why? Because it works to
our advantage [directly or indirectly]...
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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 could *add* to rule. Or
> appro> let's rephrase this and say that you can simply specify multiple
> appro> commands in an override rule. So with this in mind.
> appro> 
> appro> link => [ 'script-that-composes-list-of-objects $@.$$',
> appro>   'link -o $@ -list $@.$$' ]
> 
> So zooming in on this particular idea, I was concerned about how those
> object file names would be passed to the script...  but then you
> mention manifests, and it dawns on me that there's *nothing* stopping
> us from generating a file with the list of object files when building
> the Makefile.  That does make some kind of sense to me.
> 
> Or were you thinking something different?

Well, when I said "manifest embedding" I meant specifically $(MT) step
of the link rule. But if you want to call $@.$$ output from
'script-that-composes-list-of-objects' for manifest, sure you can do that.

> It would of course be
> possible to have the script you suggest pull data from configdata.pm,
> right?

Or from Makefile, whichever simplest.

> But considering we're talking about third parties building
> their own, that raises another concern, that we suddenly give the
> whole %unified_info structure public exposure that I'm not entirely
> sure were ready for.

You mean not ready to commit to not changing it as our discretion? Well,
then maybe grep-ing Makefile for libcrypto.a: would be more appropriate...
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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, so something like this:
> appro> > 
> appro> >  link => '$(CCLD) $(LDFLAGS) -o $@ ...',
> appro> 
> appro> You've mentioned once that it would take a special language to do that
> appro> something, and I recall myself thinking "why not just use make syntax".
> appro> I'm unsure if I actually said this, but I did think the thought. So 
> that
> appro> I for one wouldn't actually be opposed to something like this. It's 
> just
> appro> a way to specify "override" rule (and on per-toolchain basis:-).
> appro> However! It all depends on whether or not straight make syntax would
> appro> actually be expressive enough in the context. If it is, then it would 
> be
> appro> totally appropriate. But if not, then ... I'm not so sure. Maybe[!]
> appro> if-else in makefile template could turn out to be more appropriate.
> appro> (Once again, each clause in if-else is isolated and complexity is
> appro> linearly proportional to number of clauses in if-else, which is viewed
> appro> as advantage.)
> 
> Straight make syntax will probably not cut it.  How would you pass a
> list of object file names to something that might have a limited
> command line length, for example?

These are actually two different problems, aren't they? I mean a) how do
you pass, and b) what if there is some limitation. As for former. Even
though it spells "use make syntax", it would still be rather
"make-*like* syntax". In other words it doesn't mean that you will be
able to just copy referred line into makefile, it would still have to be
processed somehow first. Well, in case at hand it might be possible to
drop a rule with $+ if you know you'll use GNU make, but others don't
understand it, so $+ would have to be processed. (And even in GNU make
case to keep things unified.) So you end up using mostly-make-like
syntax to formulate an override rule, but you do some replacements
before emitting actual rule into makefile. Naturally one might have to
make up more internally recognized make-looking idioms, in addition to
$+ that is...

> With nmake, we do have a feature we
> can use, the inline file text thing, but others may not be so lucky
> (the nonstop case I mentioned is such a case), and one might need to
> do a bit of pre-processing with perl-level variables (an idea could be
> to have some well defined hooks that users can define values for, such
> as function names...  again, this is a draft of an idea).  For
> example, imagine that we have something that dumps object file names
> into a text file and then expects that file name to appear in the
> linking command line (for example, and typically in our case), how do
> we pass the text file name to the command line, and where in the
> command line?

Do you mean that you have like 'libcrypto.so: all-the-object-files' and
want a rule that would put all-the-object-files into text file and
invoke linker with that file name as argument? And putting them into
text file may not exceed a length limit either, so that you can't say
for example 'echo $+ > o-files.$$.' either...

> So no, a straight makefile rule for a config attribute value isn't
> going to be good enough.

How about this. We have touched this when discussing windows-makefile. I
mean when I called it VC-specific, you disagreed, and I said that
embedding manifest effectively makes it VC-specific. In the context I
also suggested post-link stage, a command one could *add* to rule. Or
let's rephrase this and say that you can simply specify multiple
commands in an override rule. So with this in mind.

link => [ 'script-that-composes-list-of-objects $@.$$',
  'link -o $@ -list $@.$$' ]

Well, in this particular case you'd probably be more interested to
specify multi-line command instead of multiple commands. As '(trap "rm
-f $@.* INT 0; script ... && link ...)', because you might want to clean
up temporary file even if make is interrupted. But multi-line can be
useful if different lines reside in different templates. I mean base
template can say "link" and target can add a post-link command.

Of course I'm not suggesting to take this for immediate implementation,
these are just ideas to ponder about. They might turn unusable (or give
a spark for some other idea :-)
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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 ldflags. Yes, but I'd still be
reluctant to formulating it like that. As implied I'm kind of arguing
against too many options/variables/joints and call rather for
simplification than increased complexity. I feel that there are more
efficient ways to cover corner/odd-ball places...
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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, , inp++, 1);
>>> out += outl;
>>>   }
>>
>> This should work.
> 
> On second thought, perhaps not.

It seems that double-clarification is appropriate. As it stands now it
*does* work. So question is rather if it should keep working [and if
not, is it appropriate that stops working in minor release].

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[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);
out += outl;
}

[Just in case, corresponding corner case is effectively exercised in
evp_test.] Bernd argues that this is unreasonable, which I counter with
assertion that it doesn't matter how unreasonable this snippet is,
because since we support in-place processing, it's reasonable to expect
stream-cipher-like semantic as above to work even with block ciphers. As
it stands now, suggested modified code would accept in-place calls only
on block boundaries. Collateral question also is whether or not it would
be appropriate to make this kind of change in minor release.

Just in case, to give a bit of more general background. Benrd has shown
that current checks are not sufficient to catch all corner cases of
partially overlapping buffers. It was discussed that partially
overlapping is not same as fully overlapping, a.k.a. in-place
processing, with latter being in fact supported. And even though above
snippet can be formally viewed as a stretch, it's argued that it does
exhibit "legitimate intention" that deserves to be recognized and
supported. At least it was so far, in sense that it's not exactly a
coincidence that it currently works. [The fact that other corner cases
are not recognized as invalid is of course a bug, but there is no
contradiction, as fixing the bug doesn't have to mean that specific
corner case is no longer recognized.]

Thanks in advance.
___
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.
appears as ubsan failure...
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[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 verified by themselves, they rely on effectively unverified
compiler and its [unverifiable] ability to perform advanced
optimizations. Or in other words it's problematic on two levels: a) can
output from unvalidated compiler count as validated? b) will compilers
get performance right across a range of platforms? And as one can
imagine I imply that answer to both questions is "not really". As for
b). Well, current [x86_64] compilers were observed to generate decent
code that performs virtually on-par with assembly on contemporary
high-end Intel processors. At least for 2^51 radix customarily chosen
for C. Indeed, if you consider the improvement coefficients table in
x25519-x86_64.pl, you'll notice as low coefficients as 11%, 13%, 9% in
comparison to code generated by gcc-5.4. Normally it's not large enough
improvement [to subject yourself to misery of assembly programming],
right? But assembly does shine on non-Sandy Bridge and non-Haswell
processors, most notably in ADCX/ADOX cases. As for a). Intention is to
work with group at Academia Sinica to formally verify the
implementation. On related note they did verify amd64-51(*)
implementation that x25519-x86_64 refers to, so it wouldn't be
unprecedented.

Cheers.

(*) Just in case for reference. Being hardly readable, amd64-51 is hard
to integrate, because it targets specifically Unix ABI and is not
position-independent. It also performs sub-optimally on non-"Intel Core
family" processors, nor does it solve ADCX/ADOX problem. These are
arguments against taking in amd64-51 that is.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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));
>>  ^~~
>> %8llu
>> 2 errors generated.
>>
>>
>> The thing is though this is *our* BIO_printf, and we do seem to expect a
>> uint64_t for a "%ju". So I'm not sure how to fix that.
> 
> I'd suggest -Wno-format. With rationale that a) Xcode is arguably
> somewhat unreasonable, b) we can rely on Linux builds to catch warnings
> that actually matter.

Another possibility *could* be suppressing corresponding __attribute__
in bio.h, but it's public header, so question would be if change can be
justified in minor release. Just in case, suppress specifically for
Xcode [which would cover even iOS].
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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));
>  ^~~
> %8llu
> 2 errors generated.
> 
> 
> The thing is though this is *our* BIO_printf, and we do seem to expect a
> uint64_t for a "%ju". So I'm not sure how to fix that.

I'd suggest -Wno-format. With rationale that a) Xcode is arguably
somewhat unreasonable, b) we can rely on Linux builds to catch warnings
that actually matter.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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 pair of them fit into line. I mean

if (this-is-long
  && that
  && even-that)

vs.

if (this-is-long
  && that && even-that)

with first example being preferred. And this is even if 'this-is-long'
is short.

[Or should one tolerate following provided that 'this' is short enough?

if (this && that
  && even-that)
]

Either way, suggestion is that *if* you find yourself breaking condition
to multiple lines, you should take it step further, if not all the way.
But it shouldn't preclude things like

if (this-is-long
  && (that || (even-that && not-the-one))
  && don't-forget-this)

This actually means that one should be able to write second example as

if (this-is-long
  && (that && even-that))

but it would imply that logical relation between 'that' and 'even-that'
is strong enough to justify the parentheses.


[Also note that in above examples additional indentation is just two
spaces. It's not a coincidence, it's also kind of suggestion, for
if-specific indentation.]
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

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 that size_t customarily "covers" twice as much
space. So if you are to rely on positivity of signed value, object has
to be small enough. In other words you would have to perform sanity
checks before you do so. So it's not exactly walk on roses. I mean if
one assumes the premise that signed is "easier" to handle. Well, one can
make all kind of practical arguments about practicality of such
situation, i.e. what it takes to run into ptrdiff_t vs. size_t
ambiguity, and argue that it never happens. Well, while it would be case
on most systems, there are two cases, arguably not that impractical.
64-bit VMS, where we have sizeof(size_t)

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
https://mta.openssl.org/mailman/listinfo/openssl-project


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 mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project