Bug#1067087: GCC frame pointers

2024-03-18 Thread Kurt Roeckx
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

2024-03-04 Thread Kurt Roeckx
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

2023-10-03 Thread Kurt Roeckx
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

2023-04-09 Thread Kurt Roeckx
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

2023-03-03 Thread Kurt Roeckx
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'

2023-03-03 Thread Kurt Roeckx
Hi,

Are you waiting for something before uploading this fix?


Kurt



Bug#1023284: libevent: FTBFS with glibc 2.36

2023-03-03 Thread Kurt Roeckx
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

2022-12-14 Thread Kurt Roeckx
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

2022-12-04 Thread Kurt Roeckx
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

2022-12-04 Thread Kurt Roeckx
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

2022-11-22 Thread Kurt Roeckx
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

2022-11-22 Thread Kurt Roeckx
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)

2022-11-22 Thread Kurt Roeckx
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

2022-11-22 Thread Kurt Roeckx
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

2022-11-22 Thread Kurt Roeckx
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

2022-10-18 Thread Kurt Roeckx
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:

2022-09-25 Thread Kurt Roeckx
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

2022-09-18 Thread Kurt Roeckx
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

2022-09-13 Thread Kurt Roeckx
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

2022-09-13 Thread Kurt Roeckx
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

2022-08-02 Thread Kurt Roeckx
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)

2022-07-19 Thread Kurt Roeckx
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)

2022-07-18 Thread Kurt Roeckx
This is probably https://bugzilla.kernel.org/show_bug.cgi?id=216140


Kurt



Bug#1015240: Acknowledgement (linux: rejecting DMA map of vmalloc memory)

2022-07-18 Thread Kurt Roeckx
I tried older kernels, 5.17.3-1 didn't show it.



Bug#1015240: linux: rejecting DMA map of vmalloc memory

2022-07-18 Thread Kurt Roeckx
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

2022-06-05 Thread Kurt Roeckx
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

2022-05-27 Thread Kurt Roeckx
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

2022-05-18 Thread Kurt Roeckx
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

2022-05-18 Thread Kurt Roeckx
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

2022-05-15 Thread Kurt Roeckx
It looks like it's fixed here: https://github.com/openssl/openssl/pull/18247



Bug#996276: foxeye: FTBFS with OpenSSL 3.0

2022-05-11 Thread Kurt Roeckx
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

2022-05-11 Thread Kurt Roeckx
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

2022-04-02 Thread Kurt Roeckx
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

2022-03-22 Thread Kurt Roeckx
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

2022-03-22 Thread Kurt Roeckx
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

2022-03-22 Thread Kurt Roeckx
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

2022-03-22 Thread Kurt Roeckx
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

2022-03-20 Thread Kurt Roeckx
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

2022-03-20 Thread Kurt Roeckx
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

2022-03-18 Thread Kurt Roeckx
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

2021-12-24 Thread Kurt Roeckx
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)

2021-11-13 Thread Kurt Roeckx
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

2021-11-13 Thread Kurt Roeckx
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

2021-10-18 Thread Kurt Roeckx
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

2021-10-17 Thread Kurt Roeckx
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

2021-10-13 Thread Kurt Roeckx
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

2021-10-13 Thread Kurt Roeckx
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

2021-10-13 Thread Kurt Roeckx
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

2021-10-13 Thread Kurt Roeckx
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

2021-10-13 Thread Kurt Roeckx
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

2021-10-13 Thread Kurt Roeckx
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

2021-10-13 Thread Kurt Roeckx
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

2021-10-12 Thread Kurt Roeckx
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

2021-10-12 Thread Kurt Roeckx
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

2021-10-12 Thread Kurt Roeckx
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

2021-10-12 Thread Kurt Roeckx
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

2021-10-12 Thread Kurt Roeckx
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

2021-10-12 Thread Kurt Roeckx
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

2021-10-12 Thread Kurt Roeckx
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

2021-10-12 Thread Kurt Roeckx
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

2021-10-12 Thread Kurt Roeckx
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

2021-10-03 Thread Kurt Roeckx
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

2021-10-03 Thread Kurt Roeckx
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

2021-10-03 Thread Kurt Roeckx
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'

2021-10-03 Thread Kurt Roeckx
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

2021-10-03 Thread Kurt Roeckx
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

2021-10-03 Thread Kurt Roeckx
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

2021-10-03 Thread Kurt Roeckx
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

2021-10-03 Thread Kurt Roeckx
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

2021-10-03 Thread Kurt Roeckx
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

2021-10-03 Thread Kurt Roeckx
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

2021-10-03 Thread Kurt Roeckx
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

2021-10-03 Thread Kurt Roeckx
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

2021-10-03 Thread Kurt Roeckx
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

2021-06-27 Thread Kurt Roeckx
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

2021-06-27 Thread Kurt Roeckx
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

2021-06-27 Thread Kurt Roeckx
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

2021-06-25 Thread Kurt Roeckx
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:..

2021-06-23 Thread Kurt Roeckx
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

2021-06-23 Thread Kurt Roeckx
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

2021-03-13 Thread Kurt Roeckx
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

2021-02-28 Thread Kurt Roeckx
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

2021-02-28 Thread Kurt Roeckx
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

2021-02-18 Thread Kurt Roeckx
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

2021-02-12 Thread Kurt Roeckx
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

2021-01-27 Thread Kurt Roeckx
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

2021-01-19 Thread Kurt Roeckx
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

2021-01-18 Thread Kurt Roeckx
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

2021-01-18 Thread Kurt Roeckx
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

2021-01-17 Thread Kurt Roeckx
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

2021-01-16 Thread Kurt Roeckx
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

2021-01-14 Thread Kurt Roeckx
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

2021-01-08 Thread Kurt Roeckx
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.

2021-01-08 Thread Kurt Roeckx
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

2021-01-01 Thread Kurt Roeckx
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)

2020-12-27 Thread Kurt Roeckx
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

2020-12-24 Thread Kurt Roeckx
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

2020-12-18 Thread Kurt Roeckx
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

2020-12-18 Thread Kurt Roeckx
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

2020-12-05 Thread Kurt Roeckx
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



  1   2   3   4   5   6   7   8   9   10   >