Bug#1032692: ITP: gitleaks -- protect and discover secrets using Gitleaks
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: gitleaks Version : 8.16.0-1 Upstream Author : Zachary Rice * URL : https://github.com/gitleaks/gitleaks * License : Expat Programming Lang: Go Description : protect and discover secrets using Gitleaks 🔑 Gitleaks is a SAST tool for **detecting** and **preventing** hardcoded secrets like passwords, api keys, and tokens in git repos. Gitleaks is an **easy-to-use, all-in-one solution** for detecting secrets, past or present, in your code.
Re: Unlock LUKS with login/password
On Mar 10, Stephan Verbücheln wrote: > On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote: > > In the future the initramfs will (usually) be static as well. > Can you provide more information on that? Due to multiple reasons, mostly related to secure boot and boot attestation, there is significant interest by distributions in providing static and signed initrds. BTW, I have been informed that "initramfs" is an obsolete term and that we are back to "initrd" like in the '90s. Some people in Debian are interested in working on https://github.com/systemd/mkosi-initrd, which will provide a static initrd built from system binaries and extensible using the systemd-sysext and future systemd-sysconf mechanisms for things like SAN boot or sshd in the initrd. Do not look too hard at it at this point: the upstream developers are going to make soon a new release with significant changes. I expect that people interested in working on initramfs-tools can probably extend it with little work to generate static images suitable for the most common deployments. People with uncommon ones will have to do without the modern boot attestation features or else sign their own images (which will be very easy once I, or somebody else, will have packaged sbctl). Obviously there are no new requirements for the systems without secure boot. -- ciao, Marco signature.asc Description: PGP signature
Bug#1032663: ITP: eludris -- A simple CLI to help you with setting up and managing your Eludris instance
Package: wnpp Severity: wishlist Owner: Oliver Wilkes X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : eludris Version : 0.3.2 Upstream Author : Oliver Wilkes * URL : https://github.com/eludris/eludris/tree/main/cli/ * License : MIT Programming Lang: Rust Description : A simple CLI to help you with setting up and managing your Eludris instance Located at https://github.com/eludris/eludris/tree/main/cli, this is a package for creating an Eludris instance with ease. It is officially supported and maintained by Eludris and reduces the barrier to entry for new instance owners. ### Why is this package useful/relevant? This CLI provides an easy way for users to create their own Eludris instance from scratch. There are currently no alternatives as Eludris is relatively new and this is an 'official' CLI. ### How do you plan to maintain it? I am not all too sure how this works as this is my first time packaging for Debian. I plan to maintain it solo for now, unless if anyone has any better suggestions as to what team to maintain it under.
ITP: golang-github-radovskyb-watcher -- a Go package for watching for files or directory changes without using filesystem events.
Package: wnpp Severity: wishlist Owner: Mark E. Fuller * Package name: golang-github-radovskyb-watcher Version : 1.0.7-1 Upstream Author : Benjamin Radovsky * URL : https://github.com/radovskyb/watcher * License : BSD-3-clause Programming Lang: Go Description : watcher is a Go package for watching for files or directory changes without using filesystem events. watcher is a Go package for watching for files or directory changes (recursively or non recursively) without using filesystem events, which allows it to work cross platform consistently. . watcher watches for changes and notifies over channels either anytime an event or an error has occurred. Reason for packaging: Needed by go-task
ITP: golang-github-go-task-slim-sprig -- Useful template functions for Go templates.
Package: wnpp Severity: wishlist Owner: Mark E. Fuller * Package name: golang-github-go-task-slim-sprig Version : 2.20.0-1 Upstream Author : Andrey Nering * URL : https://github.com/go-task/slim-sprig * License : MIT Programming Lang: Go Description : Useful template functions for Go templates. Slim-Sprig: Template functions for Go templates GoDoc (https://godoc.org/github.com/go-task/slim-sprig) Go Report Card (https://goreportcard.com/report/github.com/go-task/slim-sprig) . Slim-Sprig is a fork of Sprig (https://github.com/Masterminds/sprig), but with all functions that depend on external (non standard library) or crypto packages removed. The reason for this is to make this library more lightweight. Most of these functions (specially crypto ones) are not needed on most apps, but costs a lot in terms of binary size and compilation time. Reason for packaging: Needed by go-task
ITP: golang-github-sajari-fuzzy -- Spell checking and fuzzy search suggestion written in Go
Package: wnpp Severity: wishlist Owner: Mark E. Fuller * Package name: golang-github-sajari-fuzzy Version : 1.0.0-1 Upstream Author : Search.io * URL : https://github.com/sajari/fuzzy * License : MIT Programming Lang: Go Description : Spell checking and fuzzy search suggestion written in Go Fuzzy is a very fast spell checker and query suggester written in Golang. Reason for packaging: Needed by go-task OpenPGP_0xD599E76CFFCABF60.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Unlock LUKS with login/password
On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote: > In the future the initramfs will (usually) be static as well. Can you provide more information on that? Thanks and regards Stephan signature.asc Description: This is a digitally signed message part
ITP: go-task -- A task runner / simpler Make alternative written in Go
Package: wnpp Severity: wishlist Owner: Mark E. Fuller * Package name: go-task Version : 3.21.0-1 Upstream Author : Task * URL : https://github.com/go-task/task * License : MIT Programming Lang: Go Description : A task runner / simpler Make alternative written in Go Reason for packaging: Alternative to Make with utility for development and CI OpenPGP_0xD599E76CFFCABF60.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Unlock LUKS with login/password
On Fri, 2023-03-10 at 14:28 +, Jeremy Stanley wrote: > Okay, so you're wanting to rely on encrypted /boot as an incomplete > alternative to checking file signatures, because the current > attestation solutions are also imperfect. Keep in mind that > checksumming isn't providing protection from coherent modification > of the decrypted filesystem and checksums, it's just protecting > against someone blindly modifying the encrypted blocks. No, this is not about blind modification. There are relevant attacks in this area. https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ > If they have > physical access to your system sufficient to modify firmware or add > hardware without you noticing, then encrypted /boot is pretty > pointless against such an actor. The only thing an attacker can modify in software is the GRUB binary in /boot/efi. The GRUB binary can be more easily verified by Secure Boot and it is where I enter my LUKS passphrase. > Well, it's not as if encrypted /boot is protecting you from the > attacks described in that article either. Someone with that level of > access to your system can quite easily record/copy your decryption > keys, or simply wait until you've unlocked your sensitive data. Hardware modifications are not a fair comparison. Hardware modifications can always replace anything with anything that looks alike. > Sure, if you're concerned that sensitive information is being put in > /boot sufficient to warrant the additional work of protecting it What additional work? The installer did it automatically without me even noticing for years. Having a separate /boot partition is actually more work. You need to decide on the required size, choose an appropriate filesystem etc. > from disclosure when someone steals the device or gets their hands > on the drive after disposal, then by all means go ahead. It's just > not usually worth that amount of additional complexity. Any installed program that is not in the essential setup should be considered sensitive information. > It comes down to basic cost/benefit analysis, and deciding what > threats you reasonably want to invest in defending against. I'm > certainly not saying there's *never* a reason to encrypt /boot, but > people who feel they need to do so aren't involved in improving > tools and automation sufficiently to make it convenient to set up > either. There is nothing inconvenient about it. Regards signature.asc Description: This is a digitally signed message part
Re: Unlock LUKS with login/password
On 2023-03-10 13:48:21 + (+), Stephan Verbücheln wrote: > Encryption per se does not protect against modification, I am aware of > that. That is even more true for disk encryption where the encrypted > data block has to fit into the physical disk block, so there is no room > for a MAC or signature. However, in combination with a filesystem like > btrfs which checksums everything, it is providing some protection, even > though it was not designed for that purpose. Okay, so you're wanting to rely on encrypted /boot as an incomplete alternative to checking file signatures, because the current attestation solutions are also imperfect. Keep in mind that checksumming isn't providing protection from coherent modification of the decrypted filesystem and checksums, it's just protecting against someone blindly modifying the encrypted blocks. If they have physical access to your system sufficient to modify firmware or add hardware without you noticing, then encrypted /boot is pretty pointless against such an actor. > Apart from the fact that UEFI Secure Boot is an overly complex monster > which is basically broken[1] by design, my understanding of it is also > that it does not protect configs, initramfs etc. in /boot. It only > protects the kernel image and loaded modules. > > [1] > https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/ Well, it's not as if encrypted /boot is protecting you from the attacks described in that article either. Someone with that level of access to your system can quite easily record/copy your decryption keys, or simply wait until you've unlocked your sensitive data. > In addition, files in /boot like the initrd are generated individually > and may contain files not limited to what someone puts into /boot > intentionally. In contrast to /boot/efi, /boot does not only contain > static files delivered by the distribution. Sure, if you're concerned that sensitive information is being put in /boot sufficient to warrant the additional work of protecting it from disclosure when someone steals the device or gets their hands on the drive after disposal, then by all means go ahead. It's just not usually worth that amount of additional complexity. It comes down to basic cost/benefit analysis, and deciding what threats you reasonably want to invest in defending against. I'm certainly not saying there's *never* a reason to encrypt /boot, but people who feel they need to do so aren't involved in improving tools and automation sufficiently to make it convenient to set up either. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Unlock LUKS with login/password
On Mar 10, Stephan Verbücheln wrote: > Apart from the fact that UEFI Secure Boot is an overly complex monster > which is basically broken[1] by design, my understanding of it is also > that it does not protect configs, initramfs etc. in /boot. It only > protects the kernel image and loaded modules. It can, with an appropriate configuration. > In addition, files in /boot like the initrd are generated individually > and may contain files not limited to what someone puts into /boot > intentionally. In contrast to /boot/efi, /boot does not only contain > static files delivered by the distribution. In the future the initramfs will (usually) be static as well. -- ciao, Marco signature.asc Description: PGP signature
Re: Unlock LUKS with login/password
Encryption per se does not protect against modification, I am aware of that. That is even more true for disk encryption where the encrypted data block has to fit into the physical disk block, so there is no room for a MAC or signature. However, in combination with a filesystem like btrfs which checksums everything, it is providing some protection, even though it was not designed for that purpose. Apart from the fact that UEFI Secure Boot is an overly complex monster which is basically broken[1] by design, my understanding of it is also that it does not protect configs, initramfs etc. in /boot. It only protects the kernel image and loaded modules. [1] https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/ In addition, files in /boot like the initrd are generated individually and may contain files not limited to what someone puts into /boot intentionally. In contrast to /boot/efi, /boot does not only contain static files delivered by the distribution. Regards Stephan
Bug#1032650: ITP: nvme-stas -- NVMe STorage Appliance Services
Package: wnpp Severity: wishlist Owner: Benjamin Drung X-Debbugs-Cc: debian-devel@lists.debian.org, bdr...@debian.org * Package name: nvme-stas Version : 2.3.1 Upstream Author : Martin Belanger * URL : https://github.com/linux-nvme/nvme-stas * License : Apache 2.0 Programming Lang: Python Description : NVMe STorage Appliance Services This package provides two daemons, stafd and stacd. The STorage Appliance Finder Daemon (stafd) automatically discovers NVMe-oF Discovery Controllers (DC) and retrieves the list of NVMe Storage Appliances. The STorage Appliance Connector Daemon (stacd) establishes I/O connections to the NVMe Storage Appliances discovered by stafd. I am working on packaging nvme-stas as part of my day job at Canonical. I would love to team maintain that package. Since it is a Python project it could be maintained by the Python team. Or it could form a team with the nvme package libnvme and nvme-cli. -- Benjamin Drung Debian & Ubuntu Developer
