Re: [openssl-project] External contributors and the next release

2018-03-06 Thread Benjamin Kaduk
On Wed, Mar 07, 2018 at 03:01:03PM +1000, Tim Hudson wrote:
> If you are blocked on review please drop a note (like the one you just did)
> to the group.
> Some of us review the specifically blocked things when such notes are sent.
> 
> #3082 is already closed and merged - did you mean another PR?

Yup, I meant #3802, sorry.
(tmshort is my team lead at work)

> #3958 approved (in case Richard doesn't get back to it)
> #1130 approved
> #3958 approved

Thanks!

-Ben

> Tim.
> 
> 
> 
> On Wed, Mar 7, 2018 at 2:40 PM, Benjamin Kaduk  wrote:
> 
> > On Wed, Mar 07, 2018 at 01:20:41AM +, Salz, Rich wrote:
> > > I think we should make sure to set aside time to review as many of the
> > non-project pull requests as possible.  I think it is important to show a
> > commitment to the larger community.
> >
> > I agree.  I started looking at this last week, when we had something
> > like 170 open issues+pull requests for the 1.1.1 milestone.  We
> > still have 165, and that excludes a couple things that I would like
> > to see get in but are not part of the milestone (like #3082 and
> > #1130).  I also have several changes open myself that are small and
> > could easily go in, though none of them are especially critical.
> > (Richard, could you reconfirm on #3958, though, please?)
> >
> > > One way to do this is to say that we will extend the BETA date by a
> > week, and in that week no new code from the team, only third-party existing
> > pull requests will be considered
> >
> > I'm open to extending the date, though am interested to see what we
> > can do if everybody chips in this week.  (Though, I myself will only
> > be able to start on Friday, as my next couple days are fully
> > booked.)
> >
> > -Ben
> > ___
> > openssl-project mailing list
> > openssl-project@openssl.org
> > https://mta.openssl.org/mailman/listinfo/openssl-project
> >

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

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


Re: [openssl-project] External contributors and the next release

2018-03-06 Thread Tim Hudson
If you are blocked on review please drop a note (like the one you just did)
to the group.
Some of us review the specifically blocked things when such notes are sent.

#3082 is already closed and merged - did you mean another PR?
#3958 approved (in case Richard doesn't get back to it)
#1130 approved
#3958 approved

Tim.



On Wed, Mar 7, 2018 at 2:40 PM, Benjamin Kaduk  wrote:

> On Wed, Mar 07, 2018 at 01:20:41AM +, Salz, Rich wrote:
> > I think we should make sure to set aside time to review as many of the
> non-project pull requests as possible.  I think it is important to show a
> commitment to the larger community.
>
> I agree.  I started looking at this last week, when we had something
> like 170 open issues+pull requests for the 1.1.1 milestone.  We
> still have 165, and that excludes a couple things that I would like
> to see get in but are not part of the milestone (like #3082 and
> #1130).  I also have several changes open myself that are small and
> could easily go in, though none of them are especially critical.
> (Richard, could you reconfirm on #3958, though, please?)
>
> > One way to do this is to say that we will extend the BETA date by a
> week, and in that week no new code from the team, only third-party existing
> pull requests will be considered
>
> I'm open to extending the date, though am interested to see what we
> can do if everybody chips in this week.  (Though, I myself will only
> be able to start on Friday, as my next couple days are fully
> booked.)
>
> -Ben
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] External contributors and the next release

2018-03-06 Thread Benjamin Kaduk
On Wed, Mar 07, 2018 at 01:20:41AM +, Salz, Rich wrote:
> I think we should make sure to set aside time to review as many of the 
> non-project pull requests as possible.  I think it is important to show a 
> commitment to the larger community.

I agree.  I started looking at this last week, when we had something
like 170 open issues+pull requests for the 1.1.1 milestone.  We
still have 165, and that excludes a couple things that I would like
to see get in but are not part of the milestone (like #3082 and
#1130).  I also have several changes open myself that are small and
could easily go in, though none of them are especially critical.
(Richard, could you reconfirm on #3958, though, please?)

> One way to do this is to say that we will extend the BETA date by a week, and 
> in that week no new code from the team, only third-party existing pull 
> requests will be considered

I'm open to extending the date, though am interested to see what we
can do if everybody chips in this week.  (Though, I myself will only
be able to start on Friday, as my next couple days are fully
booked.)

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


[openssl-project] External contributors and the next release

2018-03-06 Thread Salz, Rich
I think we should make sure to set aside time to review as many of the 
non-project pull requests as possible.  I think it is important to show a 
commitment to the larger community.

One way to do this is to say that we will extend the BETA date by a week, and 
in that week no new code from the team, only third-party existing pull requests 
will be considered
___
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-03-06 Thread Bernd Edlinger
Hi,

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) - X, *out = buf;
EVP_EncryptUpdate(ctx, out, , , sizeof(head));
out += outl;
EVP_EncryptUpdate(ctx, out, , in, X);
out += outl;
EVP_EncryptUpdate(ctx, out, , , sizeof(tail));
out += outl;

with X > 75% sizeof(buf)
sizeof(head), sizeof(tail) not necessary multiple of block size

And make the definition of allowed in-place partially overlapping
effectively be driven by the implementation requirements.


Bernd.

On 03/03/18 13:25, Bernd Edlinger wrote:
> On 03/01/18 10:59, Andy Polyakov wrote:
> 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.

>>>
>>> It does only work, if you know that ctx->buf_len == 0
>>> before the loop is entered.
>>
>> It's naturally implied that ctx is used *consistently*. I mean it's not
>> like it's suggested that you can just use the above snippet in random
>> place. Application would have to adhere to above pattern all along, for
>> the life time of in-place processing "session". [I write "session" in
>> quotes, because there might be better term.]
>>
>>> It does not work with CFB1, CCM, XTS and WRAP modes.
>>
>> Yes, some modes are so to say "one-shot", i.e. you have to pass all the
>> data there is at once, no increments are allowed. But what does it have
>> to do with question at hand, question about in-place processing that is?
>> These two things are independent. So that question is rather should the
>> snippet work in cases when incremental processing is an option. 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.
>> Note that ctx->block_size for CFB1, CCM and XTS is 1. As for WRAP, yeah,
>> it's special...
>>
>>> There is no access function to get the internal state of the cipher
>>> context.
>>
>> But there is notion of in-place processing "session".
>>
> 
> Well, I'd say, apparently the consensus is at least not to restrict
> what is currently recognized as "fully" overlapping.
> 
> All depends obviously on how "partially" overlapping is defined:
> a) by humans
> b) by OpenSSL
> 
> a)
> I think humans would normally say two objects are partially overlapping
> when they overlap, but do not fully overlap, in other words partially
> overlapping in and out do have some common bytes, but do not start at
> the same address, thus in != out.
> 
> b)
> What is currently recognized as partially overlapping in the evp_enc.c
> is a) but adds some I would say ad-hoc exceptions to accommodate one
> special use case with certain block ciphers.  Yet it does for instance
> artificially restrict use cases where other ciphers work just fine.
> 
> I think for instance of WRAP mode, where the primitive basically
> supports arbitrary overlapping (uses memmove) but we can no longer
> use that feature because of the partially overlapping check in the
> EVP cipher handling.
> 
> And the other use case, which I think is worth to mention is
> 
> unsigned char *inp = buf + sizeof(buf) - 1, *out = buf;
> for (i = 0; i      *inp = getc();
>      EVP_EncryptUpdate(ctx, out, , inp, 1);
>      out += outl;
> }
> 
> This could work for some cipher modes at least.
> 
> And I think our overall assumption here is the user knows perfectly
> well how the internal state of the ctx is at any time, otherwise
> EVP_EncryptUpdate would probably need to have an input parameter to
> tell how large the output buffer is in reality :)
> 
> So I think maybe we can just change the definition for b) to be
> 
> Partially overlapping is any kind of overlapping that is known to be
> not working in the evp cipher update function.
> It is dependent on the cipher mode, and dependent on the internal state
> of the cipher context.
> 
> It is often the case that partially overlapping means overlapping
> with in != out but most importantly the code in evp_enc.c is known
> to fail if it was allowed to continue after EVP_R_PARTIALLY_OVERLAPPING.
> 
> 
> Bernd.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project