Bug#1067087: GCC frame pointers
Source: gcc-14 Severity: wishlist Please consider enabling frame pointers on 64 bit arches. See: https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointers.html Kurt
Bug#1065424: [Pkg-openssl-devel] Bug#1065424: Can't connect to Active Directory with openssl
Hi, It's unclear to me what you're reporting as error. The connection seems to be working. The verification of the certificate seems to fail. It seems you have your own CA, but the CA is not trusted because it's not in the certificate store. Kurt
Bug#1007669: lice: please consider upgrading to 3.0 source format
You seem to have moved the config file for some reason. Are you sure you wanted to do that?
Bug#1034004: afl++: afl-clang(-fast) does not support -m32 due to missing afl-compiler-rt-32.o
This seems to be caused by a missing build-depends. If I build it locally, I do get support for 32 bit builds.
Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64
Hi, Is the issue that with older glibc versions, it was silently casted to a 32 bit value, but now that glibc supports 64 bit, it knows it can't represent it, and gives an error? Maybe for bookworm, we should just ignore the test error? Kurt
Bug#1026508: ca-certificates: FTBFS: TypeError: argument 'data': 'bytearray' object cannot be converted to 'PyBytes'
Hi, Are you waiting for something before uploading this fix? Kurt
Bug#1023284: libevent: FTBFS with glibc 2.36
Hi, It seems a fix for this is sitting git, but hasn't been uploaded. Is there a reason it's not been uploaded yet? Kurt
Bug#1026103: aflplusplus: FTBFS on s390x
Source: aflplusplus Version: 4.04c-2 Severity: serious Hi, Your package is failing to build on s390x: [*] Compiling afl++ for OS Linux on ARCH s390x ./test/unittests/unit_maybe_alloc [==] Running 6 test(s). [ RUN ] test_pow2 [ OK ] test_pow2 [ RUN ] test_null_allocs [ OK ] test_null_allocs [ RUN ] test_nonpow2_size [ OK ] test_nonpow2_size [ RUN ] test_zero_size [ OK ] test_zero_size [ RUN ] test_unchanged_size [ OK ] test_unchanged_size [ RUN ] test_grow_multiple [ OK ] test_grow_multiple [==] 6 test(s) run. [ PASSED ] 6 test(s). ./test/unittests/unit_preallocable [==] Running 2 test(s). [ RUN ] test_alloc_free [ OK ] test_alloc_free [ RUN ] test_prealloc_overflow [ OK ] test_prealloc_overflow [==] 2 test(s) run. [ PASSED ] 2 test(s). ./test/unittests/unit_list [==] Running 3 test(s). [ RUN ] test_contains [ OK ] test_contains [ RUN ] test_foreach [ OK ] test_foreach [ RUN ] test_long_list [ OK ] test_long_list [==] 3 test(s) run. [ PASSED ] 3 test(s). ./test/unittests/unit_rand [==] Running 2 test(s). [ RUN ] test_rand_0 [ OK ] test_rand_0 [ RUN ] test_rand_below [ OK ] test_rand_below [==] 2 test(s) run. [ PASSED ] 2 test(s). ./test/unittests/unit_hash [==] Running 1 test(s). [ RUN ] test_hash [ OK ] test_hash [==] 1 test(s) run. [ PASSED ] 1 test(s). make[3]: Leaving directory '/<>' ␛[1;90m[*] 10 test cases completed.␛[0m ␛[1;93m[-] not all test cases were executed ␛[0;31m[!] failure in tests :-(␛[0m make[2]: *** [GNUmakefile:343: tests] Error 1 It's not at all clear why it says: "failure in tests". All the test seem to pass. Other architectures also have the "not all test cases were executed" message. I've tried to build it again on the buildds, but it failed the same way. Kurt
Bug#1025454: afl: Downloads software during build
Source: aflplusplus Version: 4.04c-1 Severity: serious Hi, On the buildds, we get: # -/usr/bin/make -C utils/plot_ui /usr/bin/make -C frida_mode make[3]: Entering directory '/<>/frida_mode' mkdir -p /<>/frida_mode/build/ mkdir -p /<>/frida_mode/build/frida/ wget -qO /<>/frida_mode/build/frida/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz "https://github.com/frida/frida/releases/download/15.2.1/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz; || curl -L -o /<>/frida_mode/build/frida/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz "https://github.com/frida/frida/releases/download/15.2.1/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz; /bin/sh: 1: wget: not found /bin/sh: 1: curl: not found make[3]: *** [GNUmakefile:313: /<>/frida_mode/build/frida/frida-gumjs-devkit-15.2.1-linux-x86_64.tar.xz] Error 127 make[3]: Leaving directory '/<>/frida_mode' make[2]: [GNUmakefile:636: distrib] Error 2 (ignored) cd nyx_mode && ./build_nyx_support.sh = Nyx build script = [*] Performing basic sanity checks... [*] Making sure all Nyx is checked out ./build_nyx_support.sh: line 41: git: command not found make[2]: [GNUmakefile:637: distrib] Error 127 (ignored) cd qemu_mode && sh ./build_qemu_support.sh = QemuAFL build script = [*] Performing basic sanity checks... [+] All checks passed! [*] Making sure qemuafl is checked out [*] cloning qemuafl Trying to clone qemuafl (attempt 1/3) ./build_qemu_support.sh: 84: git: not found Trying to clone qemuafl (attempt 2/3) ./build_qemu_support.sh: 84: git: not found Trying to clone qemuafl (attempt 3/3) ./build_qemu_support.sh: 84: git: not found [-] Not checked out, please install git or check your internet connection. make[2]: [GNUmakefile:638: distrib] Error 1 (ignored) cd unicorn_mode && unset CFLAGS && sh ./build_unicorn_support.sh = UnicornAFL build script = [...] On machines that have more software installed, it will download various things and build them. It makes at least use of software like wget, curl, git, cargo. Packages in Debian should be build only from the source and not download more sources from internet. Kurt
Bug#1025443: aflplusplus: Missing lld-14 Build-Depends
Source: aflplusplus Version: 4.04c-1 Hi, The LTO mode is not build at runtime, the log shows: [+] llvm_mode detected llvm 10+, enabling neverZero implementation and c++14 [+] llvm_mode detected llvm 11+, enabling afl-lto LTO implementation GNUmakefile.llvm:229: ld.lld not found, cannot enable LTO mode This is because there is a missing Build-Depends on lld-14. The LTO mode is the recommended mode. Kurt
Bug#1024631: gitlab: preinst: invalid number 9.1
On Tue, Nov 22, 2022 at 06:13:30PM +0100, Kurt Roeckx wrote: > In any case, the default cluster points to 14, it's just not on port 5432. That doesn't seem to be true. Commands like createdb, psql default to port 5432 if there is nothing overriding it, like PGPORT env variable. Kurt
Bug#1024631: gitlab: preinst: invalid number 9.1
On Tue, Nov 22, 2022 at 10:20:06PM +0530, Pirate Praveen wrote: > > > On Tue, Nov 22 2022 at 02:27:05 PM +01:00:00 +01:00:00, Kurt Roeckx > wrote: > > Package: gitlab > > Version: 15.4.2+ds1-1~fto11+3 > > > > On install I get: > > /var/lib/dpkg/tmp.ci/preinst: 7 [: Illagal number: 9.1 > > > > I have several postgresql clusters, 9.1, 9.6, 12, 14. Not all of them > > are used. 9.1 is using port 5432. > > > > Do you have another recommendation on how to make sure we use at least > postgresql 12? > > Does adding a configuration option to skip this check > "gitlab_pg_version_check" which can be set to "false" in > /etc/gitlab/gitlab-debian.conf suffice? Note that it just continues the installation because it ignores the error. To be able to install things, I had to edit the database.yml to set the port number. I also had to manually create the user and database. I think it asks for a hostname, but not for a port number. I at least assume it supports a remote database. The check should be for that combination, which is probably harder. In any case, the default cluster points to 14, it's just not on port 5432. Kurt
Bug#1024627: Acknowledgement (gitlab: Fails to install)
fasttrack contains a 1.7.3 version that's new enough. The 1.8.0 version from backports is too new it seems, and it what gets installed when you just do: apt install gitlab
Bug#1024631: gitlab: preinst: invalid number 9.1
Package: gitlab Version: 15.4.2+ds1-1~fto11+3 On install I get: /var/lib/dpkg/tmp.ci/preinst: 7 [: Illagal number: 9.1 I have several postgresql clusters, 9.1, 9.6, 12, 14. Not all of them are used. 9.1 is using port 5432. Kurt
Bug#1024627: gitlab: Fails to install
Package: gitlab Version: 15.4.2+ds1-1~fto11+3 Severity: serious Setting up gitlab (15.4.2+ds1-1~fto11+3) ... Bundler could not find compatible versions for gem "omniauth-oauth2": In Gemfile: omniauth-auth0 (~> 2.0) was resolved to 2.0.0, which depends on omniauth-oauth2 (~> 1.4) x86_64-linux omniauth-authentiq (~> 0.3.3) was resolved to 0.3.3, which depends on omniauth-oauth2 (>= 1.5) x86_64-linux omniauth-azure-activedirectory-v2 (~> 1.0) was resolved to 1.0.0, which depends on omniauth-oauth2 (~> 1.7) x86_64-linux omniauth-dingtalk-oauth2 (~> 1.0) was resolved to 1.0.0, which depends on omniauth-oauth2 (~> 1.7.1) x86_64-linux omniauth-facebook (~> 4.0) was resolved to 4.0.0, which depends on omniauth-oauth2 (~> 1.2) x86_64-linux omniauth-oauth2-generic (~> 0.2.2) was resolved to 0.2.2, which depends on omniauth-oauth2 (~> 1.0) x86_64-linux Could not find gem 'omniauth-oauth2 (~> 1.7.1)', which is required by gem 'omniauth-auth0 (~> 2.0)', in any of the sources. Kurt
Bug#1021997: cargo: New upstream version
Source: cargo Version: 0.57.0-7 Severity: wishlist Hi, Would it be possible to upload a newer version of cargo? The current version is preventing me from building things. I think the 0.62 version matches the 1.61 version of rustc that's currently in testing/unstable. Kurt
Bug#1020652: [Pkg-openssl-devel] Bug#1020652: openssl: tls_process_key_exchange:internal error:../ssl/statem/statem_clnt.c:2254:
On Sun, Sep 25, 2022 at 02:16:00AM +, Thorsten Glaser wrote: > Kurt Roeckx dixit: > > >On Sat, Sep 24, 2022 at 10:34:19PM +0200, Thorsten Glaser wrote: > >> $ openssl s_client -CApath /etc/ssl/certs -connect www.mirbsd.org:443 > >> -legacy_renegotiation -tls1 > > > >TLS 1.0 is not supported by default because it's insecure. You need > >to change the security level to 0, for instance by using the cipher > >string DEFAULT@SECLEVEL=0 >^ +colon > > Hey, this used to work at @SECLEVEL=2 even, with just MinProtocol > changed. Also openssl ciphers shows the same, independent of the > number used for @SECLEVEL. How can I find out, for any installed > OpenSSL, which settings this mysterious @SECLEVEL influences and > which are available? Where is this documented? There is /usr/share/doc/openssl/NEWS.md.gz, which says: * SSL 3, TLS 1.0, TLS 1.1, and DTLS 1.0 only work at security level 0, except when RSA key exchange without SHA1 is used. So this also works: openssl s_client -connect www.mirbsd.org:443 -cipher AES256-SHA -legacy_renegotiation -tls1 That's the only cipher you have with RSA key exchange. Your server doesn't have a preference for ciphers, so picks the first offered by the client, so the order is important. Security levels are documented in SSL_CTX_set_security_level(3): https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_security_level.html SHA1 have been moved to security level 0 because it no longer provides enough security, even when combined with MD5. Kurt
Bug#965041: [Pkg-openssl-devel] Bug#965041: Bug#965041: libssl3: Please stop building legacy provider
On Sun, Sep 18, 2022 at 07:09:05PM +0200, Sebastian Andrzej Siewior wrote: > On 2020-07-16 08:46:43 [+0200], Kurt Roeckx wrote: > > On Thu, Jul 16, 2020 at 03:57:17AM +0100, Dimitri John Ledkov wrote: > > > > > > openssl package could ship `.include /etc/ssl/providers.d/` in ssl.conf. > > > > That would actually make sense. > > > > We could use the include thing to ship a config file for the > > fips module with the correct hash in it. > > Kurt, what do we do here? > Split /usr/lib/*/ossl-modules/legacy.so into its own package which is > part of src:openssl and adds a config snippet. I'm not sure that having the legacy provider automatically enabled by default when it's installed is a good idea. That means once it's installed, all applications have it by default. I think it needs to be enabled per application. I think the same goes for fips. Only applications that need it, and probably support a library context should enable it. I don't know enough details currently about fips, but I think applications need to provider an approved RNG, and /dev/random is no longer acceptable. But upgrading the fips provider should be as easy as possible, just installing a new version. So I think we need to provider at least some config file should have the hash in it. Kurt
Bug#805646: [Pkg-openssl-devel] Bug#805646: Bug#805646: Package using openssl functions does not find default certificates
On Tue, Sep 13, 2022 at 06:40:19PM +0200, Sebastian Andrzej Siewior wrote: > On 2022-09-13 18:30:05 [+0200], Kurt Roeckx wrote: > > > > 3) provide a symlink from /usr/lib/ssl/cert.pem to > > > >/etc/ssl/certs/ca-certificates.crt > > > > > > Kurt, I tend to provide this symlink. Any objections? > > > I'm kind of confused that it works for others, like curl. But I don't > > > see anything wrong with what is done in this bug report. > > > > We have a symlink from /usr/lib/ssl/certs to /etc/ssl/certs for ages. > > what I see is: > | openat(AT_FDCWD, "/usr/lib/ssl/openssl.cnf", O_RDONLY) = 3 > | openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such > file or directory) > | openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such > file or directory) > > This is X509_CERT_FILE / X509_get_default_cert_file(). > > So it would need a symlink from this non existing file to > /etc/ssl/certs/ca-certificates.crt which is provided/ created by > ca-certificates. That works for me. Kurt
Bug#805646: [Pkg-openssl-devel] Bug#805646: Package using openssl functions does not find default certificates
On Tue, Sep 13, 2022 at 05:23:43PM +0200, Sebastian Andrzej Siewior wrote: > On 2016-01-04 23:50:10 [+0100], Jan Dittberner wrote: > > I don't know whether this will have negative side effects but from my point > > of view it would be nice if the openssl package would do one of the > > following to properly solve this issue: > > > > 1) properly load certificates from /etc/ssl/certs when > >SSL_CTX_set_default_verify_paths is called > > so I guess this works but it does not provide what it should provide, > right Kurt? > > > 2) change the default paths to /etc/ssl/certs and > >/etc/ssl/certs/ca-certificates.crt instead of /usr/lib/ssl/certs and > >/usr/lib/ssl/cert.pem > > > > 3) provide a symlink from /usr/lib/ssl/cert.pem to > >/etc/ssl/certs/ca-certificates.crt > > Kurt, I tend to provide this symlink. Any objections? > I'm kind of confused that it works for others, like curl. But I don't > see anything wrong with what is done in this bug report. We have a symlink from /usr/lib/ssl/certs to /etc/ssl/certs for ages. Kurt
Bug#1016526: [Pkg-openssl-devel] Bug#1016526: openssl: Regression on mips64el throws error:1E08010C:DECODER
On Tue, Aug 02, 2022 at 12:50:05PM +0200, Jérémy Lal wrote: > Package: openssl > Version: 3.0.5-1 > Severity: normal > Control: affects -1 nodejs > > Hi, > > while building nodejs 18.6.0+dfsg-4 on mips64el, some SSL tests did regress, > https://buildd.debian.org/status/logs.php?pkg=nodejs=mips64el > (look for "not ok" tests). > > In particular, test-crypto-sign-verify test failed with an unexpected error: > 'error:1E08010C:DECODER routines::unsupported' For some reason it seems to expect to fail with some other error instead. It's currently unclear that this is an openssl bug. Can you show what that code is trying to do, and what it expects openssl to return? There seem to be various other test suite failures that don't seem to be related to openssl at all. > I suppose the root cause is similar to the one for > [EC code appears to be broken on s390x](https://bugs.debian.org/1016290), > but it's not the same bug. It will be totally unrelated. That one is very specific to s390x. Kurt
Bug#1015240: Acknowledgement (linux: rejecting DMA map of vmalloc memory)
On Tue, Jul 19, 2022 at 06:11:23PM +0200, Diederik de Haas wrote: > According to that bug report it should be fixed with 5.19-rc6 and that > version > is available in experimental. Can you verify whether it also fixes your issue? With that version the error goes away.
Bug#1015240: Acknowledgement (linux: rejecting DMA map of vmalloc memory)
This is probably https://bugzilla.kernel.org/show_bug.cgi?id=216140 Kurt
Bug#1015240: Acknowledgement (linux: rejecting DMA map of vmalloc memory)
I tried older kernels, 5.17.3-1 didn't show it.
Bug#1015240: linux: rejecting DMA map of vmalloc memory
Package: linux-image-5.18.0-2-amd64 Version: 5.18.5-1 Hi, I'm currently seeing this during boot: [5.632167] usb 1-14: New USB device found, idVendor=8087, idProduct=0aaa, bcdDevice= 0.02 [5.632171] usb 1-14: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [5.655513] [ cut here ] [5.655515] xhci_hcd :00:14.0: rejecting DMA map of vmalloc memory [5.655541] WARNING: CPU: 6 PID: 375 at include/linux/dma-mapping.h:326 usb_hcd_map_urb_for_dma+0x448/0x470 [usbcore] [5.65] Modules linked in: rtsx_usb(+) joydev(+) pcc_cpufreq(-) acpi_cpufreq(-) snd_sof_pci_intel_cnl snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_c adence x86_pkg_temp_thermal snd_sof_intel_hda intel_powerclamp snd_sof_pci snd_sof_xtensa_dsp iwlmvm(+) snd_hda_codec_hdmi coretemp snd_sof snd_sof_utils snd_soc_hdac_hda snd_hda_ext_core sn d_soc_acpi_intel_match snd_soc_acpi kvm_intel snd_soc_core snd_compress qrtr kvm snd_hda_codec_realtek snd_hda_codec_generic soundwire_bus irqbypass mac80211 ledtrig_audio ghash_clmulni_inte l mei_hdcp snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec intel_rapl_msr snd_hda_core libarc4 snd_hwdep aesni_intel snd_pcm nls_ascii crypto_simd cryptd iwlwifi nls_cp437 iT CO_wdt snd_timer rapl processor_thermal_device_pci_legacy intel_pmc_bxt processor_thermal_device vfat intel_cstate iTCO_vendor_support snd processor_thermal_rfim cfg80211 intel_uncore fat wm i_bmof intel_wmi_thunderbolt pcspkr efi_pstore [5.655582] watchdog mei_me processor_thermal_mbox soundcore ee1004 processor_thermal_rapl mei intel_rapl_common rfkill intel_soc_dts_iosf intel_pch_thermal serial_multi_instantiate int3 400_thermal intel_pmc_core int3403_thermal int340x_thermal_zone acpi_thermal_rel evdev acpi_tad acpi_pad ipmi_devintf ipmi_msghandler msr parport_pc ppdev lp parport fuse configfs efivarfs i p_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic hid_cherry hid_generic usbhid hid i915 drm_buddy i2c_algo_bit drm_dp_helper cec rc_core ttm drm_kms_helper ahci libahci xhci_ pci libata xhci_hcd nvme drm nvme_core e1000e usbcore t10_pi scsi_mod crc32_pclmul crc64_rocksoft crc32c_intel crc64 ptp crc_t10dif i2c_i801 crct10dif_generic pps_core crct10dif_pclmul i2c_s mbus crct10dif_common usb_common scsi_common wmi fan video button [5.655614] CPU: 6 PID: 375 Comm: systemd-udevd Not tainted 5.18.0-2-amd64 #1 Debian 5.18.5-1 [5.655616] Hardware name: LENOVO 11EVCTO1WW/3168, BIOS M2TKT4FA 04/28/2022 [5.655617] RIP: 0010:usb_hcd_map_urb_for_dma+0x448/0x470 [usbcore] [5.655628] Code: 50 c6 05 c4 2a 03 00 01 4d 85 e4 75 03 4d 8b 22 4c 89 d7 e8 ca f8 6e d4 4c 89 e2 48 c7 c7 20 6e 1a c0 48 89 c6 e8 58 c2 99 d4 <0f> 0b e9 58 ff ff ff 48 8b 05 5a 02 89 d5 e9 08 fd ff ff 48 8b 05 [5.655629] RSP: 0018:a6614069fab0 EFLAGS: 00010282 [5.655630] RAX: RBX: a66140edd000 RCX: [5.655631] RDX: 0001 RSI: 9535bc45 RDI: [5.655633] RBP: 8fc3c5766d80 R08: R09: efff [5.655634] R10: a6614069f8d8 R11: 95ad1528 R12: 8fc3c1b567e0 [5.655635] R13: 000c R14: 8fc3cacac000 R15: 0001 [5.655636] FS: 7ff9a890c8c0() GS:8fd2de38() knlGS: [5.655637] CS: 0010 DS: ES: CR0: 80050033 [5.655638] CR2: 55c575cea0c0 CR3: 00010ae8e001 CR4: 003706e0 [5.655639] Call Trace: [5.655641] [5.655646] usb_hcd_submit_urb+0x95/0xb90 [usbcore] [5.655655] ? __wait_for_common+0x19f/0x1d0 [5.655658] ? usb_start_wait_urb+0xa2/0x160 [usbcore] [5.655670] ? __kmalloc+0x16b/0x300 [5.655672] usb_start_wait_urb+0x65/0x160 [usbcore] [5.655683] rtsx_usb_send_cmd+0x5c/0xb0 [rtsx_usb] [5.655687] rtsx_usb_probe+0x13c/0x3b0 [rtsx_usb] [5.655690] usb_probe_interface+0xdf/0x2a0 [usbcore] [5.655703] really_probe+0x199/0x380 [5.655706] __driver_probe_device+0xfe/0x180 [5.655708] driver_probe_device+0x1e/0x90 [5.655709] __driver_attach+0xc0/0x1c0 [5.655711] ? __device_attach_driver+0xe0/0xe0 [5.655713] ? __device_attach_driver+0xe0/0xe0 [5.655715] bus_for_each_dev+0x75/0xc0 [5.655718] bus_add_driver+0x154/0x200 [5.655721] driver_register+0x8f/0xe0 [5.655723] usb_register_driver+0x84/0x120 [usbcore] [5.655731] ? 0xc1253000 [5.655732] do_one_initcall+0x41/0x200 [5.655735] ? kmem_cache_alloc_trace+0x177/0x2a0 [5.655736] do_init_module+0x4c/0x260 [5.655738] __do_sys_finit_module+0xb4/0x120 [5.655741] do_syscall_64+0x38/0xc0 [5.655742] entry_SYSCALL_64_after_hwframe+0x44/0xae [5.655745] RIP: 0033:0x7ff9a8a32f79 [5.655746] Code: 48 8d 3d da db 0d 00 0f 05 eb a5 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
Bug#995636: transition: openssl
On Sun, Jun 05, 2022 at 08:44:22PM +0200, Sebastian Andrzej Siewior wrote: > On 2022-06-05 19:42:43 [+0200], Sebastian Ramacher wrote: > > Hi Sebastian > Hi Sebastian, > > > > Otherwise I'd fear that the only other options are openssl breaking > > > libssl1.1 or renaming /etc/ssl/openssl.cnf to have a version specific > > > name. Given the high number reverse dependencies involved in this > > > transition (and also those depending on bin:openssl), I'd prefer to > > > avoid a Breaks that could have the potential to force the libssl1.1 -> > > > libssl3 upgrade to be more of a lockstep transition than needed. > > > > I see that there was another openssl upload. Any reason a fix for this > > issue wasn't included in the upload of 3.0.3-6? > > I wasn't aware that this is something that we want do. Kurt pointed me > to the testsuite problem which was the primary motivation for the > upload. > Regarding dovecot, Kurt wanted to make some time for it. The patch in > ubuntu is working but is a giant duct tape which is not something I > would wan to upload… > Anyway, regarding the openssl.cnf. Do we want to use openssl-3.cnf for > libssl3? We can't make opnenssl-1.1.cnf happen. The modification > openssl.cnf already happend so people need to make changes manually… > Is this the request here? The suggestion was to make an openssl.cnf that's compatible with 1.1.1, and so remove or comment out everything related to providers. Kurt
Bug#995636: transition: openssl
On Thu, May 26, 2022 at 06:26:57PM +0200, Sebastian Ramacher wrote: > > That leaves #1011051. What's your view on that bug? So my understanding is that 1.1.1 doesn't understand the new configuration file and tries to load an engine (instead of a provider). We could ship a file that's comptabile with 1.1.1. That would make it a little bit harder to load some providers by default, but maybe that's something you want to do per application anyway. Kurt
Bug#1011243: nvidia-cuda-toolkit: Hard dependency on libssl1.1
Source: nvidia-cuda-toolkit Version: 11.4.3-2 Severity: serious Tags: sid bookworm Hi, It seems build-depends on libssl1.1 and not on libssl-dev. It also depends on libssl1.1 and doesn't transition to libssl3 on rebuild. Can you please move to using libssl3? Kurt
Bug#1011242: thrift: No depends on libssl after rebuild against OpenSSL 3.0
Source: thrift Version: 0.16.0-5 Severity: serious Tags: sid bookworm Hi, It seems that thrift does not depend on libssl after being rebuild against OpenSSL 3.0, but did depend on libssl1.1. Kurt
Bug#1010958: sscg FTBFS with OpenSSL 3.0.3
It looks like it's fixed here: https://github.com/openssl/openssl/pull/18247
Bug#996276: foxeye: FTBFS with OpenSSL 3.0
On Wed, May 11, 2022 at 07:25:45PM +0300, Andriy Grytsenko wrote: > >You can test it by installing the version from unstable. > > It is not in unstable yet, see That should have said experimental. Kurt
Bug#996276: foxeye: FTBFS with OpenSSL 3.0
tags 996276 - bookworm-ignore experimental + bookworm sid thanks This is affecting the bookworm release. The release managers approved the upload to unstable and marked it as serious/release critical. You can test it by installing the version from unstable.
Bug#692917: printer-driver-escpr: color error on armel
On Sat, Apr 02, 2022 at 11:19:26AM +0200, Thorsten Alteholz wrote: > Hi Kurt and Patrik, > > thanks a lot for your reports. Can you please check whether the problem > still exists after a few new upstream versions? Both the printer and the armel server have been replaced in the mean time. Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, Mar 22, 2022 at 10:13:25PM +0100, Sebastian Andrzej Siewior wrote: > On 2022-03-22 21:47:52 [+0100], Kurt Roeckx wrote: > > On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote: > > > OpenSSL signature algorithm check tightening > > > = > > > > > > The OpenSSL update included in this point release includes a change to > > > ensure that the requested signature algorithm is supported by the > > > active security level. > > > > > > Although this will not affect most use-cases, it could lead to error > > > messages being generated if a non-supported algorithm is requested - > > > for example, use of SHA1 with the default security level of 2. In such > > > cases, the security level will need to be explicitly lowered when > > > invoking OpenSSL, using an option such as > > > > > > -cipher "ALL:@SECLEVEL=1" > > > " > > > > So reading it again, I think the "when invoking OpenSSL" is confusing. > > Not only the openssl binary is affected, but also all clients and > > server applications making use of the library are. Some applications > > might have a way to set the cipher in their own configuration file, > > others might need to change the defaults in /etc/ssl/openssl.cfg > > s/openssl.cfg/openssl.cnf > > Kurt correct me if I'm wrong: > This only affects clients which were using TLS1.2 while connecting to > the server and did not send a sig-alg string which let the server > fallback to the default (sha1) which was not checked vs security level. > Would the client have sent sha1 as the sig-cipher then it would fail in > the version d, too. The client can send a list of supported sigalgs. Before the change there were 3 options: - the client didn't send anything, the server selected SHA1 - the client only send SHA1, the server selected SHA1 - the client send both SHA1 and SHA256, the server selected SHA256 With this change, it changes to: - the client didn't send anything, the server selects SHA1 for security level <= 1, for security level >= 2 it returns an error. - the client only send SHA1, the server selects SHA1 for security level <= 1, for security level >= 2 it returns an error. - the client send both SHA1 and SHA256, the server selects SHA256. The default client will send both SHA1 and SHA256 for a very long time, but you can change the settings. If the server selects SHA1, before the change the client will accept it, after the change it requires security level <= 1. When talking about SHA1 here, it's really about something RSA+SHA1, as in an RSA signature over a SHA1 hash. > Would the client need a lower protocol (TLSv1.0) then it would fail, too. > In these two cases the server administrator must have lowered the > security level to 1 (for the announced low sig-alg) and/or allow TLSv1 > in order for the client to connect. (The same for the other way around). SHA1 can be used for various things in the protocol. Other uses of SHA1 where already properly rejected, it just allowed SHA1 as signature algorithm. Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote: > OpenSSL signature algorithm check tightening > = > > The OpenSSL update included in this point release includes a change to > ensure that the requested signature algorithm is supported by the > active security level. > > Although this will not affect most use-cases, it could lead to error > messages being generated if a non-supported algorithm is requested - > for example, use of SHA1 with the default security level of 2. In such > cases, the security level will need to be explicitly lowered when > invoking OpenSSL, using an option such as > > -cipher "ALL:@SECLEVEL=1" > " So reading it again, I think the "when invoking OpenSSL" is confusing. Not only the openssl binary is affected, but also all clients and server applications making use of the library are. Some applications might have a way to set the cipher in their own configuration file, others might need to change the defaults in /etc/ssl/openssl.cfg Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, Mar 22, 2022 at 08:19:01PM +, Adam D. Barratt wrote: > Is the note below accurate? Yes. Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Tue, Mar 22, 2022 at 07:37:00PM +, Adam D. Barratt wrote: > On Mon, 2022-03-21 at 00:12 +0100, Sebastian Andrzej Siewior wrote: > > The change in openssl is commit > >cc7c6eb8135b ("Check that the default signature type is allowed") > > > > Before the commit in question it connects as: > > - Description: (TLS1.0)-(ECDHE-SECP384R1)-(AES-256-CBC)-(SHA1) > > > > after that, the server throws: > > 140490373015360:error:14201044:SSL > > routines:tls_choose_sigalg:internal error:../ssl/t1_lib.c:2880: > > > > and it appears that the security level in openssl forbids SHA1 here. > > The argument on the s_server side > > -sigalgs RSA+SHA1:RSA+SHA256:DSA+SHA1:DSA+SHA256 > > > > doesn't help here but > > -cipher "ALL:@SECLEVEL=1" > > > > does. > > > > If we wanted to add a note to the release announcement in case users > face similar issue with other software, is "tls_choose:sigalg:internal > error" a reliable signal of this situation occurring? Should the > recommended solution be to lower the security level, or might > specifying -sigalgs work on its own in some scenarios? So to clarify things. The problem is that SHA1 was allowed as signature algorithm while the security level should not have allowed it. If the peer does not support SHA256, the security level needs to be lowered so that SHA1 is allowed again. Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Mon, Mar 21, 2022 at 12:12:11AM +0100, Sebastian Andrzej Siewior wrote: > > The change in openssl is commit >cc7c6eb8135b ("Check that the default signature type is allowed") So that's: commit cc7c6eb8135be665d0acc176a5963e1eaf52e4e2 Author: Kurt Roeckx Date: Thu Jan 2 22:53:32 2020 +0100 Check that the default signature type is allowed TLS < 1.2 has fixed signature algorithms: MD5+SHA1 for RSA and SHA1 for the others. TLS 1.2 sends a list of supported ciphers, but allows not sending it in which case SHA1 is used. TLS 1.3 makes sending the list mandatory. When we didn't receive a list from the client, we always used the defaults without checking that they are allowed by the configuration. Reviewed-by: Paul Dale GH: #10784 (cherry picked from commit b0031e5dc2c8c99a6c04bc7625aa00d3d20a59a5) Kurt
Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance
On Sun, Mar 20, 2022 at 10:00:15PM +0100, Paul Gevers wrote: > Dear Sebastian, Kurt, > > On 19-03-2022 12:33, Adam D Barratt wrote: > > Upload details > > == > > > > Package: openssl > > Version: 1.1.1n-0+deb10u1 > > > > Explanation: new upstream release > > We're seeing a regression in buster in the autopkgtest of gnutls28 with the > new version of openssl on all tested architectures. Can you please have a > look and advise? (bullseye doesn't seem to have the test anymore, hence it > doesn't fail). > > https://ci.debian.net/data/autopkgtest/oldstable/amd64/g/gnutls28/20199677/log.gz > > Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)... > %COMPAT: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)... > *** Fatal error: A TLS fatal alert has been received. > Failure: Failed > *** Fatal error: A TLS fatal alert has been received. > %NO_ETM: Checking TLS 1.0 with ECDHE-ECDSA (SECP384R1)... > Failure: Failed > *** Fatal error: A TLS fatal alert has been received. > Failure: Failed > FAIL [11]../../tests/suite/testcompat-main-openssl > > Which, according to me, is this check: > https://sources.debian.org/src/gnutls28/3.6.7-4%2Bdeb10u7/tests/suite/testcompat-main-openssl/#L307 That test still seems to exist, but is just moved to a different file: https://github.com/gnutls/gnutls/blob/master/tests/suite/testcompat-openssl-cli-common.sh#L255 My understanding is that gnutls now passes the correct list of signature algorithms to use to OpenSSL's s_client to be able to do that test, and that this is probably fixed by: https://github.com/gnutls/gnutls/commit/23958322865a8a77c2f924f569484e5fd150a24b (and https://github.com/gnutls/gnutls/commit/8259a1dc8503ad760c0887eb95278f9957a00667) I'm trying to remember what was changed and why, but I can't find/remember it. Kurt
Bug#1003484: bullseye-pu: package openssl/1.1.1m-0+deb11u1
On Fri, Mar 18, 2022 at 10:22:57PM +0100, Sebastian Andrzej Siewior wrote: > On 2022-03-18 14:51:32 [+], Adam D. Barratt wrote: > > Boo. Hope you're doing better. > > Thanks, yes. > > > > I would also do the upload for Buster, would that work? I remember > > > that > > > the packages, that broken, were already uploaded a few cycles ago. > > > > Also as 1.1.1n? > > Yes. > > > I assume there haven't been any regressions reported with l/m/n in the > > meantime. I'm not aware of any regressions the past year. Kurt
Bug#1002576: dch doesn't read email settings from config file
Package: devscripts Version: 2.21.7 Running dch will give me: dch warning: neither DEBEMAIL nor EMAIL environment variable is set dch warning: building email address from username and mailname dch: Did you see those 2 warnings? Press RETURN to continue... The manual says I can put it in the ~/.devscripts file, but that doesn't have any effect. strace says it's being read. Putting it in an environment variable does make the warning go away. Kurt
Bug#999606: Acknowledgement (fetchmail: configuration requires TLS for SSH authentication)
It seems that 6.4.23 actually changed the message to: configuration requires TLS, but STARTTLS is not permitted because of authenticated state (PREAUTH). Aborting connection. If your plugin is secure, you can defeat STARTTLS with --sslproto '' (see manual). See: https://gitlab.com/fetchmail/fetchmail/-/issues/39
Bug#999606: fetchmail: configuration requires TLS for SSH authentication
Package: fetchmail Version: 6.4.22-1 Severity: serious Hi, With version 6.4.22-1 and 6.4.23-1 I get the following error: configuration requires TLS, but STARTTLS is not permitted because of authenticated state (PREAUTH). Aborting connection. Server permitting, try --ssl instead (see manual). But I'm using ssh authentication (auth ssh), and using the plugin command I'm remotely start the imap server (doveadm exec imap). The imap server does not require authentication. As far as fetchmail is concerned, it should not talk SSL/SSH, or do any authentication, it's all done externally. This worked until version 6.4.21-1. Kurt
Bug#996048: [Pkg-openssl-devel] Bug#996048: postfix-mta-sts-resolver: autopkgtest doesn't handle new version of ca-certificates nicely: rehash: warning: skipping ca-certificates.crt, it does not conta
On Mon, Oct 18, 2021 at 10:40:59PM +0200, Julien Cristau wrote: > On Mon, Oct 18, 2021 at 02:50:50PM +0200, Benjamin Hof wrote: > > Hi, > > > > I think the following change might be the relevant one: > > > > --- a/update-ca-certificates > > +++ b/update-ca-certificates > > @@ -164,8 +164,6 @@ > >done > > fi > > > > -rm -f "$CERTBUNDLE" > > - > > ADDED_CNT=$(wc -l < "$ADDED") > > REMOVED_CNT=$(wc -l < "$REMOVED") > > > > It triggers this stderr output during openssl rehash (l. 184): > > > > rehash: warning: skipping ca-certificates.crt,it does not contain > > exactly one certificate or CRL > > > Ah, that makes sense. Annoying... > > Kurt/Sebastian, do you think there's a chance openssl rehash could grow > some sort of ignore option so update-ca-certificates could ask it to > skip ca-certificates.crt, to avoid spitting out a warning for it? As in rehash all files in that directory, excluding a file? I guess that's an option. I guess it's not an option to move the file to a different location. Kurt
Bug#996692: Cargo: New upstream release
Source: cargo Version: 0.47.0-3 Severity: wishlist Hi, Can you package a newer version of cargo? The current version seems to be too old for some things. Kurt
Bug#996425: hitch: FTBFS with OpenSSL 3.0
Source: hitch Version: 1.7.1-2 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: hitch.c: In function init_dh: hitch.c:318:2: error: PEM_read_bio_DHparams is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 318 | dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL); | ^~ In file included from /usr/include/openssl/ui.h:30, from /usr/include/openssl/engine.h:30, from hitch.c:42: /usr/include/openssl/pem.h:469:1: note: declared here 469 | DECLARE_PEM_rw_attr(OSSL_DEPRECATEDIN_3_0, DHparams, DH) | ^~~ hitch.c:327:3: error: DH_free is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 327 | DH_free(dh); | ^~~ In file included from /usr/include/openssl/dsa.h:51, from /usr/include/openssl/x509.h:37, from hitch.c:40: /usr/include/openssl/dh.h:200:28: note: declared here 200 | OSSL_DEPRECATEDIN_3_0 void DH_free(DH *dh); |^~~ [...] Removing the -Werror will turn those errors in warnings and should allow building against and using OpenSSL 3.0. The functions are still available but marked for removal in some future version. Kurt
Bug#996424: haskell-blogliterately: FTBFS with OpenSSL 3.0
Source: haskell-blogliterately Version: 0.8.7-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: [12 of 12] Compiling Text.BlogLiterately ( src/Text/BlogLiterately.hs, dist-ghc/build/Text/BlogLiterately.p_o ) Preprocessing executable 'BlogLiterately' for BlogLiterately-0.8.7.. Building executable 'BlogLiterately' for BlogLiterately-0.8.7.. [1 of 1] Compiling Main ( main/BlogLiterately.hs, dist-ghc/build/BlogLiterately/BlogLiterately-tmp/Main.o ) Linking dist-ghc/build/BlogLiterately/BlogLiterately ... /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(PKey.o):function HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziEVPziPKey_zdwzdsrsaFromPKey1_info: error: undefined reference to 'EVP_PKEY_base_id' /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(PKey.o):function HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziEVPziPKey_zdwzdsrsaFromPKey_info: error: undefined reference to 'EVP_PKEY_base_id' /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(PKey.o):function HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziEVPziPKey_zdwzdsdsaFromPKey1_info: error: undefined reference to 'EVP_PKEY_base_id' /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(PKey.o):function HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziEVPziPKey_zdwzdsdsaFromPKey_info: error: undefined reference to 'EVP_PKEY_base_id' /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(Session.o):function HsOpenSSLzm0zi11zi4zi18zm6UnNvQ306xc6HmhIhGM8NK_OpenSSLziSession_zdwio_info: error: undefined reference to 'SSL_get_peer_certificate' /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(HsOpenSSL.o):function HsOpenSSL_EVP_MD_size: error: undefined reference to 'EVP_MD_size' /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(HsOpenSSL.o):function HsOpenSSL_EVP_CIPHER_CTX_block_size: error: undefined reference to 'EVP_CIPHER_CTX_block_size' /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/HsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK/libHSHsOpenSSL-0.11.4.18-6UnNvQ306xc6HmhIhGM8NK.a(HsOpenSSL.o):function HsOpenSSL_EVP_CIPHER_iv_length: error: undefined reference to 'EVP_CIPHER_iv_length' collect2: error: ld returned 1 exit status `x86_64-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1) make: *** [/usr/share/cdbs/1/class/hlibrary.mk:147: build-ghc-stamp] Error 1 Kurt
Bug#996423: haproxy: FTBFS with OpenSSL 3.0
Source: haproxy Version: 2.2.17-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: src/ssl_sock.c: In function ‘ctx_set_TLSv13_func’: src/ssl_sock.c:2178:5: error: missing binary operator before token "1" 2178 | #if SSL_OP_NO_TLSv1_3 | ^ Kurt
Bug#996422: golang-github-mendersoftware-openssl: FTBFS with OpenSSL 3.0
Source: golang-github-mendersoftware-openssl Version: 1.1.0-2 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: github.com/mendersoftware/openssl # github.com/mendersoftware/openssl src/github.com/mendersoftware/openssl/fips.go:31:7: could not determine kind of name for C.FIPS_mode_set dh_auto_build: error: cd _build && go install -trimpath -v -p 1 github.com/mendersoftware/openssl github.com/mendersoftware/openssl/utils returned exit code 2 make: *** [debian/rules:4: binary] Error 25 For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#996421: globus-proxy-utils: FTBFS with OpenSSL 3.0
Source: globus-proxy-utils Version: 7.2-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: make[4]: Entering directory '/<>/test' FAIL: grid-proxy-utils-test.pl FAIL: proxy-order-test.pl = globus_proxy_utils 7.2: test/test-suite.log = # TOTAL: 2 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 2 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: grid-proxy-utils-test.pl == # PATH = ../programs:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games # X509_CERT_DIR = /<>/test 1..33 ok 1 - create_proxy not ok 2 - grid-proxy-info # Failed test 'grid-proxy-info ' # at ./grid-proxy-utils-test.pl line 38. not ok 3 - grid-proxy-info type is RFC 3820 compliant impersonation proxy # Failed test 'grid-proxy-info type is RFC 3820 compliant impersonation proxy' # at ./grid-proxy-utils-test.pl line 41. ok 4 - create_proxy -draft not ok 5 - grid-proxy-info -draft [...] Kurt
Bug#996420: globus-gssapi-gsi: FTBFS with OpenSSL 3.0
Source: globus-gssapi-gsi Version: 14.17-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: FAIL: gssapi-thread-test-wrapper 1..1 Segmentation fault FAIL gssapi-thread-test-wrapper (exit status: 1) FAIL: import-cred-test.pl = 1..3 ERROR: GSS Major Status: General failure ERROR: GSS Minor Status Error Chain: globus_gsi_gssapi: Unable to read credential for import globus_gsi_gssapi: Error with GSI credential globus_credential: Error reading proxy credential: Couldn't read PEM from bio OpenSSL Error: ../crypto/bio/bio_lib.c:518: in library: BIO routines, function BIO_ctrl: unsupported method not ok 1 - test_import_data # Failed test 'test_import_data' # at ./import-cred-test.pl line 23. ERROR: GSS Major Status: General failure [...] Kurt
Bug#996275: [Pkg-erlang-devel] Bug#996275: coturn: FTBFS with OpenSSL 3.0
On Wed, Oct 13, 2021 at 07:43:26AM +0300, Sergei Golovan wrote: > > This is a known issue, see https://github.com/erlang/otp/issues/4577 > and I'm afraid the fix will come only with the new major Erlang 25. > It's expected to be released in May 2022. As far as I know, there are 2 issues: - The call to FIPS_mode no longer exists. This has probably never worked in Debian in the first place, so a possible solution for that would be just to remove the call. - Warnings about deprecated functions. Those are just warnings, the functions aren't going to go away soon, but will at some point in the future. So this is something we should be able to ignore until upstream fixes it. I currently don't know when the transition will start. Kurt
Bug#996288: globus-gsi-openssl-error: FTBFS with OpenSSL 3.0
Source: globus-gsi-openssl-error Version: 4.3-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: not ok 4 - Match reference output # Failed test 'Match reference output' # at ./globus-openssl-error-test.pl line 38. # Looks like you failed 1 test of 4. FAIL globus-openssl-error-test.pl (exit status: 1) Kurt
Bug#996287: git-crypt: FTBFS with OpenSSL 3.0
Source: git-crypt Version: 0.6.0-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: crypto-openssl-10.cpp: In constructor Aes_ecb_encryptor::Aes_ecb_encryptor(const unsigned char*): crypto-openssl-10.cpp:59:60: warning: int AES_set_encrypt_key(const unsigned char*, int, AES_KEY*) is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 59 | if (AES_set_encrypt_key(raw_key, KEY_LEN * 8, &(impl->key)) != 0) { |^ In file included from crypto-openssl-10.cpp:38: /usr/include/openssl/aes.h:51:5: note: declared here 51 | int AES_set_encrypt_key(const unsigned char *userKey, const int bits, | ^~~ crypto-openssl-10.cpp: In member function void Aes_ecb_encryptor::encrypt(const unsigned char*, unsigned char*): crypto-openssl-10.cpp:74:41: warning: void AES_encrypt(const unsigned char*, unsigned char*, const AES_KEY*) is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 74 | AES_encrypt(plain, cipher, &(impl->key)); | ^ In file included from crypto-openssl-10.cpp:38: /usr/include/openssl/aes.h:57:6: note: declared here 57 | void AES_encrypt(const unsigned char *in, unsigned char *out, | ^~~ crypto-openssl-10.cpp: At global scope: crypto-openssl-10.cpp:78:11: error: field ctx has incomplete type HMAC_CTX {aka hmac_ctx_st} 78 | HMAC_CTX ctx; | ^~~ In file included from /usr/include/openssl/evp.h:26, from /usr/include/openssl/hmac.h:21, from crypto-openssl-10.cpp:40: /usr/include/openssl/types.h:132:16: note: forward declaration of HMAC_CTX {aka struct hmac_ctx_st} 132 | typedef struct hmac_ctx_st HMAC_CTX; |^~~ crypto-openssl-10.cpp: In destructor Hmac_sha1_state::~Hmac_sha1_state(): crypto-openssl-10.cpp:92:2: error: HMAC_cleanup was not declared in this scope; did you mean EVP_cleanup? 92 | HMAC_cleanup(&(impl->ctx)); | ^~~~ | EVP_cleanup make[1]: *** [: crypto-openssl-10.o] Error 1 Kurt
Bug#996286: freerdp2: FTBFS with OpenSSL 3.0
Source: freerdp2 Version: 2.3.0+dfsg1-2 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: /<>/winpr/libwinpr/utils/ssl.c /<>/winpr/libwinpr/utils/ssl.c: In function ‘winpr_enable_fips’: /<>/winpr/libwinpr/utils/ssl.c:247:7: warning: implicit declaration of function ‘FIPS_mode’ [-Wimplicit-function-declaration] 247 | if (FIPS_mode() != 1) | ^ /<>/winpr/libwinpr/utils/ssl.c:249:8: warning: implicit declaration of function ‘FIPS_mode_set’ [-Wimplicit-function-declaration] 249 |if (FIPS_mode_set(1)) |^ [...] /usr/bin/ld: ../../libwinpr/libwinpr2.so.2.3.0: undefined reference to `FIPS_mode_set' /usr/bin/ld: ../../libwinpr/libwinpr2.so.2.3.0: undefined reference to `FIPS_mode' collect2: error: ld returned 1 exit status For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#996285: freelan: FTBFS with OpenSSL 3.0
Source: freelan Version: 2.2-3 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: build/release/libs/cryptoplus/include/cryptoplus/bio/../cipher/../error/error.hpp: In function ‘int cryptoplus::error::get_function_error(cryptoplus::error::error_type)’: build/release/libs/cryptoplus/include/cryptoplus/bio/../cipher/../error/error.hpp:243:11: error: ‘ERR_GET_FUNC’ was not declared in this scope; did you mean ‘ERR_GET_LIB’? 243 |return ERR_GET_FUNC(err.error_code); | ^~~~ | ERR_GET_LIB For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#996275: coturn: FTBFS with OpenSSL 3.0
Source: erlang Version: 24.0.6+dfsg-2 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: pkey.c:76:14: error: implicit declaration of function FIPS_mode [-Werror=implicit-function-declaration] 76 | if (!FIPS_mode()) return PKEY_OK; | ^ For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html There are also various warnings about deprecated functions which you might want to look at. Kurt
Bug#996276: foxeye: FTBFS with OpenSSL 3.0
Source: foxeye_0.12.1-3 Version: 0.12.1-3 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: openssl.c:450:5: warning: implicit declaration of function FIPS_mode_set [-Wimplicit-function-declaration] 450 | FIPS_mode_set(0); | ^ [...] /usr/bin/ld: openssl.o: in function `module_signal': ./modules/ssl/openssl.c:450: undefined reference to `FIPS_mode_set' For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#996274: erlang-p1-tls: FTBFS with OpenSSL 3.0
Source: erlang-p1-tls Version: 1.1.13-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: EUnit module 'fast_tls' fast_tls: transmission_with_client_certificate_test...*failed* in function fast_tls:transmission_test_with_opts/2 (fast_tls.erl, line 492) in call from eunit_test:'-mf_wrapper/2-fun-0-'/2 (eunit_test.erl, line 273) in call from eunit_test:run_testfun/1 (eunit_test.erl, line 71) in call from eunit_proc:run_test/1 (eunit_proc.erl, line 522) in call from eunit_proc:with_timeout/3 (eunit_proc.erl, line 347) in call from eunit_proc:handle_test/2 (eunit_proc.erl, line 505) in call from eunit_proc:tests_inorder/3 (eunit_proc.erl, line 447) in call from eunit_proc:with_timeout/3 (eunit_proc.erl, line 337) **error:{assertEqual,[{module,fast_tls}, {line,492}, {expression,"Msg"}, {expected,<<"abcdefghi">>}, {value,{error,<<"SSL_do_handshake failed: error:1"...>>,<<>>}}]} output:<<"">> fast_tls: transmission_without_client_certificate_test...[0.409 s] ok fast_tls: transmission_without_server_cert_fails_test...ok fast_tls: not_compatible_protocol_options_test...*failed* in function fast_tls:not_compatible_protocol_options_test/0 (fast_tls.erl, line 510) in call from eunit_test:'-mf_wrapper/2-fun-0-'/2 (eunit_test.erl, line 273) in call from eunit_test:run_testfun/1 (eunit_test.erl, line 71) in call from eunit_proc:run_test/1 (eunit_proc.erl, line 522) in call from eunit_proc:with_timeout/3 (eunit_proc.erl, line 347) in call from eunit_proc:handle_test/2 (eunit_proc.erl, line 505) in call from eunit_proc:tests_inorder/3 (eunit_proc.erl, line 447) in call from eunit_proc:with_timeout/3 (eunit_proc.erl, line 337) **error:{assertMatch,[{module,fast_tls}, {line,510}, {expression,"Res"}, {pattern,"{ badmatch , { error , _ } }"}, {value,ok}]} output:<<"">> [done in 1.244 s] Kurt
Bug#996273: dovecot: FTBFS with OpenSSL 3.0
Source: dovecot Version: 2.3.16+dfsg1-3 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: test_get_info_pw_encrypted ... : ok test-crypto.c:827: Assert failed: ret == TRUE Panic: file dcrypt-openssl.c: line 2642 (dcrypt_openssl_private_to_public_key): assertion failed: (priv_key != NULL && pub_key_r != NULL) Error: Raw backtrace: ./test-crypto(+0x53775) [0x55cb6b24d775] -> ./test-crypto(backtrace_get+0x1c) [0x55cb6b24d8ec] -> ./test-crypto(+0x2b23b) [0x55cb6b22523b] -> ./test-crypto(+0x2b271) [0x55cb6b225271] -> ./test-crypto(+0x14d1a) [0x55cb6b20ed1a] -> .libs/libdcrypt_openssl.so(+0x618d) [0x7f5058c9018d] -> ./test-crypto(+0x253fa) [0x55cb6b21f3fa] -> ./test-crypto(+0x2a63d) [0x55cb6b22463d] -> ./test-crypto(test_run+0x5f) [0x55cb6b2246df] -> ./test-crypto(main+0x4c) [0x55cb6b2136dc] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f5058cc9e4a] -> ./test-crypto(_start+0x2a) [0x55cb6b21381a] /bin/bash: line 1: 161575 Aborted ./$bin Kurt
Bug#996272: crda: FTBFS with OpenSSL 3.0
Source: crda Version: 4.14+git20191112.9856751-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: reglib.c: In function reglib_verify_db_signature: reglib.c:122:5: error: PEM_read_RSA_PUBKEY is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 122 | rsa = PEM_read_RSA_PUBKEY(keyfile, | ^~~ In file included from reglib.c:24: /usr/include/openssl/pem.h:449:1: note: declared here 449 | DECLARE_PEM_rw_attr(OSSL_DEPRECATEDIN_3_0, RSA_PUBKEY, RSA) | ^~~ reglib.c:125:6: error: RSA_verify is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 125 | ok = RSA_verify(NID_sha1, hash, SHA_DIGEST_LENGTH, | ^~ In file included from reglib.c:22: /usr/include/openssl/rsa.h:351:27: note: declared here 351 | OSSL_DEPRECATEDIN_3_0 int RSA_verify(int type, const unsigned char *m, | ^~ reglib.c:127:5: error: RSA_free is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 127 | RSA_free(rsa); | ^~~~ In file included from reglib.c:22: /usr/include/openssl/rsa.h:293:28: note: declared here 293 | OSSL_DEPRECATEDIN_3_0 void RSA_free(RSA *r); |^~~~ cc1: all warnings being treated as errors The short term solution is to drop the -Werror. Longer term the functions need to get replaced with non-deprecated versions. For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#995660: clickhouse: FTBFS with OpenSSL 3.0
Source: clickhouse Version: 18.16.1+ds-7.2 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: 11: + openssl dhparam -out /tmp/clickhouse.test..wbgfY/etc/dhparam.pem 256 11: Generating DH parameters, 256 bit long safe prime 11: dhparam: Generating DH key parameters failed 11: 40A7B5ED9C7F:error:0280007E:Diffie-Hellman routines:dh_builtin_genparams:modulus too small:../crypto/dh/dh_gen.c:168: 11/11 Test #11: with_server ***Failed0.06 sec The minimum size that it now allows you to generate is 512 bit, which might be good for a test suite, but is too short for real parameters. Kurt
Bug#995659: coturn: FTBFS with OpenSSL 3.0
Source: coturn Version: 4.5.2-3 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: src/client/ns_turn_msg.c: In function stun_produce_integrity_key_str: src/client/ns_turn_msg.c:260:7: warning: implicit declaration of function FIPS_mode [-Wimplicit-function-declaration] 260 | if (FIPS_mode()) { | ^ [...] /usr/bin/ld: lib/libturnclient.a(ns_turn_msg.o): in function `stun_produce_integrity_key_str': ./src/client/ns_turn_msg.c:260: undefined reference to `FIPS_mode' collect2: error: ld returned 1 exit status For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#995657: clevis: FTBFS with OpenSSL 3.0
Source: clevis Version: 18-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: In file included from ../src/pins/sss/sss.c:41: ../src/pins/sss/sss.c: In function ‘sss_point’: ../src/pins/sss/sss.c:217:9: error: void value not ignored as it ought to be 217 | if (BN_zero(yy) <= 0) | ^~~ ../src/pins/sss/sss.c: In function ‘sss_recover’: ../src/pins/sss/sss.c:275:9: error: void value not ignored as it ought to be 275 | if (BN_zero(k) <= 0) | ^~~ ../src/pins/sss/sss.c:306:17: error: void value not ignored as it ought to be 306 | if (BN_zero(tmp) <= 0) | ^~~ ninja: build stopped: subcommand failed. The manpage says: In OpenSSL 0.9.8, BN_zero() was changed to not return a value; previous versions returned an int. Kurt
Bug#995644: lebiniou: Fails to upgrade: trying to overwrite '/usr/share/lebiniou/etc/schemes.json'
Package: lbeibiou Version: 3.61.2-1 Severity: serious Hi, During an upgrade, I get the following: dpkg: considering deconfiguration of lebiniou-data, which would be broken by installation of lebiniou ... dpkg: yes, will deconfigure lebiniou-data (broken by lebiniou) Preparing to unpack .../110-lebiniou_3.61.2-1+b1_amd64.deb ... De-configuring lebiniou-data (3.54.1-1) ... Unpacking lebiniou (3.61.2-1+b1) over (3.54.1-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-dU3HYR/110-lebiniou_3.61.2-1+b1_amd64.deb (--unpack): trying to overwrite '/usr/share/lebiniou/etc/schemes.json', which is also in package lebiniou-data 3.54.1-1 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) dpkg: considering deconfiguration of lebiniou, which would be broken by installation of lebiniou-data ... dpkg: yes, will deconfigure lebiniou (broken by lebiniou-data) Preparing to unpack .../111-lebiniou-data_3.61.1-1_all.deb ... De-configuring lebiniou (3.54.1-1) ... Unpacking lebiniou-data (3.61.1-1) over (3.54.1-1) ... This looks like it's missing a Replaces. A Breaks is not enough. Trying again, it works because lebiniou-data got updated. I'm not sure why the file moved from lebiniou-data to lebiniou. Kurt
Bug#995643: cjose: FTBFS with OpenSSL 3.0
Source: cjose Version: 0.6.1+dfsg1-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: jwk.c: In function _cjose_jwk_rsa_get: jwk.c:58:5: error: RSA_get0_key is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 58 | RSA_get0_key(rsa, (const BIGNUM **)rsa_n, (const BIGNUM **)rsa_e, (const BIGNUM **)rsa_d); | ^~~~ In file included from ../include/cjose/util.h:21, from jwk.c:12: /usr/include/openssl/rsa.h:217:28: note: declared here 217 | OSSL_DEPRECATEDIN_3_0 void RSA_get0_key(const RSA *r, |^~~~ jwk.c: In function _cjose_jwk_rsa_set: jwk.c:82:5: error: RSA_set0_key is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 82 | return RSA_set0_key(rsa, rsa_n, rsa_e, rsa_d) == 1; | ^~ [...] The short term solution is to drop the -Werror. Longer term the functions need to get replaced with non-deprecated versions. For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#995642: cfengine3: FTBFS with OpenSSL 3.0
Source: cfengine3 Version: 3.15.2-3 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: In file included from hash.c:33: ./hash.h:64:28: error: unknown type name RSA 64 | Hash *HashNewFromKey(const RSA *rsa, HashMethod method); |^~~ ./hash.h:163:23: error: unknown type name RSA 163 | void HashPubKey(const RSA *key, unsigned char digest[EVP_MAX_MD_SIZE + 1], HashMethod type); | ^~~ hash.c:214:28: error: unknown type name RSA 214 | Hash *HashNewFromKey(const RSA *rsa, HashMethod method) |^~~ hash.c: In function HashNewFromKey: hash.c:226:5: error: implicit declaration of function RSA_get0_key [-Werror=implicit-function-declaration] 226 | RSA_get0_key(rsa, , , NULL); | ^~~~ hash.c: At top level: hash.c:531:11: error: unknown type name RSA 531 | const RSA *const key, | ^~~ cc1: some warnings being treated as errors I'm not sure why you don't get the RSA type, it should still exists. However, those functions have been deprecated, so you'll need to replace them at some point. For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#995641: certmonger: FTBFS with OpenSSL 3.0
Source: certmonger Version: 0.79.13-3 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: ../../src/util-o.c: In function util_EVP_PKEY_id: ../../src/util-o.c:333:13: error: invalid use of incomplete typedef EVP_PKEY {aka const struct evp_pkey_st} 333 | return pkey->type; | ^~ This looks like it's code for compatibility with OpenSSL older than 1.1.0 that's being build when building against 3.0. There are also other errors and warings related to OpenSSL 3.0. For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#995640: boxbackup: FTBFS with OpenSSL 3.0
Source: boxbackup Version: 0.13~~git20200326.g8e8b63c-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: NOTICE: Running test bbackupd in debug mode... ERROR: SSL or crypto error: initialising cipher: error:0308010C:digital envelope routines::unsupported WARNING: Exception thrown: CipherException(EVPInitFailure) (Failed to initialise Blowfish56-CBC: error:0308010C:digital envelope routines::unsupported) at lib/crypto/CipherContext.cpp:124 FAILED: Exception caught: EVPInitFailure: Failed to initialise Blowfish56-CBC: error:0308010C:digital envelope routines::unsupported [...] Some ciphers have been moved to the legacy provider and are no longer available by default. For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#995639: botan: FTBFS with OpenSSL 3.0
Source: botan Version: 2.18.1+dfsg-3 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: Thread_Pool ran 100 tests all ok tls: 3DES ECDH ran 2 tests 2 FAILED Failure 1: EVP_EncryptInit_ex failed: error:0308010C:digital envelope routines::unsupported Failure 2: EVP_EncryptInit_ex failed: error:0308010C:digital envelope routines::unsupported 3DES RSA ran 2 tests 2 FAILED Failure 1: EVP_EncryptInit_ex failed: error:0386:digital envelope routines::initialization error Failure 2: EVP_EncryptInit_ex failed: error:0308010C:digital envelope routines::unsupported AES-128 DH ran 1 tests 1 FAILED Failure 1: EVP_EncryptInit_ex failed: error:0308010C:digital envelope routines::unsupported AES-128 DHE_PSK ran 1 tests 1 FAILED Failure 1: EVP_EncryptInit_ex failed: error:0308010C:digital envelope routines::unsupported AES-128 ECDH ran 2 tests 2 FAILED Failure 1: EVP_EncryptInit_ex failed: error:0308010C:digital envelope routines::unsupported Failure 2: EVP_EncryptInit_ex failed: error:0308010C:digital envelope routines::unsupported AES-128 ECDHE_PSK ran 1 tests 1 FAILED Failure 1: EVP_EncryptInit_ex failed: error:0308010C:digital envelope routines::unsupported [...] It's unclear why they would be unsupported. For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#995637: boinc: FTBFS with OpenSSL 3.0
Source: boinc Version: 7.16.17+dfsg-2 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with the following error: In file included from /usr/include/openssl/x509.h:29, from /usr/include/openssl/ssl.h:31, from crypt.cpp:36: /usr/include/openssl/evp.h:1346:22: note: declared here 1346 | const struct rsa_st *EVP_PKEY_get0_RSA(const EVP_PKEY *pkey); | ^ crypt.cpp:676:32: error: invalid conversion from const rsa_st* to RSA* {aka rsa_st*} [-fpermissive] 676 | rsa = EVP_PKEY_get0_RSA(pubKey); | ~^~~~ || |const rsa_st* The return value of EVP_PKEY_get0_RSA() has been made const in OpenSSL 3.0, so you need to change "rsa" to "const RSA *". Note that there are also various other warnings about deprecated functions. For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#995636: transition: openssl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We would like to transition to OpenSSL 3.0.0. It's currently in experimental. It has an soname change, so the binary packages got renamed and binNMUs will be required. We did a rebuild of packages and currently have 105 packages that FTBFS with OpenSSL 3.0.0 that build with 1.1.1. I've started filing bugs for that: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-openssl-de...@lists.alioth.debian.org=ftbfs-3.0 Kurt
Bug#995635: azure-uamqp-python: FTBFS with OpenSSL 3.0
Source: azure-uamqp-python Version: 1.4.1-1 Severity: important Tags: bookworm sid User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Hi, Your package is failing to build using OpenSSL 3.0 with errors like: /<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c: In function load_certificate_chain: /<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c:81:28: error: invalid use of incomplete typedef SSL_CTX {aka struct ssl_ctx_st} 81 | if (ssl_ctx->extra_certs != NULL) |^~ In file included from /usr/include/openssl/ssl.h:31, from /<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/inc/azure_c_shared_utility/x509_openssl.h:7, from /<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c:4: /<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c:83:45: error: invalid use of incomplete typedef SSL_CTX {aka struct ssl_ctx_st} 83 | sk_X509_pop_free(ssl_ctx->extra_certs, X509_free); | ^~ /<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c:84:28: error: invalid use of incomplete typedef SSL_CTX {aka struct ssl_ctx_st} 84 | ssl_ctx->extra_certs = NULL; |^~ /<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c: In function load_key_RSA: /<>/src/vendor/azure-uamqp-c/deps/azure-c-shared-utility/adapters/x509_openssl.c:140:5: error: EVP_PKEY_get1_RSA is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 140 | RSA* privatekey = EVP_PKEY_get1_RSA(evp_key); | ^~~ At least some of those errors are caused by using deprecated function in combination with -Werror. I'm not sure why you get the other errors, since that's not changed between 1.1 and 3.0. For more information see: https://www.openssl.org/docs/man3.0/man7/migration_guide.html Kurt
Bug#995634: autobahn-cpp: FTBFS with OpenSSL 3.0: Uses -Werror and deprecated functions
Source: autobahn-cpp Version: 17.5.1+git7cc5d37-2.1 Severity: important User: pkg-openssl-de...@lists.alioth.debian.org Usertags: ftbfs-3.0 Your package is building using -Werror and is using functions that have been deprecated in OpenSSL 3.0. The log contains errors like: In file included from /<>/autobahn/wamp_session.ipp:48, from /<>/autobahn/wamp_session.hpp:403, from /<>/autobahn/autobahn.hpp:42, from /<>/examples/callee.cpp:33: /<>/autobahn/wamp_auth_utils.hpp: In function std::string compute_wcs(const string&, const string&): /<>/autobahn/wamp_auth_utils.hpp:169:35: error: HMAC_CTX* HMAC_CTX_new() is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] 169 | HMAC_CTX *hmac = HMAC_CTX_new(); | ^ The short time solution is to remove the -Werror, which will turn it into a warning. For a longer term solution, see https://www.openssl.org/docs/man3.0/man7/migration_guide.html#Deprecated-low-level-MAC-functions Kurt
Bug#990369: cfengine3: FTBFS with OpenSSL 3.0
Package: cfengine3 Version: 3.15.2-3 Hi, cfengine3 fails to build with OpenSSL 3.0 beta 1 with the following error: In file included from hash.c:33: ./hash.h:64:28: error: unknown type name RSA 64 | Hash *HashNewFromKey(const RSA *rsa, HashMethod method); |^~~ ./hash.h:163:23: error: unknown type name RSA 163 | void HashPubKey(const RSA *key, unsigned char digest[EVP_MAX_MD_SIZE + 1], HashMethod type); | ^~~ hash.c:214:28: error: unknown type name RSA 214 | Hash *HashNewFromKey(const RSA *rsa, HashMethod method) |^~~ hash.c: In function HashNewFromKey: hash.c:226:5: error: implicit declaration of function RSA_get0_key [-Werror=implicit-function-declaration] 226 | RSA_get0_key(rsa, , , NULL); | ^~~~ hash.c: At top level: hash.c:531:11: error: unknown type name RSA 531 | const RSA *const key, | ^~~ cc1: some warnings being treated as errors Those functions and types are deprecated, and libntech/configure.ac seems to OPENSSL_NO_DEPRECATED. Kurt
Bug#990364: certmonger: FTBFS with OpenSSL 3.0
Package: certmonger Version: 0.79.13-3 Hi, Your package is failing to build with OpenSSL 3.0 beta 1. The problem is that EVP_PKEY_base_id has been renamed to EVP_PKEY_get_base_id. There is a define to rename it: /usr/include/openssl/evp.h:# define EVP_PKEY_base_id EVP_PKEY_get_base_id But your configure script does not include evp.h to test for the presence of EVP_PKEY_base_id, claiming it doesn't exists, and then falls back to in util_EVP_PKEY_id() to use pkey->type which fails. Kurt
Bug#990363: caml-crush: FTBFS with OpenSSL 3.0
Package: caml-crush Version: 1.0.10-4 Hi, Your package is failing to build against OpenSSL 3.0 beta 1. The log file show: configure:6589: checking for SSL_get_peer_certificate in -lssl configure:6614: gcc -o conftest -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -I/usr/lib/ocaml -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/lib/ocaml -Wl,-z,relro conftest.c -lssl -lc >&5 /usr/bin/ld: /tmp/cc4uEWWT.o: in function `main': ./build-SERVER/conftest.c:38: undefined reference to `SSL_get_peer_certificate' collect2: error: ld returned 1 exit status configure:6614: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "cam-crush" | #define PACKAGE_TARNAME "cam-crush" | #define PACKAGE_VERSION "1.0.10" | #define PACKAGE_STRING "cam-crush 1.0.10" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_CAML_MLVALUES_H 1 | #define HAVE_CAML_CAMLIDLRUNTIME_H 1 | #define HAVE_DLFCN_H 1 | #define HAVE_PTHREAD_H 1 | #define HAVE_RPC_RPC_H 1 | #define HAVE_RPC_CLNT_H 1 | #define HAVE_LIBC 1 | #define HAVE_OPENSSL_SSL_H 1 | /* end confdefs.h. */ | | /* Override any GCC internal prototype to avoid an error. |Use char because int might match the return type of a GCC |builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char SSL_get_peer_certificate (); | int | main () | { | return SSL_get_peer_certificate (); | ; | return 0; | } configure:6623: result: no configure:6628: error: Cannot find symbol in openssl library. The function has been renamed, and the old name deprecated in 3.0. The header file actually has a define from the old name to the new name: # ifndef OPENSSL_NO_DEPRECATED_3_0 # define SSL_get_peer_certificate SSL_get1_peer_certificate # endif The easy fix is to actually include ssl.h when looking for symbol, so that you actually look for the renamed symbol. Kurt
Bug#990228: [Pkg-openssl-devel] Bug#990228: Bug#990228: Bug#990228: Bug#990228: openssl: breaks ssl-cert installation: 8022CB35777F0000:error:1200007A:random number generator:RAND_write_file:Not a reg
reassign 990228 ssl-cert severity 990228 normal thanks So I think there is no bug in OpenSSL and the additional check being done in 3.0 makes sense. So I'm reassigning this to ssl-cert. Kurt
Bug#990228: [Pkg-openssl-devel] Bug#990228: Bug#990228: Bug#990228: openssl: breaks ssl-cert installation: 8022CB35777F0000:error:1200007A:random number generator:RAND_write_file:Not a regular file:..
On Thu, Jun 24, 2021 at 12:20:45AM +0200, Kurt Roeckx wrote: > > From the manpage: >Random State Options > >Prior to OpenSSL 1.1.1, it was common for applications to store >information about the state of the random-number generator in a >file that was loaded at startup and rewritten upon exit. On >modern operating systems, this is generally no longer necessary >as OpenSSL will seed itself from a trusted entropy source >provided by the operating system. These flags are still supported >for special platforms or circumstances that might require them. > > Reading something from /dev/urandom and then writing it back to it > doesn't make sense to me. > > The expected behaviour is that you can read back the file you've > written, which clearly is not what /dev/urandom does. > > If you need to save the file, you actually want a file that's still > there after a reboot. > > I would recommend to just remove the option from the config file. > > That being said, the manpage seems to indicate that a non-regular > file should also be supported for reading, but it's unclear if > that also applies to writing, and would assume it is, so this also > looks like a bug in OpenSSL. The reason for the check that it's not a regular file is that you actually want to be able to delete it's content, so that you're sure it's not reused. But OpenSSL APIs for actually properly implementing it aren't that great to start with. Kurt
Bug#990228: [Pkg-openssl-devel] Bug#990228: Bug#990228: openssl: breaks ssl-cert installation: 8022CB35777F0000:error:1200007A:random number generator:RAND_write_file:Not a regular file:../crypto/rand
On Wed, Jun 23, 2021 at 09:05:03PM +0200, Sebastian Andrzej Siewior wrote: > On 2021-06-23 14:46:37 [+0200], Andreas Beckmann wrote: > > Writing new private key to '/etc/ssl/private/ssl-cert-snakeoil.key' > > - > > Warning: No -copy_extensions given; ignoring any extensions in the request > > Cannot write random bytes: > > 8022CB35777F:error:127A:random number > > generator:RAND_write_file:Not a regular > > file:../crypto/rand/randfile.c:190:Filename=/dev/urandom > … > > Hmm, well, yes, /dev/urandom is not a regular file. It's a character device > > node. > > This is from > -config $file > -> > RANDFILE= /dev/urandom > > The reject of file nodes is new in the 3.0.0 release. > In the past openssl used to have its .rnd where it keept track of a > random state. So it read the RANDFILE to seed and wrote it back to avoid > having the state on the next invocation. > This is gone since 1.1.0 (I think) and openssl uses getrandom() to > initialize its random generator. It is no longer needed to specify > /dev/urandom as RANDFILE to seed it initially. > In this case it will read urandom and use additionally getrandom() and > both provide pseude-random data from exactly the same pool. And then > after the operation, openssl will write it back… > > I would argue to remove RANDFILE from the template. On the other hand > there is nothing wrong with writting it back to a device node file. > > Kurt? >From the manpage: Random State Options Prior to OpenSSL 1.1.1, it was common for applications to store information about the state of the random-number generator in a file that was loaded at startup and rewritten upon exit. On modern operating systems, this is generally no longer necessary as OpenSSL will seed itself from a trusted entropy source provided by the operating system. These flags are still supported for special platforms or circumstances that might require them. Reading something from /dev/urandom and then writing it back to it doesn't make sense to me. The expected behaviour is that you can read back the file you've written, which clearly is not what /dev/urandom does. If you need to save the file, you actually want a file that's still there after a reboot. I would recommend to just remove the option from the config file. That being said, the manpage seems to indicate that a non-regular file should also be supported for reading, but it's unclear if that also applies to writing, and would assume it is, so this also looks like a bug in OpenSSL. Kurt
Bug#985158: gpg: No longer reads .gnupg/options
Package: gpg Version: 2.2.27-1 Severity: important Hi, It seems that the config file ~/.gnupg/options is no longer read, and it's now reading (among others) ~/.gnupg/gpg.conf Jakub Wilk bisected it and pointed to this commit: https://github.com/gpg/gnupg/commit/a028f24136a062f5 It's not the type of change I expect in the 2.2 series. It's also not mentioned anywhere is a changelog or news entry. Kurt
Bug#983722: [Pkg-openssl-devel] Bug#983722: libssl1.1: drop upgrade support from old-old-old-stable from maintainer script
On Sun, Feb 28, 2021 at 10:00:35PM +0100, Helmut Grohne wrote: > Hi Kurt, > > On Sun, Feb 28, 2021 at 09:48:04PM +0100, Kurt Roeckx wrote: > > I think you at least misunderstand the purpose of the script, but > > we've also not used it in a very long time. > > I think I do understand the purpose, but it does not presently serve the > stated purpose. Given that the checked version is so ancient, it is > effectively dead code. To activate it, the version in the postinst gets updated. But like I said, it's not been activated in a long time, so maybe it is dead code. > > It's meant to restart all services that make use of openssl when a > > security update is released. I guess I switched to "checkrestart" > > myself, so never had the need to use it myself anymore. > > That or needrestart. I don't think that the general expectation these > days is that upgrading a library restarts affected services. Exceptions > to this rule include nss (libc6) and pam updates as failing to restart > services can result in them becoming dysfunctional. For most other > cases, an external checker is the recommended best practice. I'm not sure users are aware that they need to restart the services (or reboot) to fix the security issues. We still lack a way to indicate that to the user. I would really like to see a general fix for this. > Unless you wish to reactivate this code with a current version, I think > it should be deleted. If you do, please close this bug with a wontfix > tag. I guess you mean "If you don't". Anyway, the template code and translations can all be deleted too if that patch is applied. Kurt
Bug#983722: [Pkg-openssl-devel] Bug#983722: libssl1.1: drop upgrade support from old-old-old-stable from maintainer script
On Sun, Feb 28, 2021 at 09:26:28PM +0100, Helmut Grohne wrote: > Package: libssl1.1 > Version: 1.1.1j-1 > Tags: patch > User: debian-d...@lists.debian.org > Usertags: dpkg-root-support > > The libssl1.1 package ships a maintainer script whose entire purpose is > supporting upgrades from old-old-old-stable. Since Debian does not > support skipping releases, it seems like this code can be safely > dropped. The good thing about dropping it is that code that isn't there > doesn't have to support DPKG_ROOT. Please consider applying the attached > patch. I think you at least misunderstand the purpose of the script, but we've also not used it in a very long time. It's meant to restart all services that make use of openssl when a security update is released. I guess I switched to "checkrestart" myself, so never had the need to use it myself anymore. Kurt
Bug#983013: [Pkg-openssl-devel] Bug#983013: m2crypto: autopkgtest needs update for new version of openssl: M2Crypto.RSA.RSAError: sslv3 rollback attack
forwarded 983013 https://gitlab.com/m2crypto/m2crypto/-/issues/293 thanks I've created an upstream issue for it.
Bug#982645: CVE-2018-3640 on N3160
Package: intel-microcode Version: 3.20201118.1~deb10u1 Hi, spectre-meltdown-checker reports: CVE-2018-3640 aka 'Variant 3a, rogue system register read' * CPU microcode mitigates the vulnerability: NO > STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this > vulnerability) /proc/cpuinfo says: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 76 model name : Intel(R) Celeron(R) CPU N3160 @ 1.60GHz stepping: 4 microcode : 0x411 cpu MHz : 700.500 cache size : 1024 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 dmesg reports: [0.00] microcode: microcode updated early to revision 0x411, date = 2019-04-23 [...] [2.012058] microcode: sig=0x406c4, pf=0x1, revision=0x411 Can you clarify if a microcode update is missing, just not available or that spectre-meltdown-checker is wrong? Kurt
Bug#959469: buster-pu: package openssl/1.1.1g-1
On Thu, Jan 14, 2021 at 07:03:37PM +0100, Kurt Roeckx wrote: > There are a whole bunch of other issues and pull requests related to > this. I hope this is the end of the regressions in the X509 code. So there is something else now: https://github.com/openssl/openssl/issues/13931 https://github.com/openssl/openssl/pull/13982 Kurt
Bug#980302: dictionaries-common-dev: vim dictionary support
On Tue, Jan 19, 2021 at 10:55:28AM +0100, Agustin Martin wrote: > One thing, do you know if processed vim dictionaries are arch:all? I have no idea, but I assume it is. Kurt
Bug#980302: dictionaries-common-dev: vim dictionary support
On Mon, Jan 18, 2021 at 07:34:55PM +0100, Agustin Martin wrote: > > Note that I need to patch the .aff files to actually make it work > > properly because vim doesn't implement all the same things > > hunspell does. > > Knowing that vim does not use standard hunspell files makes things > more clear. I thought you meant something like what is done for aspell > or ispell dicts, allowing hashes to be built at postinst stage. > However, seems that what you would like is to recover something like > vim-spellfiles, but adapted to current vim. Vim has it's own file format and implementation that works totally different than hunspell, and so needs to convert it to it's own format. I have no idea what vim-spellfiles was, it only seems to have been in experimental. Vim has various files on it's ftp site at: https://ftp.nluug.nl/vim/runtime/spell/ I assume someone packaged up all the files from the ftp site. As you can see at https://github.com/vim/vim/tree/master/runtime/spell most haven't been updated in the past 10 years, nor is the source of them actually available, just a patch against something, and it's unclear to me to which version the patch is. I haven't tried to run the aap script to see if it can actually still fetch the source. If you have the input files, it's easy to generate the files from it. > > I was looking at the libhunspell patch upstream, which seems to be > > going nowhere, the pull requests was closed because it wasn't > > complete and nobody seems to want to fix it. > > > > > On the other hand most hunspell dicts come from libreoffice-dicts and > > > do not provide a dict-common info file. In my TODO list there is a > > > point to play with libreoffice-dicts build process to automatically > > > create a minimal info file, but it has been there for years due to > > > lack of both time and python skills at that time. > > > > I have no idea what those files are used for, so I can't even test > > that they are correct or not. I assume that it might have something > > to do with emacs, but I'm a vim user, not an emacs user. > > Note that I was thinking about autobuild, and for ispell and aspell > some info may be there for hash autobuild, together with for other > things like Emacs or jed. > > I do not object adding a vim section to policy if there is need to > coordinate with packages outside the vim environment. However, from > what I seem to understand, everything is inside vim ecosystem. > spellchecker is part of vim, hunspell dicts need to be adapted for vim > and this spellchecking facility seems not to be used outside vim. > > So we would need to have a better understanding of what is expected. > Will vim files be built from a central package (like libreoffice-dicts > does for most hunspell dicts) or there will be separate source > packages for each dict, probably with different maintainers? If the > second, a vim spellckeck policy and helper scripts are useful. Note, > however, that I do not use vim, so some help will be needed, where is > this feature documented? There is documentation about it in: /usr/share/vim/vim82/doc/spell.txt Or online at: https://vimhelp.org/spell.txt.html I think we should at least ship the files in Debian somehow, the user shouldn't need to download it. Kurt
Bug#980302: dictionaries-common-dev: vim dictionary support
On Mon, Jan 18, 2021 at 01:22:48PM +0100, Agustin Martin wrote: > El dom, 17 ene 2021 a las 16:06, Kurt Roeckx () escribió: > > > > Package: dictionaries-common-dev > > > > Hi, > > > > Vim has support for spellchecking using it's own spell check > > files. It can be generated based on hunspell .aff/.dic files, or > > based on a wordlist. Files currently need to be placed in > > /usr/share/vim/vim82/spell/ > > > > It would be good if we had a policy and helper scripts to install > > the files so vim can use them, and how to name the packages. > > Hi, Kurt, > > This was mentioned a while ago in #490987. It was closed because at > that time building vim spell files creation seemed to be very memory > intensive and using libhunspell via a redhat patch was under > consideration. I have no idea about current status of spellchecking in > vim and if those concerns were addressed. Converting it from .aff and .dic to .spl and .sug takes 2.3 seconds here and 99 MB of RAM. Note that I need to patch the .aff files to actually make it work properly because vim doesn't implement all the same things hunspell does. I was looking at the libhunspell patch upstream, which seems to be going nowhere, the pull requests was closed because it wasn't complete and nobody seems to want to fix it. > On the other hand most hunspell dicts come from libreoffice-dicts and > do not provide a dict-common info file. In my TODO list there is a > point to play with libreoffice-dicts build process to automatically > create a minimal info file, but it has been there for years due to > lack of both time and python skills at that time. I have no idea what those files are used for, so I can't even test that they are correct or not. I assume that it might have something to do with emacs, but I'm a vim user, not an emacs user. Kurt
Bug#980302: dictionaries-common-dev: vim dictionary support
Package: dictionaries-common-dev Hi, Vim has support for spellchecking using it's own spell check files. It can be generated based on hunspell .aff/.dic files, or based on a wordlist. Files currently need to be placed in /usr/share/vim/vim82/spell/ It would be good if we had a policy and helper scripts to install the files so vim can use them, and how to name the packages. Kurt
Bug#959469: buster-pu: package openssl/1.1.1g-1
On Thu, Jan 14, 2021 at 09:13:49PM +0100, Sebastian Andrzej Siewior wrote: > On 2021-01-14 19:03:37 [+0100], Kurt Roeckx wrote: > > > Do you have pointers to upstream issues? > > > > There are a whole bunch of other issues and pull requests related to > > this. I hope this is the end of the regressions in the X509 code. > > Okay. Please ping once this gets sorted out and I will prepease > unstalbe/stable uploads. The m2crypto issue got resolved in unstable > \o/. So I went over the open issues and pull requests, and currently don't see a reason not to upload it to unstable with those 2 patches. I don't know about any other regressions in 1.1.1. Kurt
Bug#959469: buster-pu: package openssl/1.1.1g-1
On Thu, Jan 14, 2021 at 05:43:00PM +, Adam D. Barratt wrote: > Hi, > > On Fri, 2021-01-08 at 23:59 +0100, Kurt Roeckx wrote: > > On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior > > wrote: > [...] > > > The i release in unstable managed to migrate to testing. It was > > > blocked due to ci by m2crypto and swi-prolog. The swi-prolog issue > > > got fixed in unstable (the testuite was updated) and is not an > > > issue in stable (the package builds, the testsuite gets ignored). > > > The m2crypto issue is a different story and is still open in BTS > > > (#977655). I *think* someone added an override or the ci-system was > > > kind to Kurt/me and looked the other way :) > > > The m2crypto package in stable and bpo will FTBFS with the updated > > > openssl package. > > > > > > I'm not aware of other issues. > > > > I think there are at least 2 upstream issues since the 1.1.1i > > release we want to fix first. As far as I know, they haven't been > > fixed upstream yet. > > Just to confirm, these are issues that you'd want to have fixed before > adding 1.1.1i to stable, presumably requiring further uploads to > unstable first? Yes. > Do you have pointers to upstream issues? They both got merged today: commit 76ed0c0ad119569f6e6f6c96b27b76d3b110413b (origin/OpenSSL_1_1_1-stable) Author: Dr. David von Oheimb Date: Mon Dec 28 11:25:59 2020 +0100 x509_vfy.c: Fix a regression in find_isser() ...in case the candidate issuer cert is identical to the target cert. Fixes #13739 Reviewed-by: Tomas Mraz (Merged from https://github.com/openssl/openssl/pull/13749) commit fb1e2411042f0367c2560e4ec5e4b1189ca9cd45 Author: Dr. David von Oheimb Date: Wed Dec 30 09:57:49 2020 +0100 X509_cmp(): Fix comparison in case x509v3_cache_extensions() failed to due to invalid cert This is the backport of #13755 to v1.1.1. Fixes #13698 Reviewed-by: Tomas Mraz (Merged from https://github.com/openssl/openssl/pull/13756) There are a whole bunch of other issues and pull requests related to this. I hope this is the end of the regressions in the X509 code. Kurt
Bug#959469: buster-pu: package openssl/1.1.1g-1
On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior wrote: > On 2020-11-24 20:18:15 [+], Adam D. Barratt wrote: > > > At some point, could we please have a combined / single diff between > > the current 1.1.1d-0+deb10u3 and the proposed 1.1.1h-0+deb10u1 (I > > assume)? > > Please find attached the diff between 1.1.1d-0+deb10u4 and the proposed > 1.1.1i-0+deb10u1. > > The i release in unstable managed to migrate to testing. It was blocked > due to ci by m2crypto and swi-prolog. The swi-prolog issue got fixed in > unstable (the testuite was updated) and is not an issue in stable (the > package builds, the testsuite gets ignored). > The m2crypto issue is a different story and is still open in BTS > (#977655). I *think* someone added an override or the ci-system was kind > to Kurt/me and looked the other way :) > The m2crypto package in stable and bpo will FTBFS with the updated > openssl package. > > I'm not aware of other issues. I think there are at least 2 upstream issues since the 1.1.1i release we want to fix first. As far as I know, they haven't been fixed upstream yet. Kurt
Bug#979558: aspell-nl: The word "X" is invalid. The char 'Y' may not appear at the beginning of a word. Skipping word.
On Fri, Jan 08, 2021 at 11:15:54AM +0100, Diederik de Haas wrote: > Package: aspell-nl > Version: 1:2.20.19-1 > Severity: normal > > Warning: The word "&" is invalid. The character '&' (U+26) may not appear at > the beginning of a word. Skipping word. [...] > The 'aptitude safe-upgrade' finish successfully afaict, but I'm guessing > this wasn't intended behavior. It was expected behaviour. Everything should work. I just need to spend some more time to remove unsupported words. Kurt
Bug#898746: myspell-tools: Convert into dummy transitional package depending on hunspell-tools
On Tue, May 15, 2018 at 06:23:24PM +0200, Rene Engelhard wrote: > # grep-dctrl -FBuild-Depends myspell-tools -sPackage > # /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources > Package: ifrench-gut > Package: ispell-czech > Package: norwegian > Package: rus-ispell That still seems to be the case today. I suggest you file bugs against those packages to move a away form those tools, and then at some point just remove the myspell source package. Kurt
Bug#977657: closed by Debian FTP Masters (reply to Lev Lamberov ) (Bug#977657: fixed in swi-prolog 8.2.3+dfsg-2)
reopen 977657 thanks Hi, The CI test still fails with 1.1.1i: Testing package ssl:ssl Script test_ssl.pl failed: Unknown message: exit(1) % PL-Unit: ssl_options ... done % PL-Unit: ssl_server . done % PL-Unit: ssl_keys . done % PL-Unit: ssl_certificates . ERROR: /usr/lib/swi-prolog/test/packages/ssl/test_ssl.pl:629: test Certificate is not issued by trusted CA: received error: plunit_ssl_certificates:'unit body'/2: Unknown procedure: plunit_ssl_certificates:(+)/1 .. done % PL-Unit: crypto_data_encrypt . done % 1 test failed % 45 tests passed ERROR: -g test_ssl: false Kurt
Bug#971760: systemd: Error messages about XDG autostart after logging in as root
On Mon, Dec 21, 2020 at 05:58:55PM +0100, Michael Biebl wrote: > > Doing so now. > If you feel comfortable sharing the above information via private > email, you can send it to me directly. I'll promise to not disclose any > information without your prior consent. I can't reproduce it anymore currently. I now have systemd 247.1-3+deb11u1 installed. Kurt
Bug#977657: swi-prolog: FTBFS with OpenSSL 1.1.1i
Package: swi-prolog Version: 8.2.3+dfsg-1 Severity: serious Forwarded: https://github.com/SWI-Prolog/packages-ssl/issues/159 Tag: patch Hi, Swi-prolog is failing to build using OpenSSL 1.1.1i. I've attached a patch that fixes it. Kurt --- packages/ssl/test_ssl.pl.orig 2020-12-18 11:04:37.481046178 +0100 +++ packages/ssl/test_ssl.pl 2020-12-18 11:06:09.479169064 +0100 @@ -629,11 +629,14 @@ test('Certificate is not issued by trusted CA'):- do_verification_test(14, try_ssl_client('www.example.com', test_verify_hook), VerificationResults, Status), ( VerificationResults:Status == [unknown_issuer]:true -> -% OpenSSL 1.0.2 and above +% OpenSSL 1.0.2 - 1.1.1h true ; VerificationResults:Status == [unknown_issuer, not_trusted]:true -> % OpenSSL 1.0.1 and below true +; VerificationResults:Status == [unknown_issuer, verified]:true -> +% OpenSSL 1.1.1i and above +true ). test('Certificate is issued by trusted CA but has been altered so signature is wrong', VerificationResults:Status == [bad_signature, verified]:true):-
Bug#977655: m2crypto: FTBFS with OpenSSL 1.1.1i
Package: m2crypto Version: 0.36.0-1 Severity: serious Forwarded: https://gitlab.com/m2crypto/m2crypto/-/issues/289 Hi, m2crypto is failing to build since the 1.1.1i version of OpenSSL, see the upstream bug report for more details. Kurt
Bug#976465: [Pkg-openssl-devel] Bug#976465: Restore rejection of expired trusted (root) certificate
On Sat, Dec 05, 2020 at 02:13:32PM +0100, Matthias Klose wrote: > Package: src:openssl > Version: 1.1.1h-1 > Severity: serious > Tags: sid bullseye patch > > Please backport https://github.com/openssl/openssl/pull/13585 > > Without this patch, this causes python-asyncssh's tests to fail (and failing > the > build). So that's been merged to the 1.1.1 branch. There is a release on Tuesday that should include it. Kurt