Re: [Pkg-matrix-maintainers] Accepted matrix-synapse 1.116.0-1 (source) into unstable
Hi, On Thu, 3 Oct 2024, at 23:08, Jonas Smedegaard wrote: > Quoting Andrej Shadura (2024-10-03 21:41:49) >> On Thu, 3 Oct 2024, at 20:05, Debian FTP Masters wrote: >> >* simplify rules; >> > build-depend on dh-rust (not dh-cargo); >> > add X-Cargo-Crates hint; >> > drop patch debian-rust >> >> I disagree with you using dh-rust. Please revert this change. >> If dh-cargo doesn’t work well enough, it needs to be improved, not replaced. > I am awfully sorry that I took for granted that I could contribute > without close coordination with you. > I cannot revert the use of dh-rust and still have a package that builds. > What I can do, and will do if you want me to, is to a) remove myself > again as uploader, and b) request that ftpmasters remove the package > from unstable. > Do you want me to make sure that my contribution here is nullified? Jonas, by all means, no. I just want a bit more coordination, that’s all. -- Cheers, Andrej
Bug#1083296: ITP: buffybox -- Suite of graphical applications for the terminal
Package: wnpp Severity: wishlist Owner: Jarrah Gosbell X-Debbugs-Cc: debian-devel@lists.debian.org, Jarrah Gosbell * Package name: buffybox Version : 3.2.0 Upstream Contact: Johannes Marbach * URL : https://gitlab.com/postmarketos/buffybox * License : BSD-3-clause, TjpgDec, GPL-3+, MIT, LKC-custom-license, public-domain, FreeType-Project-License, OFL-1.1, BSD-2-clause Programming Lang: C Description : BuffyBox is a suite of graphical applications for the terminal. Buffybox includes two main user facing applications: Unl0kr and Buffyboard Unl0kr is a lightweight framebuffer On-Screen-Keyboard based on LVGL This keyboard is designed to unlock encrypted root partitions on boot on mobile devices. It is automatically launched on boot, allowing the user to enter their disk encryption password. This package replaces both the existing Unl0kr source package and osk-sdl. Buffyboard is a touch-enabled framebuffer keyboard (not only) for vampire slayers Buffyboard is a touch-enabled on-screen keyboard running on the Linux framebuffer. It's primarily intended for vampire hunting but you can also use it as a general purpose keyboard. This package will be maintained inside the DebianOnMobile Team.
Re: Alternative signature mechanisms for upstream source verification
Hi! On Fri, 2024-10-04 at 18:21:01 +, Stefano Rivera wrote: > Picking up a thread that started on debian-pyt...@lists.debian.org: > https://lists.debian.org/msgid-search/14198883.O9o76ZdvQC@galatea > > Upstreams that care about supply chain security have been building > mechanisms to authenticate their releases, beyond PGP signatures. > For example, Python started providing sigstore signatures a couple of > years ago, and is now talking about the idea of dropping PGP signatures. > https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signatures-for-cpython-artifacts/65058 Hmm, I find this usual conflation (in the upstream discussion) of GPG (or GnuPG) as if it was OpenPGP itself rather problematic, because the OpenPGP ecosystem is way richer than that, and as such way more active, and there has been and there is lots of work going on to implement and provide more usable, intuitive, secure and modern interfaces and code, be those CLI or library-first ones (not just wrapping a CLI from a library), including implementation neutral interfaces like the Stateless OpenPGP CLI (SOP). The OpenPGP work group also just got a new RFC9580 published that obsoletes RFC4880. Of course the schism between GnuPG and the OpenPGP work group is rather problematic too, but I'd hope we can manage to move into something like SOP backed by any of the many new implementations that provide it (see [S]), or barring that into any of the native interfaces by implementations that provide easier and more secure to use ones, all of which while eventually following the new RFC. [S] https://gitlab.com/dkg/openpgp-stateless-cli/-/wikis/Stateless-OpenPGP-status For an example of the activity that is going on in the OpenPGP ecosystem, here's a list of some of the non-GnuPG implementations already present in Debian, by programming language: * Rust: - Sequoia-PGP - rPGP * Haskell: - hOpenPGP * Golang: - GopenPGP * Java: - Bouncy Castle - PGPainless * Python: - PGPy * C: - RNP In addition, I'd strongly recommend checking SOP (https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/), which should be nicer to integrate into test suites and tools, by way of any of the currently available implementations in Debian, such as: * sqop / sqopv (Rust) * rsop / rsopv (Rust) * pgpainless-cli (Java) * gosop (Golang) * sopv-gpgv (C + Python) For the sopv subset we also now have a virtual package. And finally, I'd also recommend taking a look at both the Sequoia-PGP native interfaces (but note these are not yet stable, but should be RSN AFAIUI!): * sq / sqv / sq-wot / sq-keyring-linter Where in addition to the usual commands to verify, sign, etc, you have extremely useful stuff like: $ sq inspect ... $ sq cert ... $ sq toolbox keyring ... $ sq toolbox packet ... $ sq network ... $ sq ... And its GnuPG compatibility drop-in replacements, for either: * CLI: - sequoia-chameleon-gnupg (gpg-sq / gpgv-sq) - gpg-from-sq / gpgv-from-sq * Thunderbird (if you use that): - libsequoia-octopus-librnp Oh, and you can already use either SOP or the Sequoia-PGP interfaces with dpkg itself! See dpkg-buildpackage's --sign-backend. > We currently support including PGP signatures in source packages, and > verifying them in uscan. > > Should we expand this to include some of these new mechanisms? > Things brought up in the debian-python thread include: > 1. sigstore https://docs.sigstore.dev/ Although I've heard of this before, I never really checked what is the actual design behind it, and its implications. I'm not sure how reliant on centralization this is, or on the apparent specific OIDC providers currently in use, about offline operations and whether that is a first class use, or if that implies limitations, etc. Even though in the Python upstream thread it's mentioned that many upstreams are moving into using it, it's not clear to me either what are the long-term prospects of this either. I've not checked either what is the format of the certificates and signatures for this, how detectable they are, their size, etc. From Python upstream and your comment below, I take the only implementations are either Python or Golang, which seems problematic as something to have to pull into say a build-essential chroots by default. (Not to mention that these are not even yet in Debian. :) > 2. ssh signatures AFAIK these are used via ssh-keygen. The signatures are pretty easy to detect, as they are surrounded by «-BEGIN SSH SIGNATURE-» and «-END SSH SIGNATURE-» and are ASCII encoded. The certificates and signatures can be few lines or many lines, but should be relatively small, probably similar to at most an OpenPGP one. I think depending on the format the certificates can also be easily detectable. I'm not sure I'd be comfortable with having to depend (even weakly) on openssh-client to be able to work with these. At least the implementation is portabl
Alternative signature mechanisms for upstream source verification
Picking up a thread that started on debian-pyt...@lists.debian.org: https://lists.debian.org/msgid-search/14198883.O9o76ZdvQC@galatea Upstreams that care about supply chain security have been building mechanisms to authenticate their releases, beyond PGP signatures. For example, Python started providing sigstore signatures a couple of years ago, and is now talking about the idea of dropping PGP signatures. https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signatures-for-cpython-artifacts/65058 We currently support including PGP signatures in source packages, and verifying them in uscan. Should we expand this to include some of these new mechanisms? Things brought up in the debian-python thread include: 1. sigstore https://docs.sigstore.dev/ 2. ssh signatures 3. signify https://man.openbsd.org/signify.1 There is a general trend towards getting upstream sources from Git rather than tarballs in Debian, but we're a long way from moving across completely, or even finding consensus to do so. These signature mechanisms can generally be applied to git commits as well as tarballs. I see supporting them in Debian requiring: 1. Decisions on which schemes to support. I'd assume we support all that are available in Debian and have some significant use. Some, like sigstore, can be used in multiple modes, we'd have to make some selections. 2. Support in uscan to verify at download/checkout time. 2.1: Syntax in watch files to locate signature files. 2.2: Path in source packages / watch files to declare trusted signers. 2.3: Syntax in watch files for signature verification in git mode. 3. Support in dpkg-source to include detached signatures in source packages. 3.1: Declare expected formats and filename extensions. 4. Support in the archive? (Is anything necessary?) Is this something people are interested in pursuing? For sigstore, we probably need to package the Python / go client in Debian. We have rekor-cli for low-level verification, but not tools for verifying bundles like the ones Python provides. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Alternative signature mechanisms for upstream source verification
* Stefano Rivera: " Alternative signature mechanisms for upstream source verification" (Fri, 4 Oct 2024 18:21:01 +): [...] > Should we expand this to include some of these new mechanisms? > Things brought up in the debian-python thread include: > 1. sigstore https://docs.sigstore.dev/ > 2. ssh signatures > 3. signify https://man.openbsd.org/signify.1 JFTR: Tryton moved from pgp signatures to signify, so of course I would appreciate if this format could be handled as well. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Re: Alternative signature mechanisms for upstream source verification
Hi Guillem (2024.10.05_01:32:45_+) > > 1. sigstore https://docs.sigstore.dev/ > > Although I've heard of this before, I never really checked what is > the actual design behind it, and its implications. I'm new to all this too, but I can answer some of those questions from my own reading: > I'm not sure how reliant on centralization this is, or on the apparent > specific OIDC providers currently in use The signing process is reliant on centralization. The signature scheme trusts the central server and OIDC provider to identify the signer. It signs that assertion and stores it in a CT log. > about offline operations Verification is possible offline, the bundle includes CT proof. The downside of verifying offline is that you can miss revocation. > and whether that is a first class use, or if that implies limitations, > etc. There are definitely limitations. The set of trusted parties is much larger than when verifying an OpenPGP signature. Instead of relying on the signer maintaining perfect security of their OpenPGP keys, we are relying on the security of their OIDC server & sigstore. Signatures are publicly auditable, so fraudulent signatures are theoretically detectable by the identity owner. There are revocation mechanisms. A system like this has a chance of being widely adopted in software ecosystems in a way that I don't think OpenPGP has any more. > Even though in the Python upstream thread it's mentioned that many > upstreams are moving into using it, it's not clear to me either what > are the long-term prospects of this either. Yep. Hard to say. We can sit on the fence until it becomes obvious. This is how we often do things :) In the meantime, packages like Python may drop OpenPGP in favor of it. That may be a small loss. We weren't even verifying Python's OpenPGP signatures until yesterday. > I've not checked either what is the format of the certificates and > signatures for this, how detectable they are, their size, etc. The bundle format (capable of offline use) is a JSON document with a mediaType key. It's detectable. > From Python upstream and your comment below, I take the only > implementations are either Python or Golang, which seems problematic as > something to have to pull into say a build-essential chroots by default. > (Not to mention that these are not even yet in Debian. :) We can take a slower approach and not include support in build-essential chroots for these newer schemes. Re-evaluate later, if one of them really blows up in popularity. And of course, we should probably just start with uscan, and talk about adding support to dpkg later, when we can see significant use. > > 2. ssh signatures > > AFAIK these are used via ssh-keygen. The signatures are pretty easy to > detect, as they are surrounded by «-BEGIN SSH SIGNATURE-» and > «-END SSH SIGNATURE-» and are ASCII encoded. The certificates > and signatures can be few lines or many lines, but should be > relatively small, probably similar to at most an OpenPGP one. I think > depending on the format the certificates can also be easily detectable. > > I'm not sure I'd be comfortable with having to depend (even weakly) on > openssh-client to be able to work with these. At least the implementation > is portable C so it should be available everywhere, so in theory such > (weak?) dependency would be possible everywhere. I'm not sure how you'd > automatically verify signatures if you need to specify the namespace, > the allowed signers and the signer identity, I guess you'd probably > need to store this alongside as well. And the ssh-keygen CLI seems > rather brittle. :/ > > Is this really being used widely, or much at all? I know it's used in some git tag signing. See: #1023140 Those aren't relevant to dpkg, at all (without git source packages). > > I see supporting them in Debian requiring: > > 1. Decisions on which schemes to support. I'd assume we support all that > >are available in Debian and have some significant use. > > I think that just like some compression formats that might be deemed > not worth the effort, to me this could look similar. > > I also think even then, we could decide that we do not want full > support for all of these, but perhaps still partial support might be > good enough for now. Say shipping the signatures and certs somewhere > that requires no integration infra work, for example, or only > supporting them in say uscan. Yes, I think starting with uscan is the obvious way, but I would want to do so in a way that leaves the way open to support in dpkg later. Ideally without any source package API changes, later. Stefano
