Re: questions on using ed25519
Sure, I can help. It's my pleasure to help with the project. Since you have opened an issue. Then what should I do? Nicola Tuveri 于2020年4月24日周五 下午11:17写道： > That's right! Thanks Viktor for pointing that out!! > > I just opened an issue to track this: > https://github.com/openssl/openssl/issues/11633 > > We warmly welcome contributions from everyone and this could be a good > first issue to work on: Yang (as the person that started this thread and > noticed the issue first) or anyone else from the community, are you willing > to get your hands dirty and help out the project? > > > Nicola > > > On Thu, 23 Apr 2020 at 19:33, Viktor Dukhovni > wrote: > >> On Thu, Apr 23, 2020 at 11:23:35AM +0200, Nicola Tuveri wrote: >> >> > > On 22/04/2020 18:12, Viktor Dukhovni wrote: >> > > > sadly the >> > > > EVP_PKEY_METHOD for ed25519 has a NULL sign() member, instead, >> somewhat >> > > > ironically, it has a digestsign() method. This is presumably to >> > > > distinguish between the pure and prehash variants. Therefore, >> presently >> > > > pkeyutl(1) indeed appears to not implement signing and verifying >> with >> > > > ed25519, this looks doable with modest effort. >> > > >> > > I'm fairly sure it used to have a "sign" function during the dev >> phase - >> > > but it was taken out. I forget the reasoning. >> > >> > Yes, that change was intentional, the reasoning is detailed in the >> > discussion in: https://github.com/openssl/openssl/pull/6284 >> >> This did leave us with a documentation bug, the dgst(1) manpage suggests >> using pkeyutl(1) for ed25519 and ed448, but the latter does not work. >> >> The dgst(1) manpage probably needs a tweak to remove the misleading >> redirect. Or else backport the pkeyutl(1) support from 3.0, but we're >> not supposed to add features in 1.1.1x patch releases, and there are no >> plans for a 1.1.2. >> >> -- >> Viktor. >> >
Re: OpenSSL version 3.0.0-alpha1 published
I would normally refrain but ... On 25/04/2020 23:24, Salz, Rich via openssl-users wrote: Yes, nice, why not reduce compile time and save prescious compiler memory by getting rid of all-inline one-liners. And link-time collapsing the identical code. I think this is an issue on some Solaris, for example. Sorry for coming over sarcastic, i am listening to "This monkeys gone to heaven" from The Pixies (from the 80s), it seemed due :-)) Henh. I can give a boatload of Boston bands. Sometimes while working on OpenSSL I think of https://www.youtube.com/watch?v=F6z0Cv4PYvs ( https://www.youtube.com/watch?v=PDhiUh82dOo
Re: OpenSSL version 3.0.0-alpha1 published
Salz, Rich wrote in <05c099a8-261f-43df-a59a-97ccf030f...@akamai.com>: |>Yes, nice, why not reduce compile time and save prescious compiler |memory by getting rid of all-inline one-liners. | |And link-time collapsing the identical code. I think this is an issue \ |on some Solaris, for example. | |> Sorry for coming |over sarcastic, i am listening to "This monkeys gone to heaven" |from The Pixies (from the 80s), it seemed due :-)) | |Henh. I can give a boatload of Boston bands. Sometimes while working \ |on OpenSSL I think of https://www.youtube.com/watch?v=F6z0Cv4PYvs ( Nice. Yes. I am hatching a bit on the story behind that.. But then again, the Killing Joke went on stage again after meeting on the funeral of one of their members, so something's about it. My interpretation. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: OpenSSL version 3.0.0-alpha1 published
>Yes, nice, why not reduce compile time and save prescious compiler memory by getting rid of all-inline one-liners. And link-time collapsing the identical code. I think this is an issue on some Solaris, for example. > Sorry for coming over sarcastic, i am listening to "This monkeys gone to heaven" from The Pixies (from the 80s), it seemed due :-)) Henh. I can give a boatload of Boston bands. Sometimes while working on OpenSSL I think of https://www.youtube.com/watch?v=F6z0Cv4PYvs (
Re: OpenSSL version 3.0.0-alpha1 published
On Fri, Apr 24, 2020 at 01:26:05PM +0200, Yann Ylavic wrote: > > - DH_bits(dh) (used for logging only in httpd) > Replaced by BN_num_bits(DH_get0_p(dh)). > Not sure this one should be deprecated, it seems to be used in several > places in openssl codebase still, no replacement? I think the replacement is using the EVP_PKEY API and then use EVP_PKEY_bits() Kurt
Re: OpenSSL version 3.0.0-alpha1 published
Hello Rich Salz,
Salz, Rich wrote in
:
|>I do not understand one thing at the moment. If i use
|no-deprecated then the stack handling is not available:
|
|If you use no-deprecated you have to use DEFINE_STACK_OF in exactly \
|one file. And use DECLARE_STACK in your common header file.
|Let me know if this works, or not, for you.
Yep, it works fine, it is only necessary in xtls.c.
Yes, nice, why not reduce compile time and save prescious compiler
memory by getting rid of all-inline one-liners. Sorry for coming
over sarcastic, i am listening to "This monkeys gone to heaven"
from The Pixies (from the 80s), it seemed due :-))
Can we expect that the oddity that Yann Ylavic reported
({SSL_CTX,X590_STORE}_load_verify_{dir,path}(), wrong glob:) stays
as such? (I turned to Landslide of Fleetwood Mac..)
Ciao, a nice Sunday, (and Good luck!),
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: opensssl 1.1.1g test failure(s)
On Wed, Apr 22, 2020 at 11:02:47AM +0200, Michael Tuexen wrote:
> > On 22. Apr 2020, at 10:38, Matt Caswell wrote:
> >
> >
> >
> > On 21/04/2020 23:45, Michael Tuexen wrote:
> >>> Looks like the failing call is here:
> >>>
> >>> if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
> >>> (const void *), sizeof(on)) != 0) {
> >> Can you provide a pointer to the code?
> >
> > Yes, its here:
> >
> > https://github.com/openssl/openssl/blob/fa555aa8970260c3e198d91709b2d4b3e40f8fa8/crypto/bio/b_sock2.c#L267-L282
> OK. Thanks.
>
> Could it be that on == 0, when you do the setsockopt() call? Disabling
> IPV6_V6ONLY seems not to be supported
> on OpenBSD:
Yes:
if (BIO_ADDR_family(addr) == AF_INET6) {
/*
* Note: Windows default of IPV6_V6ONLY is ON, and Linux is OFF.
* Therefore we always have to use setsockopt here.
*/
on = options & BIO_SOCK_V6_ONLY ? 1 : 0;
if (setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY,
(const void *), sizeof(on)) != 0) {
So something is calling BIO_listen without setting BIO_SOCK_V6_ONLY
in options. All calling functions really should set BIO_SOCK_V6_ONLY
if they actually support multiple sockets, and they should.
Kurt
Re: OpenSSL version 3.0.0-alpha1 published
Steffen Nurpmeso wrote in
<20200425210613.scjxn%stef...@sdaoden.eu>:
|Hello once more.
|
|OpenSSL wrote in
|<20200423142936.ga24...@openssl.org>:
|| OpenSSL version 3.0 alpha 1 released
|
|I do not understand one thing at the moment. If i use
|no-deprecated then the stack handling is not available:
|
| /*
| * If we're building OpenSSL, or we have no-deprecated configured,
| * then we don't define the inline functions (see |SKM_DEFINE_STACK_OF|,
| * above), we just declare the stack datatypes. Otherwise, for compatibil\
| ity
| * and to not remove the API's, we define the functions. We have the
| * trailing semicolon so that uses of this never need it.
| */
| #if defined(OPENSSL_BUILDING_OPENSSL) || defined(OPENSSL_NO_DEPRECATED_3\
| _0)
| # define DEFINE_OR_DECLARE_STACK_OF(s) STACK_OF(s);
|
|This of course results in all the stack things not being
|available, for example
|
| /.../xtls.c:1444:20: warning: implicit declaration of function 'sk_X509_\
| num'; did you mean 'X509_new'? [-Wimplicit-function-declaration]
| for (i = 0; i < sk_X509_num(certs); ++i) {
|
|How can i access stacks without those accessors?
|Is this documented somewhere, i stopped searching for answers
|anywhere else, which is why i write this.
Hihihi, after sending this mail i thought i go git, and indeed
i found
commit 852c2ed260
Author: Rich Salz
AuthorDate: 2019-12-19 17:30:24 -0500
Commit: Tomas Mraz
CommitDate: 2020-04-24 16:42:46 +0200
In OpenSSL builds, declare STACK for datatypes ...
So i try that now.
Ciao from Germany, a nice Sunday, and Good luck!
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: OpenSSL version 3.0.0-alpha1 published
>I do not understand one thing at the moment. If i use no-deprecated then the stack handling is not available: If you use no-deprecated you have to use DEFINE_STACK_OF in exactly one file. And use DECLARE_STACK in your common header file. Let me know if this works, or not, for you.
Re: OpenSSL version 3.0.0-alpha1 published
Hello once more.
OpenSSL wrote in
<20200423142936.ga24...@openssl.org>:
| OpenSSL version 3.0 alpha 1 released
I do not understand one thing at the moment. If i use
no-deprecated then the stack handling is not available:
/*
* If we're building OpenSSL, or we have no-deprecated configured,
* then we don't define the inline functions (see |SKM_DEFINE_STACK_OF|,
* above), we just declare the stack datatypes. Otherwise, for compatibility
* and to not remove the API's, we define the functions. We have the
* trailing semicolon so that uses of this never need it.
*/
#if defined(OPENSSL_BUILDING_OPENSSL) || defined(OPENSSL_NO_DEPRECATED_3_0)
# define DEFINE_OR_DECLARE_STACK_OF(s) STACK_OF(s);
This of course results in all the stack things not being
available, for example
/.../xtls.c:1444:20: warning: implicit declaration of function 'sk_X509_num';
did you mean 'X509_new'? [-Wimplicit-function-declaration]
for (i = 0; i < sk_X509_num(certs); ++i) {
How can i access stacks without those accessors?
Is this documented somewhere, i stopped searching for answers
anywhere else, which is why i write this.
Ciao and thank you,
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
