Bug#942723: ITP: medialibrary -- library for managing media files in a media library
Package: wnpp Severity: wishlist Owner: Sebastian Ramacher * Package name: medialibrary Version : 0.4.0 Upstream Author : Videolan * URL : https://code.videolan.org/videolan/medialibrary * License : LGPL-2.1+ Programming Lang: C++ Description : library for managing media files in a media library Medialibrary provides tools for media applications to manage their media libraries. It supports media discovery, metadata handling, and a database backend. The latter provides ways to easily search and browse the media library. This package will be maintained within the multimedia team and will be required for vlc 4.0 Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#942741: ITP: lxqt-organizer -- LXQt Pim, right now only an basic organizer
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: lxqt-organizer Version : 0.1.0 Upstream Author : crispinalan * URL : https://github.com/lxqt/lxqt-organizer * License : LGPL Programming Lang: C++ Description : LXQt Pim, right now only an basic organizer The LXQt Team will maintain the package
Wifi en debian
Queridos debianos, Estos días estoy probando diferentes distribuciones de linux. Entre ellas Debian. Creía que era una de las mejores, pero me he dado cuenta de que es la peor, según mis gustos. ¿Como puede ser, que una distribución del 2019 venga sin los drivers del wifi instalados??? De todas las distros, y he probado bastantes, Debian es la única que viene sin wifi. He buscado en internet, y la única solución que dan es conectarse por cable para configurar la wifi. Pero se supone, que si me conecto por wifi es porque no tengo la posibilidad de conectarme por cable. ¿Tan difícil es dejar instalados los drivers? Hasta en las más básicas y pobres distros te puedes conectar por wifi. La verdad es que no entiendo el motivo. ¿Sabrían decirmelo? Muchas gracias. Riber.
Re: Wifi en debian
translation of spanish email: disappointed wifi didn´t work out of the box with Debian thinking wifi drivers are missing. answer: I don't think the drivers are the problem for wifi in Debian. Most, if not all wireless chipsets have open source drivers which are included. The problem is that many wireless chips require non-free firmware. check out the list here: https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers Debian is very principled about not including non-free software, but you can build an installation medium that includes the firmware so almost all wifi should work out of the box. see here: https://www.debian.org/releases/buster/amd64/ch06s04.en.html On Sun, Oct 20, 2019 at 5:42 PM riber enyos wrote: > Queridos debianos, > Estos días estoy probando diferentes distribuciones de linux. Entre ellas > Debian. Creía que era una de las mejores, pero me he dado cuenta de que es > la peor, según mis gustos. > ¿Como puede ser, que una distribución del 2019 venga sin los drivers del > wifi instalados??? De todas las distros, y he probado bastantes, Debian es > la única que viene sin wifi. He buscado en internet, y la única solución > que dan es conectarse por cable para configurar la wifi. Pero se supone, > que si me conecto por wifi es porque no tengo la posibilidad de conectarme > por cable. ¿Tan difícil es dejar instalados los drivers? Hasta en las más > básicas y pobres distros te puedes conectar por wifi. La verdad es que no > entiendo el motivo. > ¿Sabrían decirmelo? > Muchas gracias. > Riber. >
Bug#942754: ITP: volatility3 -- advanced memory forensics framework
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho * Package name: volatility3 Version : 1.0.0-beta.1 Upstream Author : Volatility Foundation * URL : https://github.com/volatilityfoundation/volatility3 * License : Special, available at https://www.volatilityfoundation.org/license/vsl-v1.0 Programming Lang: Python Description : advanced memory forensics framework The Volatility Framework is a collection of tools for the extraction of digital artifacts from volatile memory (RAM) samples. It is useful in forensics analysis. The extraction techniques are performed completely independent of the system being investigated but offer unprecedented visibility into the runtime state of the system. . Volatility 3 is a full replacement of Volatility, using Python 3 instead of Python 2.
Re: Wifi en debian
On 2019-10-20 18:32:00 -0400 (-0400), Peter Silva wrote: [...] > Debian is very principled about not including non-free software, but you > can build an installation medium that includes the firmware so almost all > wifi should work out of the box. [...] Or use the installation images available from https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/ which have it baked in. -- Jeremy Stanley signature.asc Description: PGP signature
Summary of the Secure Boot BoF at DC19 [long, late]
[ Please note the cross-post and Reply-To ] Hi folks, As promised, here's a summary of what was discussed at the BoF session at DebConf19 in Curitiba. Apologies for the huge delay in posting - life... :-/ Thanks to the awesome efforts of our video team, video of the session is online [1]. I've taken a copy of the Gobby notes too, alongside my small set of slides for the session. [2] = Secure Boot. In Debian. In Buster. Really. Sunday, 2019-07-21, 13:30 What is Secure Boot? Simply, it is a way for computer firmware to validate that the boot-time binaries it runs are the right ones - they have not been tampered with, e.g. infested by malware. This works using a chain of signatures, based on public key crypto. It is typically *not* designed to totally lock down what software a user can run on their system. It *is* designed to stop boot-time malware - verifying the boot loader and kernel means that the operating system, virus checkers, (etc.) can be started in a known-clean state. UEFI Secure Boot is included and enabled by default in just about every modern x86 machine. It can be disabled if desired, but it's genuinely useful technology and we should be part of it. In the Linux world == Most of the Linux distro community have decided to use shim as part of their UEFI Secure Boot support. Shim is a tiny, really simple first-stage boot loader started by Matthew Garrett. It is well audited, well understood, etc. It has a simple job: it is a single piece of signed software that verifies and runs the next stage bootloader (Grub). It's a collaborative project, with contributions from many people in lots of the distributions. Microsoft act as the Certification Authority (CA) for UEFI SB here - for obvious reasons their key is present on almost all x86 computers as shipped. They *don't* want to sign Grub, as it's too large and complex and (importantly) they don't like the GPLv3 licence there. Instead, Microsoft will sign the simple, small, BSD-licenced shim. A team of cross-distro people are responsible for reviewing the shim patches and builds that are presented for signing. Microsoft trust us to do that job - they don't pretend to be experts in how shim works. Each distro builds a version of shim with their own key(s) embedded, and those key(s) are used for validating further things that are loaded: Grub, Linux, firmware update programs, etc. Users can also enrol their own Machine Owner Key(s) (MOK) on the system, and shim will also use those key(s) for validation. This is an important feature - end users have control over the keys that are used here. In Debian, we use our own key to sign some of the binaries generated by a small number of source packages: Grub, shim (helper binaries), Linux (and modules) and fwupd/fwupdate. We *can* sign other things if we need to, but we want to keep the list of signed packages small and controlled. Anything that is signed here must have a good security story, for obvious reasons. There are restrictions applied *by default* to systems booted with SB enabled. Examples: 1. Grub will refuse to boot unsigned kernels. [ Ubuntu's signed version of Grub initially would allow booting with unsigned kernels, but this was widely agreed to be a mistake and things have now been changed here. ] 2. No non-free/out-of-tree kernel modules will be loaded by Debian's kernel, as they will not be signed. It is possible for users to sign them (via MOK, for example); Ubuntu have methods to do module signing in a more automated fashion, but we haven't yet set up similar in Debian. More on this later. 3. Hibernation is disabled. All the state of the hibernated system is put into the hibernation space (swap); it's very difficult to secure and validate that data so that a cleanly-booted system can know to trust it. This might be solved in the future, but not yet. Is this supported in Debian? YES! Finally! Everything is deployed (since earlier in 2019) so that everything should work on three architectures: amd64, i386, arm64. Most users are likely to be on amd64, but the others should work too. On arm64, a minor issue is that there has not been a single CA for arm64 machines to use until very recently, so a lot of current machines will need configuration to be able to secure things. Microsoft has recently agreed to act as a CA here also, but it may take time for this setup to turn up on common shipping hardware. Our signed packages are pulled in using Recommends, to still allow people to *not* have them installed if that is preferred. This means that standard installation methods will be secure by default, but be careful during installation of packages when using apt --no-install-recommends. An important target here is that SB should Just Work for people, invisibly. Any problems are bugs that should be
FTBFS on i386 for user mode linux
Hi, I recently refreshed User Mode Linux to version 5.2 in Debian Unstable. The package built fine for amd64 but for i386, I have run into the following build failure. Any help on how to solve this build failure ? CC arch/um/drivers/slirp_kern.o CC arch/um/drivers/slirp_user.o CC arch/um/drivers/daemon_kern.o CC arch/um/drivers/daemon_user.o CC arch/um/drivers/vector_kern.o CC arch/um/drivers/vector_user.o CC arch/um/drivers/vector_transports.o CC arch/um/drivers/vde_kern.o CC arch/um/drivers/vde_user.o ld -r -dp -o arch/um/drivers/vde.o arch/um/drivers/vde_kern.o arch/um/drivers/vde_user.o -m elf_x86_64 -r /usr/lib/gcc/i686-linux-gnu/9/../../../../lib/libvdeplug.a ld: relocatable linking with relocations from format elf32-i386 (/usr/lib/gcc/i686-linux-gnu/9/../../../../lib/libvdeplug.a(libvdeplug.o)) to format elf64-x86-64 (arch/um/drivers/vde.o) is not supported make[2]: *** [arch/um/drivers/Makefile:31: arch/um/drivers/vde.o] Error 1 make[1]: *** [Makefile:1061: arch/um/drivers] Error 2 make[1]: Leaving directory '/<>/linux-source-5.2' make: *** [debian/rules:75: build-stamp] Error 2 Full build log is accessible from the buildd page linked on the tracker page: https://tracker.debian.org/pkg/user-mode-linux https://buildd.debian.org/status/package.php?p=user-mode-linux -- Given the large number of mailing lists I follow, I request you to CC me in replies for quicker response signature.asc Description: This is a digitally signed message part
