On 1/19/18, 12:52, "Salz, Rich" wrote:
>> It appears to me that you could use openssl-dev instead of openssl-project,
>> saving cycles on killing
>> one and creating the other.
>
> We discussed that, but it would be harder to “undo” if things don’t work
> out, we wanted
> to make it very c
➢ It appears to me that you could use openssl-dev instead of openssl-project,
saving cycles on killing one and creating the other.
We discussed that, but it would be harder to “undo” if things don’t work out,
we wanted to make it very clear that this is a new way of operating, and
openssl-p
It appears to me that you could use openssl-dev instead of openssl-project,
saving cycles on killing one and creating the other.
--
Regards,
Uri Blumenthal
On 1/19/18, 12:35, "openssl-dev on behalf of Salz, Rich via openssl-dev"
wrote:
There’s a new blog post at
https://www.opens
There’s a new blog post at
https://www.openssl.org/blog/blog/2018/01/18/f2f-london/
It contains some important policy changes we decided at our meeting last month.
This includes:
- Closing the openssl-dev mailing list; use GitHub for issues
- New mailing list openssl-project for pro
On 19/01/18 16:32, Michael Richardson wrote:
> Matt Caswell wrote:
> > Please raise a separate PR for this work. It *must* be portable though
> > and work across all our platforms (e.g. including VisualC etc). My
> > suggestion is that your BIO_CTRL_DGRAM_GET_ADDR/BIO_CTRL_DGRAM_SET_
Matt Caswell wrote:
> Please raise a separate PR for this work. It *must* be portable though
> and work across all our platforms (e.g. including VisualC etc). My
> suggestion is that your BIO_CTRL_DGRAM_GET_ADDR/BIO_CTRL_DGRAM_SET_ADDR
> ctrls should return an error on platforms th
On 17/01/18 16:34, Michael Richardson wrote:
>
> > It seems like a fairly simple solution could solve this. Currently we
> > have BIO_dgram_get_peer() which returns the peer's address for the last
> > message read from a BIO. You could imagine a new call being introduced
> > to g