Secure Boot meeting at DebConf
You might be interested in this meeting at DebConf. It should be streamed (see http://blog.debconf.org/blog/debconf13/hl_dc13_video.dc) so others can participate by IRC, though I'm not sure how well that works for meetings. Secure Boot for Debian Linux today, 14:30 CST (12:30 UTC), talk room 2 https://penta.debconf.org/penta/schedule/dc13/event/1039.en.html Colin Watson will be present and can talk about how Ubuntu has implemented this. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Linux kernel ABI bump in testing: from 3.9-1 to 3.10-2
Linux kernel ABI bump in testing: from 3.9-1 to 3.10-2 Full summary: http://d-i.debian.org/kernel-summary.html#testing -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1v9bra-0001tg...@ravel.debian.org
Bug#719411: tasksel: Standard out-of-the-box configuration as a router
Hi, It seems you have a couple of separate ideas maybe: * a pre-configured system, a project more like a 'Debian Pure Blend' * a generic 'tasksel' task of networking utils The FreedomBox is an example of a more specialised project. Debian Edu also preconfigures its servers for NAT. And there is also https://wiki.debian.org/DebianLAN You may want to look at the third-party project LibreWrt which sounds like it could be optionally built from Debian sources. (Official builds are based on Trisquel, a Debian derivative). FWIW for 7+ years I have used *only* Debian GNU/Linux, Debian GNU/kFreeBSD, or other *BSDs for routers or access points at home, and at some other deployments too. I already know which packages I need, so as long as the installed system has network access I can get them from a network mirror later. If it was viable to create a tasksel task for this, it would be difficult to decide how many packages is enough, or too many. Systems used as routers are often low-powered with very limited space. It is desirable to provide everything possibly needed to get a network connection, then maybe some 'Recommends' on other useful packages. My own ideas are: Wireless: * iw [not kfreebsd-amd64, kfreebsd-i386] * wireless-tools [not kfreebsd-amd64, kfreebsd-i386] * hostapd Modem: * ppp [not kfreebsd-amd64, kfreebsd-i386] * pppoe * pppoeconf * usb-modeswitch Services: * bind9 * isc-dhcp-client * isc-dhcp-server * ntp * openssh-server IPv6: * radvd Diagnostic: * dnsutils * elinks * inetutils-ping * inetutils-traceroute * mtr-tiny * nmap * tcpdump * wget * whois Reporting: * collectd-core * logwatch VPN: * ipsec-tools * openvpn * strongswan Firewall/traffic shaping: * iptables [not kfreebsd-amd64, kfreebsd-i386] * iproute [not kfreebsd-amd64, kfreebsd-i386] * pf [kfreebsd-amd64, kfreebsd-i386] * denyhosts | fail2ban (for protecting the router itself) + more userland tools for managing a firewall (as long as having them installed doesn't mean they are immediately active/conflicting). wondershaper, shorewall, ufw... And offline documentation! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/520a3d96.9090...@pyro.eu.org
Re: D-I build failures for kfreebsd-amd64....
Hi, On 03/08/13 14:58, Christian PERRIER wrote: Quoting Steven Chamberlain (ste...@pyro.eu.org): Yes, for grub2 2.0 we just need to drop pxecmd. Sort of related to So, you mean drop it from there? installer/build/config/hurd.cfg:GRUB_MODULES_PXE=pxe pxecmd I've done this with my first d-i commit. It should address the build failures, but the kfreebsd/hurd netboot images won't actually work yet due to #711799. http://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=commitdiff;h=07036d2f693b5aebaaa2708534bbde6080595efd Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/520a4884.2070...@pyro.eu.org
Plan of action for Secure Boot support
Colin Watson and Stefano Rivera talked about how Ubuntu had implemented Secure Boot and what they believed were the requirements. Apparently, the Secure Boot spec requires each stage of the boot code to validate signatures only until ExitBootServices() is called. (At this point the firmware makes some parts of its non-volatile configuration inaccessible.) While some users would probably like to be able to 'lock down' the kernel, requiring signed modules and disabling other kernel features that allow code injection, this does not seem to be a requirement for booting on systems that implement Windows 8 logo requirements in the usual way, i.e. that require a Microsoft-signed first stage boot loader. There seemed to be a consensus that we could use an implementation quite similar to Ubuntu's. Some may be concerned that use of a Microsoft signing key results in a non-free binary, but so long as the target machines (amd64 architecture) generally allow installation of alternate public keys this is not so different from the way that APT on a Debian system requires Debian-signed Release files by default. So the plan seems to be: 1. Colin Watson will prepare dak changes to support upload and subsequent signing of EFI executables. (This is an embedded, not detached, signature.) 2. Steve Langasek will prepare and upload a package of the 'shim' EFI boot loader. This will embed our own set of public keys (corresponding to those used by dak) and can load any other EFI executable signed by one of them. Later, there will be a shim-signed package containing the same executable with a Microsoft signature. (This costs money and takes several days, but shim should require only very infrequent changes.) 3. Colin Watson will update the GRUB package to build a to-be-signed monolithic EFI executable separate from the package. Then he will add a grub-signed package that includes the Debian-signed executable from the archive. This executable would be suitable for use on both removable media and the installed system. 4. The kernel team may also need to upload kernel images for signing and add linux-image-signed packages with the Debian-signed kernel images. This is because some quirks in the kernel should be run before calling ExitBootServices(). Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Re: Plan of action for Secure Boot support
On Tue, 2013-08-13 at 22:54 +0200, Ben Hutchings wrote: Colin Watson and Stefano Rivera talked about how Ubuntu had implemented Secure Boot and what they believed were the requirements. [...] Sorry, I'm having name confusion here. Who do I really mean? Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Re: Plan of action for Secure Boot support
Hi, many thanks for the summary. Ben Hutchings b...@decadent.org.uk (2013-08-13): Colin Watson and Stefano Rivera talked about how Ubuntu had implemented Secure Boot and what they believed were the requirements. Apparently, the Secure Boot spec requires each stage of the boot code to validate signatures only until ExitBootServices() is called. (At this point the firmware makes some parts of its non-volatile configuration inaccessible.) While some users would probably like to be able to 'lock down' the kernel, requiring signed modules and disabling other kernel features that allow code injection, this does not seem to be a requirement for booting on systems that implement Windows 8 logo requirements in the usual way, i.e. that require a Microsoft-signed first stage boot loader. There seemed to be a consensus that we could use an implementation quite similar to Ubuntu's. Some may be concerned that use of a Microsoft signing key results in a non-free binary, but so long as the target machines (amd64 architecture) generally allow installation of alternate public keys this is not so different from the way that APT on a Debian system requires Debian-signed Release files by default. So the plan seems to be: 1. Colin Watson will prepare dak changes to support upload and subsequent signing of EFI executables. (This is an embedded, not detached, signature.) 2. Steve Langasek will prepare and upload a package of the 'shim' EFI boot loader. This will embed our own set of public keys (corresponding to those used by dak) and can load any other EFI executable signed by one of them. Later, there will be a shim-signed package containing the same executable with a Microsoft signature. (This costs money and takes several days, but shim should require only very infrequent changes.) 3. Colin Watson will update the GRUB package to build a to-be-signed monolithic EFI executable separate from the package. Then he will add a grub-signed package that includes the Debian-signed executable from the archive. This executable would be suitable for use on both removable media and the installed system. 4. The kernel team may also need to upload kernel images for signing and add linux-image-signed packages with the Debian-signed kernel images. This is because some quirks in the kernel should be run before calling ExitBootServices(). (Sorry, I'm new to all this) do you mean (1) the regular linux image packages are getting a signature added, and we're using those like we do today, or (2) that we'll have additional linux image packages with the signatures to be used instead of the usual linux image packages when a Secure Boot environment is detected? (or (3) something else…) [As a side yet relevant note: I think there's a general agreement that we aren't going to target putting as many things as possible on a regular CD like we used to do, so a few grub/bootloader things are probably OK; having duplicate linux image packages wouldn't look too nice though.] Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130813213857.ga25...@mraw.org
Re: Plan of action for Secure Boot support
Cyril Brulebois wrote: (Sorry, I'm new to all this) do you mean (1) the regular linux image packages are getting a signature added, and we're using those like we do today, or (2) that we'll have additional linux image packages with the signatures to be used instead of the usual linux image packages when a Secure Boot environment is detected? (or (3) something else…) The secure boot shim is a small bootloader. It's the only part that absolutely needs to be signed by MS, AIUI. It was designed to facilitate distributions in our position. Signed versions are also already available, produced by DD Matthew Garret, though not as Debian packages (perhaps he could be convinced to maintain it?) http://mjg59.dreamwidth.org/20303.html http://www.codon.org.uk/~mjg59/shim-signed/ (Assuming the plan is to use Matthew's shim and not the other one created by IIRC, the Linux Foundation.) -- see shy jo signature.asc Description: Digital signature
Re: Plan of action for Secure Boot support
On Tue, 2013-08-13 at 23:38 +0200, Cyril Brulebois wrote: [...] 4. The kernel team may also need to upload kernel images for signing and add linux-image-signed packages with the Debian-signed kernel images. This is because some quirks in the kernel should be run before calling ExitBootServices(). (Sorry, I'm new to all this) do you mean (1) the regular linux image packages are getting a signature added, and we're using those like we do today, or (2) that we'll have additional linux image packages with the signatures to be used instead of the usual linux image packages when a Secure Boot environment is detected? (or (3) something else…) [...] Signing of EFI executables (aside from MS signature on shim) would be done by dak and would require manual intervention from the FTP team. Editing of binary packages is icky, so that's not part of the plan. Instead, after dak signs an executable, the package maintainer downloads and copies those into a separate 'source' package, which has a trivial debian/rules. (And of course will generate an appropriate 'Built-Using' header.) I suppose GRUB's Linux configuration generator will also need to prefer a signed vmlinuz (whatever name it gets) to the unsigned version. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Debian installer build: failed or old builds
Debian installer build overview --- Failed or old builds: * OLD BUILD:armhf Aug 11 09:48 buildd@hasse build_mx5_netboot http://d-i.debian.org/daily-images/armhf/daily/build_mx5_netboot.log * OLD BUILD:armhf Aug 11 09:51 buildd@hasse build_mx5_network-console http://d-i.debian.org/daily-images/armhf/daily/build_mx5_network-console.log * OLD BUILD:armhf Aug 11 09:58 buildd@hasse build_mx5_netboot-gtk http://d-i.debian.org/daily-images/armhf/daily/build_mx5_netboot-gtk.log * OLD BUILD:armhf Aug 11 10:02 buildd@hasse build_vexpress_netboot http://d-i.debian.org/daily-images/armhf/daily/build_vexpress_netboot.log * OLD BUILD:ia64 May 26 00:12 buildd@alkman build_cdrom http://d-i.debian.org/daily-images/ia64/daily/build_cdrom.log * OLD BUILD:ia64 May 26 00:16 buildd@alkman build_netboot http://d-i.debian.org/daily-images/ia64/daily/build_netboot.log Totals: 127 builds (0 failed, 6 old) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1v9pry-0007pb...@ravel.debian.org
unable to install apps
good day sir. i just installed debian wheezy kde from a live cd image. but any time i try to apt-get update or aptitude update i get this message= Ign cdrom://[Debian GNU/Linux 7.0.0 _Wheezy_ - Official Snapshot amd64 LIVE/INSTALL Binary 20130505-13:41] wheezy Release.gpg Ign cdrom://[Debian GNU/Linux 7.0.0 _Wheezy_ - Official Snapshot amd64 LIVE/INSTALL Binary 20130505-13:41] wheezy Release Ign cdrom://[Debian GNU/Linux 7.0.0 _Wheezy_ - Official Snapshot amd64 LIVE/INSTALL Binary 20130505-13:41] wheezy/main amd64 Packages/DiffIndex Ign cdrom://[Debian GNU/Linux 7.0.0 _Wheezy_ - Official Snapshot amd64 LIVE/INSTALL Binary 20130505-13:41] wheezy/main Translation-en_NG Ign cdrom://[Debian GNU/Linux 7.0.0 _Wheezy_ - Official Snapshot amd64 LIVE/INSTALL Binary 20130505-13:41] wheezy/main Translation-en please what can be done. i am unable to install apps
