Re: Debian 12.5: pigz 2.6-1 fails with error message (Upstream issue 111)
On Tue, Apr 02, 2024 at 06:34:43PM -0400, Jeffrey Walton wrote: > On Tue, Apr 2, 2024 at 6:24 PM Chung Jonathan wrote: > > > > Dear Franco Martelli, dear Thomas Schmitt, > > > > Sorry for the potential duplication. This mail should now also go to the > > list. > > > > I believe I found the problem which was on my side. I do have libz.so.1.3, > > since I manually compiled grpc on my machine and this also uses a newer > > version of zlib appearently. So this is not a Debian problem but rather > > specific to my setup. A clean install in a VM indeed works as expected. > > Do you still think a bug report is worth it? > > Your problem is one that plagues Linux. You compile and link against > one version of a library, and then you runtime link against another > version. This should have been fixed for users a long time ago, but > the folks responsible leave users to suffer it. I consider it a > security bug since essentially random libraries are being loaded at > runtime. > > To fix the problem yourself, add an RPATH to your LDFLAGS when > building your program: > > -Wl,-rpath=/path/to/expected/libz -Wl,--enable-new-dtags > > The loader will encounter the RPATH when loading your executable, and > load the correct library for your program. I've run into a variant of this issue myself. I had compiled an upstream version of Tcl, which builds a shared library named libtcl8.6.so in the lib/ subdirectory of the --prefix used for ./configure, where the default value of --prefix is /usr/local. This places the shared library in /usr/local/lib which happens to be in the default set of paths used by ldconfig and ld.so. Which in turn means that the locally built library gets used when running Debian's packaged version of Tcl, taking priority over the version installed in /usr/lib/x86_64-linux-gnu/ or whatver arch-specific directory is used. In my case, the solution was to build my local version of Tcl with a different --prefix. Then there's nothing dropped into /usr/local/lib and there's no conflict with the system's packages. Of course, this is a particularly subtle problem that most users are not going to be aware of. It's specific to packages that build part of themselves as a shared library, which immediately makes most programs immune to it. But when it *does* affect you, it can be tricky to figure out what's happening. It sounds like the OP's pigz issue was of a similar nature. If this is the case, then filing a Debian bug report isn't going to be helpful, unless it's done as a sort of documentation for anyone else who runs into the same problem in the future.
Re: Debian 12.5: pigz 2.6-1 fails with error message (Upstream issue 111)
On Tue, Apr 2, 2024 at 6:24 PM Chung Jonathan wrote: > > Dear Franco Martelli, dear Thomas Schmitt, > > Sorry for the potential duplication. This mail should now also go to the list. > > I believe I found the problem which was on my side. I do have libz.so.1.3, > since I manually compiled grpc on my machine and this also uses a newer > version of zlib appearently. So this is not a Debian problem but rather > specific to my setup. A clean install in a VM indeed works as expected. > Do you still think a bug report is worth it? Your problem is one that plagues Linux. You compile and link against one version of a library, and then you runtime link against another version. This should have been fixed for users a long time ago, but the folks responsible leave users to suffer it. I consider it a security bug since essentially random libraries are being loaded at runtime. To fix the problem yourself, add an RPATH to your LDFLAGS when building your program: -Wl,-rpath=/path/to/expected/libz -Wl,--enable-new-dtags The loader will encounter the RPATH when loading your executable, and load the correct library for your program. Jeff
Re: Debian 12.5: pigz 2.6-1 fails with error message (Upstream issue 111)
Dear Franco Martelli, dear Thomas Schmitt, Sorry for the potential duplication. This mail should now also go to the list. I believe I found the problem which was on my side. I do have libz.so.1.3, since I manually compiled grpc on my machine and this also uses a newer version of zlib appearently. So this is not a Debian problem but rather specific to my setup. A clean install in a VM indeed works as expected. Do you still think a bug report is worth it? Thanks for your prompt responses, Jonathan Chung Am 02.04.2024 um 21:37 schrieb Chung Jonathan : Dear Franco Martelli, dear Thomas Schmitt, Yes, /etc/debian_version reports 12.5. However, as I have the docker sources as external repository those might have introduced an update to zlib. I will try to narrow it down and then open a subsequent bug report - possibly on a clean VM too. The error first occurred as I installed a docker image. However, pigz --version also gave this error. Thank you for pointing me to the correct directions, Jonathan Chung Am 02.04.2024 um 21:07 schrieb Franco Martelli : On 02/04/24 at 10:27, Jonathan Chung wrote: Dear sir or madam, I'm new with Debian bug reporting and thus need some help with that. pigz 2.6-1 on Debian 12.5 fails to execute due to a fixed bug on upstream https://github.com/madler/pigz/issues/111 Installing the version from sid resolves the issue which is clearly not optimal. I think the fix should be backported. Can someone help me to file a bug report? To file a bug report use "reportbug pigz" and answer the questions… but I use regularly "pigz" in my backup scripts and I didn't notice nothing wrong ?_? My installed version is: ~$ dpkg -l | grep pigz ii pigz 2.6-1 amd64Parallel Implementation of GZip I just tested it and I've nothing to report: ~$ tar tf frankbck2.tgz --use-compress-program=pigz >/dev/null ~$ echo $? 0 Are you sure you are using Debian 12.5 ? Kind regards. -- Franco Martelli
Re: Debian 12.5: pigz 2.6-1 fails with error message (Upstream issue 111)
Dear Thomas Schmitt, Yes, I think the local fix is the way to go. Probably even getting rid of the source of this, my manual GRPC install and replacing it with libgrpc++-dev. But that’s outside of this issue. Yours, Jonathan Chung Am 02.04.2024 um 23:34 schrieb Thomas Schmitt : Hi, (You forgot to Cc: debian-user@lists.debian.org. Consider to send your mail to the list address, too. I too would then resend my following reply to the list.) Chung Jonathan wrote: I do have libz.so.1.3, since I manually compiled grpc on my machine and this also uses a newer version of zlib appearently. [...] Do you still think a bug report is worth it? Rather not. The original combination of pigz and zlib works in Debian 12. So it's not a bug in that context. The fact that it hampers upgrade to younger zlib is already addressed by the version of pigz in "testing". So in the context of Debian 13 it will be no bug either. This leaves only the possibility to really ask for a backport for the new feature that one can upgrade zlib before Debian offers it. But the desired use case is near to the topic of "Frankendebian": https://wiki.debian.org/DontBreakDebian If in urgent need for a fix, i expect that you would get more lucky by patching the "stable" pigz package for your local use according to https://wiki.debian.org/BuildingTutorial (patching is done in https://wiki.debian.org/BuildingTutorial#Edit_the_source_code and as usual in Debian, there are more ways than this one to do it ...) Have a nice day :) Thomas
Re: Debian ISOs on USB stick, was: SOLVED
On 4/2/24 08:56, Thomas Schmitt wrote: Hi, David Christensen wrote: the Debian installer modifies the contents of the USB flash drive when it runs. Do you mean inside the range of the ISO image or outside by creating a new partition ? songbird wrote: if it is an iso image copied to the USB stick it should not be modified if you haven't somehow told the installer to install the system to that USB stick (somehow). There are other parties which feel entitled to operate on the EFI System Partition of a USB stick. In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056998 we found that Lenovo Thinkpad firmware created directories for storing an empty file named "/efi/Lenovo/BIOS/SelfHealing.fd" and that MS-Windows created a 12-byte file named "/System Volume Information/WPSettings.dat" when it had contact with the USB stick. i guess if you wanted to be really sure you could mount it read-only. I think it's the installer which mounts the ISO 9660 filesystem. Whatever, the Linux kernel has no regular means to alter an ISO 9660 filesystem. Neither kernel nor Debain installer will be so daring to operate with byte level commands on that filesystem. But the FAT filesystem in file /boot/grub/efi.img of the ISO 9660 filesystem in debian-12.*-amd64-netinst.iso is advertised by the partition table of the image and thus attracts vermin. Have a nice day :) Thomas Please see my reply to songbird. It's a relatively simple experiment to confirm that a USB flash drive with d-i changes after the first boot. Same for finding which bytes change. The challenge is figuring out what performed the change(s) and why. I assumed it was d-i, but no longer own 64-bit BIOS-only computers to confirm. David
Re: HDD long-term data storage with ensured integrity
On 4/2/24 06:55, Stefan Monnier wrote: The most obvious alternative to ZFS on Debian would be Btrfs. Does anyone have any comments or suggestions regarding Btrfs and data corruption bugs, concurrency, CMM level, PSP, etc.? If you're worried about such things, I'd think "the most obvious alternative" is LVM+ext4. Both Btrfs and ZFS share the same underlying problem: more features => more code => more bugs. Stefan AIUI neither LVM nor ext4 have data and metadata checksum and correction features. But, it should be possible to achieve such by including dm-integrity (for checksumming) and some form of RAID (for correction) in the storage stack. I need to explore that possibility further. David
Re: SOLVED
On 4/2/24 07:55, songbird wrote: David Christensen wrote: I thought about suggesting that in my last post, but did not want to complicate things. A key advantage of using a CD-R disc is that you can verify the disc contents and/or checksum against the ISO and/or checksum now and in the future. This is not true for a USB flash drive, because the Debian installer modifies the contents of the USB flash drive when it runs. if it is an iso image copied to the USB stick it should not be modified if you haven't somehow told the installer to install the system to that USB stick (somehow). i guess if you wanted to be really sure you could mount it read-only. songbird I used to think that the d-i ran in memory when booted from read-write media, but discovered otherwise several years ago. I previously downloaded debian-11.3.0-amd64-netinst.iso and SHA512SUMS: 2022-04-29 22:16:19 dpchrist@tinkywinky ~/samba/dpchrist/iso/debian/11.3.0 $ ls -l total 380414 -rwxr-xr-x 1 dpchrist dpchrist 494 Apr 28 21:04 SHA512SUMS -rwxr-xr-x 1 dpchrist dpchrist 833 Apr 28 21:04 SHA512SUMS.sign -rwxr-xr-x 1 dpchrist dpchrist 396361728 Apr 28 21:05 debian-11.3.0-amd64-netinst.iso I verified the checksum of the ISO file: 2022-04-29 22:17:17 dpchrist@tinkywinky ~/samba/dpchrist/iso/debian/11.3.0 $ grep debian-11.3.0-amd64-netinst.iso SHA512SUMS | sha512sum -c debian-11.3.0-amd64-netinst.iso: OK I burned the ISO to a zeroed USB flash drive: 2022-04-29 22:39:25 root@tinkywinky ~/hardware/adata/usb-flash-drive/REDACTED # time dd if=/home/dpchrist/samba/dpchrist/iso/debian/11.3.0/debian-11.3.0-amd64-netinst.iso of=/dev/disk/by-id/usb-ADATA_USB_Flash_Drive_1392303332110024-0\:0 bs=1M iflag=fullblock oflag=sync,noatime status=progress 394264576 bytes (394 MB, 376 MiB) copied, 76.1204 s, 5.2 MB/s 378+0 records in 378+0 records out 396361728 bytes (396 MB, 378 MiB) copied, 76.5701 s, 5.2 MB/s real1m16.582s user0m0.012s sys 0m0.584s I computed the checksum of the relevant blocks of the USB flash drive: 2022-04-29 22:43:56 root@tinkywinky ~/hardware/adata/usb-flash-drive/REDACTED # time dd if=/dev/disk/by-id/usb-ADATA_USB_Flash_Drive_REDACTED-0\:0 bs=1M count=378 iflag=fullblock | sha512sum 378+0 records in 378+0 records out 396361728 bytes (396 MB, 378 MiB) copied, 25.0641 s, 15.8 MB/s 2810f894afab9ac2631ddd097599761c1481b85e629d6a3197fe1488713af048d37241eb85def681ba86e62b406dd9b891ee1ae7915416335b6bb000d57c1e53 - real0m25.068s user0m3.468s sys 0m0.720s The USB flash drive checksum matched the value stored in SHA512SUMS: 2022-04-29 22:44:58 root@tinkywinky ~/hardware/adata/usb-flash-drive/REDACTED # grep 2810f894afab9ac2631ddd097599761c1481b85e629d6a3197fe1488713af048d37241eb85def681ba86e62b406dd9b891ee1ae7915416335b6bb000d57c1e53 /home/dpchrist/samba/dpchrist/iso/debian/11.3.0/SHA512SUMS 2810f894afab9ac2631ddd097599761c1481b85e629d6a3197fe1488713af048d37241eb85def681ba86e62b406dd9b891ee1ae7915416335b6bb000d57c1e53 debian-11.3.0-amd64-netinst.iso I have since used the USB flash drive to install Debian onto one or more computers. If I compute the checksum of the relevant blocks of the USB flash drive today: 2024-04-02 14:32:43 root@laalaa ~ # time dd if=/dev/disk/by-id/usb-ADATA_USB_Flash_Drive_REDACTED-0\:0 bs=1M count=378 iflag=fullblock | sha512sum 378+0 records in 378+0 records out 6cbb7e54fccdf550cbb5535d7dd9357513b36b767f0aaa550b1d58b37ef827c881036dcf47b3c377d196c4e77d14c786a6dd975aa558a11a81cf9ae107062abc - 396361728 bytes (396 MB, 378 MiB) copied, 27.7592 s, 14.3 MB/s real0m27.766s user0m4.134s sys 0m1.380s The checksum has changed because d-i modified the USB flash drive. I previously confirmed this behavior years ago after booting a d-i USB flash drive only once. You must use read-only media (e.g. CD-R) if you want to be able to verify d-i after use. David
Re: KVM, como faz o acesso remoto?
Acho que essa abordagem é mais fácil: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-generic_commands-connect Em ter., 2 de abr. de 2024 às 17:26, Atenágoras Silva escreveu: > Se eu entendi, você quer acessar o console da máquina virtual pelo > terminal? > > Tenta antes com o virt-viewer. Ele vai abrir o console dentro de uma > janela, aí você redimensiona ela. > Dá para configurar uma porta serial e acessar a VM através dela com o > virsh: https://askubuntu.com/questions/576437/virsh-ssh-into-a-guest-vm > > Em ter., 2 de abr. de 2024 às 17:13, hamacker > escreveu: > >> Olá a todos, >> >> Instalei o kvm e o virt-manager. >> No desktop, eu tenho problemas porque ao acessar, a tela fica escalonada >> no fullscreen. Daí pensei que similar ao xen, o kvm quer que você acesse-o >> via terminal remoto, talvez usando o remmina ou algo diferente. Então >> pergunto a vocês, como eu acesso remotamente a VM, tem um protocolo >> especifico? VNC, RDP ou qual? >> >> Eu posso acessar localmente também, mas nesse caso teria de ver como >> configuro a pseudo-tela da VM que é travada em 1280px. >> >
Re: KVM, como faz o acesso remoto?
Se eu entendi, você quer acessar o console da máquina virtual pelo terminal? Tenta antes com o virt-viewer. Ele vai abrir o console dentro de uma janela, aí você redimensiona ela. Dá para configurar uma porta serial e acessar a VM através dela com o virsh: https://askubuntu.com/questions/576437/virsh-ssh-into-a-guest-vm Em ter., 2 de abr. de 2024 às 17:13, hamacker escreveu: > Olá a todos, > > Instalei o kvm e o virt-manager. > No desktop, eu tenho problemas porque ao acessar, a tela fica escalonada > no fullscreen. Daí pensei que similar ao xen, o kvm quer que você acesse-o > via terminal remoto, talvez usando o remmina ou algo diferente. Então > pergunto a vocês, como eu acesso remotamente a VM, tem um protocolo > especifico? VNC, RDP ou qual? > > Eu posso acessar localmente também, mas nesse caso teria de ver como > configuro a pseudo-tela da VM que é travada em 1280px. >
KVM, como faz o acesso remoto?
Olá a todos, Instalei o kvm e o virt-manager. No desktop, eu tenho problemas porque ao acessar, a tela fica escalonada no fullscreen. Daí pensei que similar ao xen, o kvm quer que você acesse-o via terminal remoto, talvez usando o remmina ou algo diferente. Então pergunto a vocês, como eu acesso remotamente a VM, tem um protocolo especifico? VNC, RDP ou qual? Eu posso acessar localmente também, mas nesse caso teria de ver como configuro a pseudo-tela da VM que é travada em 1280px.
Re: Debian 12.5: pigz 2.6-1 fails with error message (Upstream issue 111)
Dear Franco Martelli, dear Thomas Schmitt, Yes, /etc/debian_version reports 12.5. However, as I have the docker sources as external repository those might have introduced an update to zlib. I will try to narrow it down and then open a subsequent bug report - possibly on a clean VM too. The error first occurred as I installed a docker image. However, pigz --version also gave this error. Thank you for pointing me to the correct directions, Jonathan Chung > Am 02.04.2024 um 21:07 schrieb Franco Martelli : > On 02/04/24 at 10:27, Jonathan Chung wrote: >> Dear sir or madam, >> I'm new with Debian bug reporting and thus need some help with that. >> pigz 2.6-1 on Debian 12.5 fails to execute due to a fixed bug on >> upstream https://github.com/madler/pigz/issues/111 >> Installing the version from sid resolves the issue which is clearly not >> optimal. I think the fix should be backported. >> Can someone help me to file a bug report? > > To file a bug report use "reportbug pigz" and answer the questions… but I use > regularly "pigz" in my backup scripts and I didn't notice nothing wrong ?_? > My installed version is: > > ~$ dpkg -l | grep pigz > ii pigz 2.6-1 > amd64Parallel Implementation of GZip > > I just tested it and I've nothing to report: > > ~$ tar tf frankbck2.tgz --use-compress-program=pigz >/dev/null > ~$ echo $? > 0 > > Are you sure you are using Debian 12.5 ? > > Kind regards. > > -- > Franco Martelli
Re: Debian 12.5: pigz 2.6-1 fails with error message (Upstream issue 111)
On 02/04/24 at 10:27, Jonathan Chung wrote: Dear sir or madam, I'm new with Debian bug reporting and thus need some help with that. pigz 2.6-1 on Debian 12.5 fails to execute due to a fixed bug on upstream https://github.com/madler/pigz/issues/111 Installing the version from sid resolves the issue which is clearly not optimal. I think the fix should be backported. Can someone help me to file a bug report? To file a bug report use "reportbug pigz" and answer the questions… but I use regularly "pigz" in my backup scripts and I didn't notice nothing wrong ?_? My installed version is: ~$ dpkg -l | grep pigz ii pigz 2.6-1 amd64Parallel Implementation of GZip I just tested it and I've nothing to report: ~$ tar tf frankbck2.tgz --use-compress-program=pigz >/dev/null ~$ echo $? 0 Are you sure you are using Debian 12.5 ? Kind regards. -- Franco Martelli
Debian ISOs on USB stick, was: SOLVED
Hi, David Christensen wrote: > > the Debian installer modifies the contents of the USB flash drive when > > it runs. Do you mean inside the range of the ISO image or outside by creating a new partition ? songbird wrote: > if it is an iso image copied to the USB stick it should not > be modified if you haven't somehow told the installer to > install the system to that USB stick (somehow). There are other parties which feel entitled to operate on the EFI System Partition of a USB stick. In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056998 we found that Lenovo Thinkpad firmware created directories for storing an empty file named "/efi/Lenovo/BIOS/SelfHealing.fd" and that MS-Windows created a 12-byte file named "/System Volume Information/WPSettings.dat" when it had contact with the USB stick. > i guess if you wanted to be really sure you could mount it read-only. I think it's the installer which mounts the ISO 9660 filesystem. Whatever, the Linux kernel has no regular means to alter an ISO 9660 filesystem. Neither kernel nor Debain installer will be so daring to operate with byte level commands on that filesystem. But the FAT filesystem in file /boot/grub/efi.img of the ISO 9660 filesystem in debian-12.*-amd64-netinst.iso is advertised by the partition table of the image and thus attracts vermin. Have a nice day :) Thomas
Re: Debian 12.5: pigz 2.6-1 fails with error message (Upstream issue 111)
On Tue, 2 Apr 2024 10:27:33 +0200 Jonathan Chung wrote: > I'm new with Debian bug reporting and thus need some help with that. > pigz 2.6-1 on Debian 12.5 fails to execute due to a fixed bug on > upstream https://github.com/madler/pigz/issues/111 Are you sure this is a bug and not a problem with your system? I am also using pigz 2.6-1 on Debian 12.5, and I don't see it. charles@hawk:~$ pigz --version pigz 2.6 charles@hawk:~$ pre zlib pigz pigz2.6-1 amd64 zlib1g 1:1.2.13.dfsg-1 amd64 zlib1g-dev 1:1.2.13.dfsg-1 amd64 charles@hawk:~$ What version of zlib are you running? -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: SOLVED
David Christensen wrote: > I thought about suggesting that in my last post, but did not want to > complicate things. A key advantage of using a CD-R disc is that you can > verify the disc contents and/or checksum against the ISO and/or checksum > now and in the future. This is not true for a USB flash drive, because > the Debian installer modifies the contents of the USB flash drive when > it runs. if it is an iso image copied to the USB stick it should not be modified if you haven't somehow told the installer to install the system to that USB stick (somehow). i guess if you wanted to be really sure you could mount it read-only. songbird
Re: VMs Windows, qual virtualizador é melhor?
Sim, mas não existe mais Borland, já mudou de nome muitas vezes, mas estabilizou-se agora com o nome de Embarcadero. O Delphi não é barato, mas é muito rápido e prático. Eu estou portanto uma aplicação em Delphi c/ BDE+MSSQL (considerado bem legado) para Delphi c/ FirebirdSQL, essa não é a primeira vez, já faço isso ajudando equipes e softhouses. Eu aprendi com os colegas de outro forum a usar o Lazarus+fpc, então uma parte da estrutura já é em Lazarus com freepascal ao invés de Delphi, como vantagem obtive algo que pode rodar em gtk e que possivelmente pode ser exportado para web ou via 'ssh -x' . Como eu estou portando todos os módulos, os procedimentos de CRUD, calculos ou processos normais com banco de dados não ocorrem mais no lado cliente, é tudo no lado servidor ou por procedures no banco ou APIs. Meu intento, é que quando o processo estiver terminado possamos dar uma olhada novamente, escolher uma linguagem mais web para alguns desses módulos, e então paralelamente com a ponte antiga em funcionamento criar uma nova reutilizando o que já está feito. Parece que marquei bobeira na hora de começar, como já conheço php e python (pelo menos meus scripts para automação de servidores são muito bem feitos em python) poderia ter partido diretamente daqui, mas tinha programas aqui com alguns níveis de automação, ex a parte de corte e furação de chapas e que tenho quase certeza não daria certo no formato web. Valeu pela ajuda, eu vou dar uma olhada no kvm, mas o ReactOS eu vou passar, como tenho as licenças de windows, tá facil virtualizar neste sistema. Na realidade, minha única aplicação windows necessária mesmo é o Delphi. Lazarus+fpc já é opensource e o IBExpert(gerenciador do banco) é nível gold no WINE. [] ´s Em qui., 28 de mar. de 2024 às 15:57, Atenágoras Silva < athenago...@gmail.com> escreveu: > A Borland havia feito uma versão do Delphi para GNU/Linux... Ainda usam > Delphi? > Há muitas opções para você fazer isso, e algumas delas não depende de > virtualização. (embora o virt-manager torne a virtualização com o kvm > absurdamente fácil) > - É possível usar o ReactOS (Sistema Operacional compatível com o Windows, > mas com licença livre) no KVM ou no virtualbox > - Dá para usar Delphi no wine > - Existe uma IDE chamada Lazarus, que tem licença GPL, e que pode > substituir o Delphi, de modo que talvez seja possível você nem precisar de > virtualização nem de uma camada de compatibilidade com o Windows. > >> >>
Re: HDD long-term data storage with ensured integrity
> The most obvious alternative to ZFS on Debian would be Btrfs. Does anyone > have any comments or suggestions regarding Btrfs and data corruption bugs, > concurrency, CMM level, PSP, etc.? If you're worried about such things, I'd think "the most obvious alternative" is LVM+ext4. Both Btrfs and ZFS share the same underlying problem: more features => more code => more bugs. Stefan
Re: making Debian secure by default
On Tue, Apr 02, 2024 at 07:14:02AM -0500, Nate Bargmann wrote: > * On 2024 01 Apr 23:41 -0500, to...@tuxteam.de wrote: [...] > > This pattern has been seen in other contexts. Here [1] is a good review > > of "supply chain attacks" [...] > If you have Rust and Go in mind, Absolutely not. On the contrary. I don't even think that the language makes a difference in the risk of supply chain attack. > I am hugely skeptical of both, not > because of the languages themselves but because both, from what I see, > do not lend themselves easily to a set of known curated packages that > can be used for development. > > Noted Debian developer Ian Jackson wrote a blog post back on 21 March > detailing the extra steps necessary to *only* use Debian Rust packages: > > https://diziet.dreamwidth.org/18122.html No need to convince *me*. > > So yes, the pattern was known. It was, up to now, pretty unusual in > > this context. But the deeper "the stack" becomes... (so I think Nate > > had a point. That Andy read that as a "systemd insult" is IMHO > > infortunate, because it clogs a potentially useful discussion. But > > there you are). > > I think Andy was responding to Jacob Bachmeyer's use of "katamari" to > describe systemd/libsystemd which he uses again in: Yes, but he preferred to latch on "systemd", which is a pity, because the "katamari" part does have a point. > > The next level is using a package phantasized by your trusty "AI" [2] > > counsellor (and whose name was predicted by a malicious actor, because > > "AI" tends to phantasize names consistently). Note that this one was > > just (yet?) a proof of concept. > > I am guessing that the Jia Tan actor(s) are watching the response to > this event carefully. I doubt they have been deterred. We don't know much about Jia Tan (and we might never know). To me, one possible branch is the one most being talked about, that it was a state-level actor (group) planning things for two years from the start. More plausible to me would be a bona fide contributor who at some point was picked up and turned bad (by bribery or coercion). That's more the modus operandi of such actors [1]. To be honest, this one is also more unsettling to me. Cheers [1] Remember Bruce Schneier's observation that the NSA is better at breaking knuckles than at breaking code? -- t signature.asc Description: PGP signature
Re: SOLVED
On 4/1/24 11:35, DdB wrote: Am 01.04.2024 um 18:52 schrieb David Christensen: A bad USB flash drive would explain why you cannot boot the Debian installer. Please buy a good quality USB 3.0+ flash drive and try again. A friend of mine just let me use an external CD-Drive with the netboot image. I thought about suggesting that in my last post, but did not want to complicate things. A key advantage of using a CD-R disc is that you can verify the disc contents and/or checksum against the ISO and/or checksum now and in the future. This is not true for a USB flash drive, because the Debian installer modifies the contents of the USB flash drive when it runs. This is already the third time, i am restarting the installation process, due to my false assumptions about the intelligence within the installer. The last time, i was quite happy until i came to notice, that partitions were not aligned with physical sector boundaries, which i assumed would be elementary best practice. I chose manual partitioning and the Debian installer aligned the partitions to 2**20 byte boundaries: 2024-04-02 04:07:16 root@laalaa ~ # cat /etc/debian_version ; uname -a 11.9 Linux laalaa 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64 GNU/Linux 2024-04-02 04:08:18 root@laalaa ~ # fdisk -l /dev/sda Disk /dev/sda: 55.9 GiB, 60022480896 bytes, 117231408 sectors Disk model: INTEL SSDSC2CW06 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x544032f5 Device BootStart End Sectors Size Id Type /dev/sda1 *2048 1953791 1951744 953M 83 Linux /dev/sda21953792 3907583 1953792 954M 83 Linux /dev/sda33907584 29298687 25391104 12.1G 83 Linux /dev/sda4 29298688 117229567 87930880 41.9G 83 Linux But apart from losing some of my illusions the hard way, all is well. A big thank you to all the crowd offering suggestions and encouragement. so long, DdB I'm glad you were able to install Debian. :-) David
HDD long-term data storage with ensured integrity
On 3/31/24 02:18, DdB wrote: > i intend to create a huge backup server from some oldish hardware. > Hardware has been partly refurbished and offers 1 SSD + 8 HDD on a > 6core Intel with 64 GB RAM. ... the [Debian] installer ... aborts. On 4/1/24 11:35, DdB wrote: > A friend of mine just let me use an external CD-Drive with the netboot > image. ... all is well. Now you get to solve the same problem I have been stuck on since last November -- how to use those HDD's. ZFS has been my bulk storage solution of choice for the past ~4 years, but the recent data corruption bugs [1, 2] have me worried. From a technical perspective, it's about incorrect concurrent execution of GNU cp(1), Linux, and/or OpenZFS. From a management perspective, it's about Capability Maturity Model (CMM) [3] and Programming Systems Product (PSP) [4]. The most obvious alternative to ZFS on Debian would be Btrfs. Does anyone have any comments or suggestions regarding Btrfs and data corruption bugs, concurrency, CMM level, PSP, etc.? Does anyone have any comments or suggestions regarding how to use magnetic hard disk drives, commodity x86 computers, and Debian for long-term data storage with ensured integrity? David [1] https://github.com/openzfs/zfs/issues/15526 [2] https://github.com/openzfs/zfs/issues/15933 [3] https://en.wikipedia.org/wiki/Capability_maturity_model [4] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Re: making Debian secure by default
* On 2024 01 Apr 23:41 -0500, to...@tuxteam.de wrote: > On Mon, Apr 01, 2024 at 03:19:18PM -0500, Nate Bargmann wrote: > > * On 2024 01 Apr 14:01 -0500, Andy Smith wrote: > > [...] > > > Until now, who anticipated this? I'm sure there are security > > researchers who have and it's likely that I'm not well-read enough on > > this topic to have seen it discussed. How many people did it occur to > > that when A links to B and B links to C that C can create a > > vulnerability in A? That is what I understand happened here. > > This pattern has been seen in other contexts. Here [1] is a good review > of "supply chain attacks", which unsurprisingly happen most often in > decentrally managed package distributions which at the same time have > "production environments" where time-to-deploy is the main mover: npm, > PyPi and RubyGems. If you don't have the time to even consider what the > hundreds of packages you're ploughing into your app actually do, this > is no surprise. If you have Rust and Go in mind, I am hugely skeptical of both, not because of the languages themselves but because both, from what I see, do not lend themselves easily to a set of known curated packages that can be used for development. Noted Debian developer Ian Jackson wrote a blog post back on 21 March detailing the extra steps necessary to *only* use Debian Rust packages: https://diziet.dreamwidth.org/18122.html > So yes, the pattern was known. It was, up to now, pretty unusual in > this context. But the deeper "the stack" becomes... (so I think Nate > had a point. That Andy read that as a "systemd insult" is IMHO > infortunate, because it clogs a potentially useful discussion. But > there you are). I think Andy was responding to Jacob Bachmeyer's use of "katamari" to describe systemd/libsystemd which he uses again in: https://lists.gnu.org/archive/html/automake/2024-04/msg00015.html As far as I know, Jacob is not on this list so discussing his opinion is a bit unfair to him. > The next level is using a package phantasized by your trusty "AI" [2] > counsellor (and whose name was predicted by a malicious actor, because > "AI" tends to phantasize names consistently). Note that this one was > just (yet?) a proof of concept. I am guessing that the Jia Tan actor(s) are watching the response to this event carefully. I doubt they have been deterred. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Debian 12.5: pigz 2.6-1 fails with error message (Upstream issue 111)
Hi,
Jonathan Chung wrote:
> > pigz 2.6-1 on Debian 12.5 fails to execute due to a fixed bug on
> > upstream https://github.com/madler/pigz/issues/111
> > Installing the version from sid resolves the issue which is clearly not
> > optimal. I think the fix should be backported.
> > Can someone help me to file a bug report?
Michael Kjörling wrote:
> https://www.debian.org/Bugs/Reporting
This covers the question "how", but not "what".
So my two cents:
"Backported" is probably the wrong wish.
https://backports.debian.org/Contribute/
says:
"Backports are about additional features that are only offered in a
new version, not a replacement for getting fixes into stable - use
stable-updates for that."
That would probably mean to patch the existing pigz package in Debian 12
by the upstream remedy
"Make pigz compatible with two-component zlib version numbers. "
https://github.com/madler/pigz/commit/907ca0763be4547a9b0cce8c105721748814974
pigz.c:
@@ -1333,7 +1333,7 @@ local long zlib_vernum(void) {
}
ver++;
} while (left);
- return left < 2 ? num << (left << 2) : -1;
+ return left < 3 ? num << (left << 2) : -1;
}
// -- check value combination routines for parallel calculation --
The new state can already be seen in
https://sources.debian.org/src/pigz/2.8-1/pigz.c/#L1339
The old state is in
https://sources.debian.org/src/pigz/2.6-1/pigz.c/#L1317
But there the "// -- check ..." comment is missing in favor of a line
#ifndef NOTHREAD
So a patch proposal would need some minor hand work.
There remains the question, though, why you run into zlib-1.3 on a
Debian "stable" system where the zlib version is "1:1.2.13.dfsg-1":
https://tracker.debian.org/pkg/zlib
Have a nice day :)
Thomas
Re: How to file a Debian bug report? was: Debian 12.5: pigz 2.6-1 fails with error message (Upstream issue 111)
On 2 Apr 2024 10:27 +0200, from jch...@student.ethz.ch (Jonathan Chung): > Can someone help me to file a bug report? https://www.debian.org/Bugs/Reporting -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Debian 12.5: pigz 2.6-1 fails with error message (Upstream issue 111)
Dear sir or madam, I'm new with Debian bug reporting and thus need some help with that. pigz 2.6-1 on Debian 12.5 fails to execute due to a fixed bug on upstream https://github.com/madler/pigz/issues/111 Installing the version from sid resolves the issue which is clearly not optimal. I think the fix should be backported. Can someone help me to file a bug report?
