Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Blumenthal, Uri - 0553 - MITLL]

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 clear that this is a new way of operating, and 
> openssl-project is a
>   moderated list.  Make sense?

I don’t know. I’d still do as I said. But since you guys discussed it (i.e., 
debated this option), I’ll defer to your judgment.



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Salz, Rich via openssl-dev]

➢ 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-project is a moderated list.  Make sense?

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

[Blumenthal, Uri - 0553 - MITLL]

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.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 project discussions
- New policy for accepting crypto algorithms, formats, and protocols.
- .. several others

Please read the posting; the changes described in it affect everyone who 
uses OpenSSL.  Thanks for your interest, and all your efforts to help improve 
the project!



-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Blog post; changing in email, crypto policy, etc

[Salz, Rich via openssl-dev]

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 project discussions
- New policy for accepting crypto algorithms, formats, and protocols.
- .. several others

Please read the posting; the changes described in it affect everyone who uses 
OpenSSL.  Thanks for your interest, and all your efforts to help improve the 
project!



-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Matt Caswell]

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_ADDR
> > ctrls should return an error on platforms that we don't know we can
> > support, i.e. attempt to detect (at compile time) whether we are on a
> > platform that we know has the required system calls - if we are then use
> > them, otherwise we do things the old way.
> 
> > Note that stuff like this is problematic:
> 
> > char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
> > in_pktinfo))];
> 
> > The "attribute" is compiler specific and not something we can rely on to
> > be available. Additionally "CMSG_SPACE" is probably not portable, and in
> > any case may not evaluate to a compile time constant (according to the
> > man page), so this is not C90 (which is a requirement for OpenSSL
> > submissions).
> 
> Understood.
> I think that CMSG_SPACE might be in the POSIX spec, but I'll double check.
> 
> What do you suggest I do for the IPv4 stuff, which has no POSIX standard?
> A bunch of #ifdef on OS definitions?

If its non portable and we're not already using it then that's the
probably the best we can do. We should try and provide some sensible
fallback wherever possible. Or if not possible it shouldn't break
anything that already works.

Matt
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Michael Richardson]

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 that we don't know we can
> support, i.e. attempt to detect (at compile time) whether we are on a
> platform that we know has the required system calls - if we are then use
> them, otherwise we do things the old way.

> Note that stuff like this is problematic:

> char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
> in_pktinfo))];

> The "attribute" is compiler specific and not something we can rely on to
> be available. Additionally "CMSG_SPACE" is probably not portable, and in
> any case may not evaluate to a compile time constant (according to the
> man page), so this is not C90 (which is a requirement for OpenSSL
> submissions).

Understood.
I think that CMSG_SPACE might be in the POSIX spec, but I'll double check.

What do you suggest I do for the IPv4 stuff, which has no POSIX standard?
A bunch of #ifdef on OS definitions?

> Once this PR is in (assuming it gets accepted), then you can look at
> what remains of your original PR and see if it makes sense to raise new
> PRs to bring the rest of it in.

Roger. Wilco.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

[Matt Caswell]

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 get our own address. You could then call that immediately after a
> > successful DTLSv1_listen() call. Obviously we'd have to change the
> > dgram BIO to use recvmsg for this to work.
> 
> That's here:
>
> https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c
>
> https://github.com/mcr/openssl/commit/50692219afe92762e85338b8d947e7ac732d2cde
> and:   
> https://github.com/mcr/openssl/commit/bb6f6b2cc860f25eb2b08aa109d1c7dc9ea94323

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 that we don't know we can
support, i.e. attempt to detect (at compile time) whether we are on a
platform that we know has the required system calls - if we are then use
them, otherwise we do things the old way.

Note that stuff like this is problematic:

char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
in_pktinfo))];

The "attribute" is compiler specific and not something we can rely on to
be available. Additionally "CMSG_SPACE" is probably not portable, and in
any case may not evaluate to a compile time constant (according to the
man page), so this is not C90 (which is a requirement for OpenSSL
submissions).

I suggest you Configure with the "--strict-warnings" option which will
probably complain about some of this stuff.

Please also make sure we have suitable documentation and ideally tests too.

Once this PR is in (assuming it gets accepted), then you can look at
what remains of your original PR and see if it makes sense to raise new
PRs to bring the rest of it in.

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev