Bug#594940: Includes binary-only and obfuscated C code
On Sat, Nov 13, 2010 at 08:13:36PM +0100, Petr Salinger wrote: what would the effect on the kfreebsd-* kernel be of removing all of the files which were originally mentioned in Ben's mails in this bug report, and is that an option which has been considered by the porters? From my (non-DD) POV, the most problematic are network drivers sys/dev/txp/3c990img.h - binary is packaged in firmware-linux-nonfree as /lib/firmware/3com/typhoon.bin sys/dev/fxp/rcvbundl.h - binaries are packaged in firmware-linux-nonfree as /lib/firmware/e100/* For our port is very important to release. It would be better to release even without any of these drivers compared to not release at all ... fwiw, if the current firmware-loading mechanism could be extended to support using the firmware-* packages, the SRMs would be prepared to look at introducing the updated mechanism - and any necessary new firmware packages - as part of a Squeeze point release, if desired / required. Could be the plan: 1) drop all files from Ben's mail, repackage .orig.tgz, disable drivers 2) upload into sid and ask for propagation into squeeze 3) start extending firmware-loading mechanism 4a) upload into sid and ask for propagation into squeeze 4b) upload into stable-proposed-updates Whether 4a or 4b depends on our timing. I have to note, that this is my personal planing, not planing of whole porter group, but I expect they would agree. This looks like the way to go. I am sorry I don't have a lot of time to spend on that, but I can do the upload once everything is ready. About the firmware loader mechanism, another alternative is to package all removed (but distributable) firmwares that are currently already built as .ko in a separate source package, and build firmware-kfreebsd-nonfree from it. But I agree it would be even better to be able to load firmware in the same format as the linux kernel. Cheers, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594940: Includes binary-only and obfuscated C code
Sorry for the slight delay in responding to this. On Sun, 2010-11-07 at 14:16 +0100, Petr Salinger wrote: Now we have to somehow prune current source tree and disable some modules. Could we get squeeze-ignore tag for some of the affected files or is it necessary to prune all affected files ? Ben's original lists included some files which we don't appear to be able to distribute at all. If his analysis is correct then those files at least would need to be removed rather than ignored. The question is whether pruning following files suffices: Apologies if this question has already been asked (I couldn't find the previous occurrence if it has), but what would the effect on the kfreebsd-* kernel be of removing all of the files which were originally mentioned in Ben's mails in this bug report, and is that an option which has been considered by the porters? fwiw, if the current firmware-loading mechanism could be extended to support using the firmware-* packages, the SRMs would be prepared to look at introducing the updated mechanism - and any necessary new firmware packages - as part of a Squeeze point release, if desired / required. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594940: Includes binary-only and obfuscated C code
what would the effect on the kfreebsd-* kernel be of removing all of the files which were originally mentioned in Ben's mails in this bug report, and is that an option which has been considered by the porters? From my (non-DD) POV, the most problematic are network drivers sys/dev/txp/3c990img.h - binary is packaged in firmware-linux-nonfree as /lib/firmware/3com/typhoon.bin sys/dev/fxp/rcvbundl.h - binaries are packaged in firmware-linux-nonfree as /lib/firmware/e100/* For our port is very important to release. It would be better to release even without any of these drivers compared to not release at all ... fwiw, if the current firmware-loading mechanism could be extended to support using the firmware-* packages, the SRMs would be prepared to look at introducing the updated mechanism - and any necessary new firmware packages - as part of a Squeeze point release, if desired / required. Could be the plan: 1) drop all files from Ben's mail, repackage .orig.tgz, disable drivers 2) upload into sid and ask for propagation into squeeze 3) start extending firmware-loading mechanism 4a) upload into sid and ask for propagation into squeeze 4b) upload into stable-proposed-updates Whether 4a or 4b depends on our timing. I have to note, that this is my personal planing, not planing of whole porter group, but I expect they would agree. Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594940: Includes binary-only and obfuscated C code
On Sat, 2010-11-06 at 10:48 +0100, Petr Salinger wrote: For the remainder of the files, whilst we may consider granting a squeeze-ignore tag, we would like to come to an agreement as to how we can resolve these issues in the medium term. We appreciate that the BSD kernel has not received the same level of upstream attention that the Linux kernel has in recent years in terms of ensuring that all content is freely distributable. We believe that working with them on these issues can only be of benefit for free software, and would help to move the kfreebsd-* architectures from technology previews towards fully supported stable releases with everything we have to come to expect from the Linux architectures. [...] Now we have to somehow prune current source tree and disable some modules. Could we get squeeze-ignore tag for some of the affected files or is it necessary to prune all affected files ? Ben's original lists included some files which we don't appear to be able to distribute at all. If his analysis is correct then those files at least would need to be removed rather than ignored. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594940: Includes binary-only and obfuscated C code
Now we have to somehow prune current source tree and disable some modules. Could we get squeeze-ignore tag for some of the affected files or is it necessary to prune all affected files ? Ben's original lists included some files which we don't appear to be able to distribute at all. If his analysis is correct then those files at least would need to be removed rather than ignored. The question is whether pruning following files suffices: sys/gnu/dev/sound/pci/csaimg.h - not packaged; not distributable since the stated licence is GPL sys/gnu/dev/sound/pci/maestro3_dsp.h - not packaged; not distributable since the stated licence is GPL sys/dev/fatm/firmware.h - not packaged; not distributable sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu sys/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu sys/dev/hptrr/amd64-elf.hptrr_lib.o.uu sys/dev/hptrr/i386-elf.hptrr_lib.o.uu sys/dev/hptmv/i386-elf.raid.o.uu sys/dev/hptmv/amd64-elf.raid.o.uu - uuencoded files with binary code to run on the host, without accompanying source code (not used even now - see 903_disable_non-free_drivers.diff) Or whether we have to drop all mentioned files or something between. Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594940: Includes binary-only and obfuscated C code
For the remainder of the files, whilst we may consider granting a squeeze-ignore tag, we would like to come to an agreement as to how we can resolve these issues in the medium term. We appreciate that the BSD kernel has not received the same level of upstream attention that the Linux kernel has in recent years in terms of ensuring that all content is freely distributable. We believe that working with them on these issues can only be of benefit for free software, and would help to move the kfreebsd-* architectures from technology previews towards fully supported stable releases with everything we have to come to expect from the Linux architectures. Does the kfreebsd kernel include the ability to load firmware from external files, akin to /lib/firmware on Linux? If so, this would hopefully make the process of moving the firmware files out-of-kernel much less painful, particularly for those cases where firmware-non-free already includes the affected files. Currently, there exists a related kernel interface for it. http://www.freebsd.org/cgi/man.cgi?query=firmware: FIRMWARE LOADING MECHANISMS Any component of the system can register firmware images at any time by simply calling firmware_register(). This is typically done when a module containing a firmware image is given control, whether compiled in, or preloaded by /boot/loader, or manually loaded with kldload(8). However, a system can implement additional mechanisms to bring these images in memory before calling firmware_register(). When firmware_get() does not find the requested image, it tries to load it using one of the available loading mechanisms. At the moment, there is only one, namely Loadable kernel modules. We could probably extend it. But definitely not in time for squeeze. Now we have to somehow prune current source tree and disable some modules. Could we get squeeze-ignore tag for some of the affected files or is it necessary to prune all affected files ? Cheers Petr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594940: Includes binary-only and obfuscated C code
On Sun, 2010-10-03 at 13:04 +0200, Cyril Brulebois wrote: Ben Hutchings b...@decadent.org.uk (30/08/2010): The following C files contain firmware images in binary-equivalent form but are not obviously accompanied by the corresponding source code: […] Hi, and thanks for your report. I'm not sure we're going to have time and manpower to fix this bug in time for squeeze; that's why I'm wondering whether it could be granted a squeeze-ignore exception. Cc-ing the release team. Hi, Apologies for not getting back to you sooner regarding this. Firstly, we'd like to thank Ben for his offer to help incorporate those files which we are able to distribute into the existing firmware-nonfree package. Sadly, the list mentioned in the bug log includes some files which we cannot distribute for various reasons; these appear to be a couple of sound drivers, some network card drivers, firmware for an ATM card (which Google suggests is intended for use in Alpha machines) and some serial multiplexers and adapters. Without the ability to distribute the affected files, there is not a great deal we can do to resolve these issues other than removing them. For the remainder of the files, whilst we may consider granting a squeeze-ignore tag, we would like to come to an agreement as to how we can resolve these issues in the medium term. We appreciate that the BSD kernel has not received the same level of upstream attention that the Linux kernel has in recent years in terms of ensuring that all content is freely distributable. We believe that working with them on these issues can only be of benefit for free software, and would help to move the kfreebsd-* architectures from technology previews towards fully supported stable releases with everything we have to come to expect from the Linux architectures. Does the kfreebsd kernel include the ability to load firmware from external files, akin to /lib/firmware on Linux? If so, this would hopefully make the process of moving the firmware files out-of-kernel much less painful, particularly for those cases where firmware-non-free already includes the affected files. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594940: Includes binary-only and obfuscated C code
On Tue, Oct 26, 2010 at 11:32:13PM +0100, Adam D. Barratt wrote: ... For the remainder of the files, whilst we may consider granting a squeeze-ignore tag, we would like to come to an agreement as to how we can resolve these issues in the medium term. ... Can you actually add a squeeze-ignore tag without a GR? It appears to me this situation is similar to the Sarge-exception for Linux that required GR 2004-003, or do I miss anything here? Regards, Adam cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594940: Includes binary-only and obfuscated C code
Ben Hutchings b...@decadent.org.uk (30/08/2010): Package: kfreebsd-8 Version: 8.1-5 Severity: serious The following C files contain firmware images in binary-equivalent form but are not obviously accompanied by the corresponding source code: […] Hi, and thanks for your report. I'm not sure we're going to have time and manpower to fix this bug in time for squeeze; that's why I'm wondering whether it could be granted a squeeze-ignore exception. Cc-ing the release team. Mraw, KiBi. signature.asc Description: Digital signature
Bug#594940: Includes binary-only and obfuscated C code
Package: kfreebsd-8 Version: 8.1-5 Severity: serious The following C files contain firmware images in binary-equivalent form but are not obviously accompanied by the corresponding source code: sys/contrib/dev/ral/rt2661_ucode.h - binaries are packaged in firmware-ralink as /lib/firmware/ralink/rt2?6*.bin sys/gnu/dev/sound/pci/csaimg.h - not packaged; not distributable since the stated licence is GPL sys/gnu/dev/sound/pci/maestro3_dsp.h - not packaged; not distributable since the stated licence is GPL sys/dev/drm/mga_ucode.h - binaries are packaged in firmware-linux-nonfree as /lib/firmware/matrox/* sys/dev/drm/r128_cce.c - binary is packaged in firmware-linux-nonfree as /lib/firmware/r128/r128_cce.bin sys/dev/drm/r600_microcode.h sys/dev/drm/radeon_microcode.h - binaries are packaged in firmware-linux-nonfree as /lib/firmware/radeon/* sys/dev/txp/3c990img.h - binary is packaged in firmware-linux-nonfree as /lib/firmware/3com/typhoon.bin sys/dev/fxp/rcvbundl.h - binaries are packaged in firmware-linux-nonfree as /lib/firmware/e100/* sys/dev/digi/*X*.h - not packaged; distributable sys/dev/sf/starfire_rx.h sys/dev/sf/starfire_tx.h - not packaged; maybe distributable sys/dev/sn/ositech.h - not packaged; distributable sys/dev/sound/pci/ds1-fw.h - not packaged; distributable sys/dev/si/si2_z280.c sys/dev/si/si3_t225.c - not packaged; maybe distributable sys/dev/cxgb/common/cxgb_ael1002.c - binaries are packaged in firmware-linux-nonfree as /lib/firmware/cxgb3/ael*.bin sys/dev/fatm/firmware.h - not packaged; not distributable sys/dev/cx/csigmafw.h - not packaged; maybe distributable sys/dev/bce/if_bcefw.h - binaries are packaged in firmware-bnx2 as /lib/firmware/bnx2/bnx2/*.fw sys/dev/usb/net/if_kuefw.h - binaries are packaged in firmware-linux-nonfree as /lib/firmware/kaweth/* sys/dev/usb/wlan/if_rumfw.h - binary is packaged in firmware-ralink as /lib/firmware/ralink/rt73.bin sys/dev/usb/wlan/if_zydfw.h - not packaged; distributable sys/dev/ti/ti_fw2.h sys/dev/ti/ti_fw.h - not packaged; maybe distributable sys/dev/ctau/ctaue1fw.h sys/dev/ctau/ctau2fw.h sys/dev/ctau/ctaufw.h sys/dev/ctau/ctaug7fw.h - not packaged; maybe distributable sys/dev/ispfw/asm_*.h - binaries are packaged in firmware-qlogic as /lib/firmware/ql*_fw.bin sys/dev/advansys/adwmcode.c - binary is packaged in firmware-linux-nonfree as /lib/firmware/advansys/mcode.bin As one of the maintainers of firmware-nonfree, I'm happy to cooperate in adding any firmware images from FreeBSD that Debian can legally distribute. Additionally, these C files contain obfuscated code: sys/dev/ce/tau32-ddk.c sys/dev/cp/cpddk.c Ben. -- System Information: Debian Release: squeeze/sid APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594940: Includes binary-only and obfuscated C code
Additionally, the following uuencoded files contain binary-equivalent firmware images with no accompanying source code: sys/contrib/dev/mwl/mwlboot.fw.uu sys/contrib/dev/mwl/mw88W8363.fw.uu - not packaged; distributable sys/contrib/dev/ral/rt2561.fw.uu sys/contrib/dev/ral/rt2561s.fw.uu sys/contrib/dev/ral/rt2860.fw.uu sys/contrib/dev/ral/rt2661.fw.uu sys/contrib/dev/run/rt2870.fw.uu - packaged in firmware-ralink sys/contrib/dev/npe/IxNpeMicrocode.dat.uu - not packaged; distributable sys/contrib/dev/ipw/ipw2100-1.3-i.fw.uu sys/contrib/dev/ipw/ipw2100-1.3-p.fw.uu sys/contrib/dev/ipw/ipw2100-1.3.fw.uu sys/contrib/dev/iwi/ipw2200-ibss.fw.uu sys/contrib/dev/iwi/ipw2200-bss.fw.uu sys/contrib/dev/iwi/ipw2200-sniffer.fw.uu - packaged in firmware-ip2x00 sys/contrib/dev/uath/ar5523.bin.uu - not packaged; no licence visible sys/contrib/dev/iwn/iwlwifi-5150-8.24.2.2.fw.uu sys/contrib/dev/iwn/iwlwifi-1000-128.50.3.1.fw.uu sys/contrib/dev/iwn/iwlwifi-5000-8.24.2.12.fw.uu sys/contrib/dev/iwn/iwlwifi-4965-228.61.2.24.fw.uu sys/contrib/dev/iwn/iwlwifi-6000-9.193.4.1.fw.uu sys/contrib/dev/wpi/iwlwifi-3945-2.14.4.fw.uu - packaged in firmware-iwlwifi And the following uuencoded files appear to contain x86 binary code to run on the host, without accompanying source code: sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu sys/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu sys/dev/hptrr/amd64-elf.hptrr_lib.o.uu sys/dev/hptrr/i386-elf.hptrr_lib.o.uu sys/dev/hptmv/i386-elf.raid.o.uu sys/dev/hptmv/amd64-elf.raid.o.uu Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
