Bug#862207: error: libcrypto does not provide GOST
28.04.2022 19:22, Ondřej Surý wrote: On 28. 4. 2022, at 15:23, Michael Tokarev wrote: Yeah. Formally we should do either one or another. In practice I *highly* doubt anyone is using these 4 symbols, so maybe we can just disable the thing without doing anything. I'm too lazy now to provide the stubs :) Yeah, I concur. I would recommend doing such upload to experimental first and then we can add couple of versioned Breaks if we find any problems. I see no reason to go to experimental here. I checked all rdepends of libldns3, - none are using any gost symbols. -exp wont do anything useful there I think. It is not the first time I see people suggesting uploading stuff in experimental. Sometimes I do that too (not counting the case like we had with the python transition, and a risk to delay the transition further in case of a problematic upload to unstable) - when I'm not sure if the changes I did are okay and I want to give it some wider testing and when I *know* someone can help me by explicitly install the experimental stuff. But for things like this, I *think* -exp is useless, it wont show anything which we don't know already. Did I miss something? Thank you! /mjt
Bug#862207: error: libcrypto does not provide GOST
> On 28. 4. 2022, at 18:34, Michael Tokarev wrote: > > I see no reason to go to experimental here. I checked all rdepends > of libldns3, - none are using any gost symbols. -exp wont do > anything useful there I think. Ok, then. > But for things like this, I *think* -exp is useless, it wont show > anything which we don't know already. It’s just easier to test this “in place”, that’s all. Ondrej -- Ondřej Surý (He/Him) ond...@sury.org signature.asc Description: Message signed with OpenPGP
Bug#862207: error: libcrypto does not provide GOST
> On 28. 4. 2022, at 15:23, Michael Tokarev wrote: > > Yeah. Formally we should do either one or another. > In practice I *highly* doubt anyone is using these 4 > symbols, so maybe we can just disable the thing without > doing anything. I'm too lazy now to provide the stubs :) Yeah, I concur. I would recommend doing such upload to experimental first and then we can add couple of versioned Breaks if we find any problems. Ondrej -- Ondřej Surý (He/Him) ond...@sury.org signature.asc Description: Message signed with OpenPGP
Bug#862207: error: libcrypto does not provide GOST
28.04.2022 15:27, Ondřej Surý wrote: .. Yes, it’s the old one. The 2012 hasn’t been specified for use in DNSSEC - there was a draft, but it has expired. Ok, that makes sense. Thank you for clarification. Please note there are at least 4 symbols in the libldns3 library which are gost-related: .. We can keep the symbols as dummy shims, so the package doesn’t have to bump SOVERSION. Yeah. Formally we should do either one or another. In practice I *highly* doubt anyone is using these 4 symbols, so maybe we can just disable the thing without doing anything. I'm too lazy now to provide the stubs :) .. There are no GOST signatures used in real world deployments, there’s no need to have validation enabled anywhere. Keeping obsoleted algorithm alive is not doing anybody any favor. I for one have no objections whatsoever against removal it besides the extra work which is needed. To me it is like, don't touch it if it does not disturb anyone. FWIW, for me the whole GOST thing is weird, I'd not have/use it at all to begin with. In some contexts it is required though. /mjt
Bug#862207: error: libcrypto does not provide GOST
> On 28. 4. 2022, at 14:09, Michael Tokarev wrote: > > 27.04.2022 12:08, Ondřej Surý wrote: >> Hi, >> GOST has been deprecated for use in DNSSEC, and the >> actual standard actually says it MUST NOT be used for >> signing (and MAY be used for verification), see RFC 8624. >> I think the best course of action here is to actually disable it >> everywhere where GOST R 34.10-2001 is used as it has >> been superseded by GOST R 34.10-2012 in [RFC7091]. > > I don't know which version(s) of GOST is enabled in ldns > when built with --enable-gost[-anyway]. Do you? Yes, it’s the old one. The 2012 hasn’t been specified for use in DNSSEC - there was a draft, but it has expired. There’s an effort to add GOST-2012 to DNSSEC, but it’s still a draft: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ But that’s only tangential. The GOST-2001 needs to be eradicated from DNS. > Please note there are at least 4 symbols in the libldns3 > library which are gost-related: > > ldns_gost2pkey_raw@Base 1.7.1 > ldns_gost_engine@Base 1.7.1 > ldns_key_EVP_load_gost_id@Base 1.7.1 > ldns_key_EVP_unload_gost@Base 1.7.1 We can keep the symbols as dummy shims, so the package doesn’t have to bump SOVERSION. > I'm not sure here, but it looks like we'll have to > bump the library soname when removing these symbols. > > To me it looks like not worth the effort. Especially > since we "MAY" (as the RFC suggests) need it to verify > some old signatures anyway. There are no GOST signatures used in real world deployments, there’s no need to have validation enabled anywhere. Keeping obsoleted algorithm alive is not doing anybody any favor. Ondrej -- Ondřej Surý (He/Him) ond...@sury.org signature.asc Description: Message signed with OpenPGP
Bug#862207: error: libcrypto does not provide GOST
27.04.2022 12:08, Ondřej Surý wrote: Hi, GOST has been deprecated for use in DNSSEC, and the actual standard actually says it MUST NOT be used for signing (and MAY be used for verification), see RFC 8624. I think the best course of action here is to actually disable it everywhere where GOST R 34.10-2001 is used as it has been superseded by GOST R 34.10-2012 in [RFC7091]. I don't know which version(s) of GOST is enabled in ldns when built with --enable-gost[-anyway]. Do you? Please note there are at least 4 symbols in the libldns3 library which are gost-related: ldns_gost2pkey_raw@Base 1.7.1 ldns_gost_engine@Base 1.7.1 ldns_key_EVP_load_gost_id@Base 1.7.1 ldns_key_EVP_unload_gost@Base 1.7.1 I'm not sure here, but it looks like we'll have to bump the library soname when removing these symbols. To me it looks like not worth the effort. Especially since we "MAY" (as the RFC suggests) need it to verify some old signatures anyway. Thanks, /mjt
Bug#862207: error: libcrypto does not provide GOST
Hi, GOST has been deprecated for use in DNSSEC, and the actual standard actually says it MUST NOT be used for signing (and MAY be used for verification), see RFC 8624. I think the best course of action here is to actually disable it everywhere where GOST R 34.10-2001 is used as it has been superseded by GOST R 34.10-2012 in [RFC7091]. If we get a bugreport about GOST being disabled, it should be rejected with the reference to RFC 8624. Cheers, Ondrej -- Ondřej Surý (He/Him) ond...@sury.org > On 26. 4. 2022, at 17:28, Michael Tokarev wrote: > > Control: tag -1 + moreinfo > > On Tue, 9 May 2017 21:44:45 +0200 martin f krafft wrote: >> Package: ldnsutils >> Version: 1.7.0-1 >> Severity: normal >> When trying ti use ldns-key2ds with -g, I get an error about GOST >> not being available. >> % ldns-key2ds -g -n _combined.key >> error: libcrypto does not provide GOST >> Either the option should be disabled, or ldns-key2ds linked with >> a libcrypto that provides GOST. > > Well, GOST comes as an add-on to libcrypto. So if you install > such an add-on on your system, everything will work. If we > disable GOST for ldns, we'll got another bugreport, saying > GOST is not enabled even if ldns supports it. > > I think it's best to keep it the way it is now, how do you think? > > /mjt > signature.asc Description: Message signed with OpenPGP
Bug#862207: error: libcrypto does not provide GOST
Regarding the following, written by "Michael Tokarev" on 2022-04-26 at 18:28 Uhr +0300: Well, GOST comes as an add-on to libcrypto. So if you install such an add-on on your system, everything will work. If we disable GOST for ldns, we'll got another bugreport, saying GOST is not enabled even if ldns supports it. I think it's best to keep it the way it is now, how do you think? Yeah, but maybe add a stanza to the README? -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems
Bug#862207: error: libcrypto does not provide GOST
Control: tag -1 + moreinfo On Tue, 9 May 2017 21:44:45 +0200 martin f krafft wrote: Package: ldnsutils Version: 1.7.0-1 Severity: normal When trying ti use ldns-key2ds with -g, I get an error about GOST not being available. % ldns-key2ds -g -n _combined.key error: libcrypto does not provide GOST Either the option should be disabled, or ldns-key2ds linked with a libcrypto that provides GOST. Well, GOST comes as an add-on to libcrypto. So if you install such an add-on on your system, everything will work. If we disable GOST for ldns, we'll got another bugreport, saying GOST is not enabled even if ldns supports it. I think it's best to keep it the way it is now, how do you think? /mjt
Bug#862207: error: libcrypto does not provide GOST
Package: ldnsutils Version: 1.7.0-1 Severity: normal When trying ti use ldns-key2ds with -g, I get an error about GOST not being available. % ldns-key2ds -g -n _combined.key error: libcrypto does not provide GOST Either the option should be disabled, or ldns-key2ds linked with a libcrypto that provides GOST. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ldnsutils depends on: ii libc6 2.24-10 ii libldns21.7.0-1 ii libpcap0.8 1.8.1-3 ii libssl1.1 1.1.0e-1 ldnsutils recommends no packages. ldnsutils suggests no packages. -- no debconf information -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
