Re: Reaction to potential PGP schism
Hi Gioele-- On Thu 2023-12-21 11:02:06 +0100, Gioele Barabucci wrote: > On 21/12/23 04:16, Daniel Kahn Gillmor wrote: > As the Uploader of rust-sequoia-openpgp, what do you think of the > related sequoia-chameleon-gnupg project [1] (drop-in replacement for gpg > that uses sequoia internally)? > > Would it work as a stop-gap measure while the Debian infrastructure > moves from GnuPG to something else (to `sop`, for instance)? > > [1] https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg not yet in > Debian AFAIK Thanks for pointing this out! It looks interesting, but i've never used it (or even tested it) myself. I don't think it can be a completely perfect, feature-for-feature replacement for GnuPG, given the overwhelming complexity and peculiarity of the GnuPG interface, but I imagine it would work for some people, for some purposes. I certainly wouldn't object to anyone packaging it for debian as long as it ships its binary interface someplace other than /usr/bin/gpg. Modulo dealing with the rust dependencies, that seems like an obviously reasonable and straightforward thing to try to do. I don't know how the "chameleon" would compare with GnuPG itself in terms of performance or some of the scaling concerns i mentioned in my earlier e-mail, but such a straightforward deployment should make it easy to test. If you're asking about using /etc/alternatives or something like that to provide some sort of generic swapping capability, or a dpkg Provides:, such that /usr/bin/gpg on some systems would point toward the "chameleon", i would want to see some significant archive-wide testing done before we even consider inflicting that on our normal users. This would be the kind of thing that the experimental archive is designed for. One of the ongoing challenges with GnuPG development is the fear of dropping or mis-handling some feature or flag or option or configuration that someone has stuffed into some script somewhere and completely forgotten about. GnuPG itself deals with this kind of problem regularly, and sometimes things like this do break during an upgrade. Clawing the way back from such a break actually ends up making the interface even more complex and surprising to those people who haven't seen how it accreted in the first place :/ It was scary enough to change /usr/bin/gpg to move from the 1.4 branch to the 2.x branch many years ago (we shipped the 2.0 branch as /usr/bin/gpg2, and only finally made /usr/bin/gpg update when the 2.1.x branch was sufficiently mature). And even thenm we dealt with the fallout from that change for years (e.g. see /usr/bin/migrate-pubring-from-classic-gpg in the gnupg-utils package). The differences were enough that I resisted using /etc/alternatives to let each installation decide which package offered /usr/bin/gpg1, because of the dangerous side effects of switching back and forth (see #806904 for example, and the conversations at DebConf14). I can only imagine that trying to ship the "chameleon" as /usr/bin/gpg would face some of the same challenges, probably even more severely. At best, something like this would be a stop-gap, as you say. i wouldn't want the long-term health of *PGP functionality in debian to depend specifically on the command-line interface for /usr/bin/gpg, regardless of who is implementing it. Even GnuPG upstream appears to agree with this sentiment, as they encourage programmatic users of GnuPG to use libgpgme, which is supposed to hide some of the command-line complexity. --dkg signature.asc Description: PGP signature
Re: Reaction to potential PGP schism
hey folks-- [ This message won't make sense unless the reader distinguishes clearly between OpenPGP the protocol and GnuPG the implementation! As a community we have a history of fuzzily conflating the two terms, which is one of the reasons that we're in this mess today. Please read explicitly. ] [ Background: for those who don't know, i've been a maintainer in debian of GnuPG and other OpenPGP-related tooling for several years, and i'm also the co-chair of the IETF's OpenPGP working group; i participated in many of the discussions that led to the current sorry situation, and it is happening despite my best efforts to avoid this problem. I'm probably as responsible for this situation as anyone in Debian is. My apologies. ] The best outcome, in my opinion, would be for GnuPG to go ahead and implement the pending updated OpenPGP specification (the so-called "crypto-refresh"). I say this despite personally preferring some of the concrete ways that i think the GnuPG project would have preferred to (as indicated by the latest "LibrePGP" Internet-Draft, at least) diverge from the OpenPGP specification. There are enough other advantages to the OpenPGP crypto-refresh that it doesn't make sense for GnuPG to deliberately avoid implementing the community consensus. The GnuPG project clearly has all the underlying cryptographic and engineering capability to do this, if it wants to, and the OpenPGP crypto-refresh process took deliberate measures to avoid collisions with any prematurely deployed code that implements a draft that hadn't managed to reach a rough consensus. Can debian make GnuPG interoperate with the rest of the OpenPGP ecosystem? Probably not without GnuPG's cooperation: it would be a substantial patchset to carry in Debian, and even trickier to do if GnuPG upstream sees such a patchset as hostile. Read on below if you want to consider some other options. Stephan Verbücheln wrote: > As you probably know, Debian relies heavily on GnuPG for various > purposes, including: > - developer communication > - signing of tarballs and patches > - automated processes such as update validation by APT Debian by policy and by mechanism relies heavily on the OpenPGP protocol for these things. And i'd also add certificate verification, aka "web of trust" for Debian developer identities to the list as well. In particular, we use OpenPGP for cryptographic signing of software source, packaging information, archive control, and distribution mechanisms; for developer identities; and for cryptographic verification of all of these things. As a project, we don't make much use of the encryption/decryption parts of OpenPGP, since we develop mainly in the open. But not everyone uses GnuPG for these purposes. There are multiple interoperable OpenPGP implementations in Debian beyond the GnuPG family (C), including RNP (C/C++), pgpainless (java), pgpy (Python), GOpenPGP (Go), hOpenPGP (haskell), and Sequoia (Rust). But it is also true that the GnuPG implementation specifically is baked into some of our infrastructure. I'll get into why that is below (see "Why is GnuPG on Debian's Critical Path?"). > How can Debian deal with this? Should Debian intervene to prevent the > worst? I don't think Debian can make a specific intervention that will avoid the global problem, but i think there are things we can consider going forward. One possible approach is to drop the use of OpenPGP (or "LibrePGP") entirely, and instead base our internal cryptographic dependencies on bespoke cryptographic implementations. I think that would be a mistake. I do not want Debian's long-term health to depend on any particular implementation. If the implementation fails then we would have to (as a project) decide on our own upgrade path. For a failure due to cryptanalytic advances, that can be particularly harrowing: I don't think we as a project have the necessary expertise to do that well. For failures due to buggy implementations, we can always patch, but i wonder about the amount of cryptanalytic review a bespoke implementation will have as opposed to publicly audited generic tooling. If we have to decide as a project on LibrePGP vs. OpenPGP, i'd prefer the wider community project with a stable reference, functioning (albeit sometimes rough) consensus, a range of diverse implementations, and substantial public interoperability testing. That means OpenPGP. To be clear, the IETF OpenPGP working group actively solicited input from the GnuPG team, and tried to work with the project as one significant implementation among many. But ultimately, the GnuPG project decided to break away from the community process, and created this "LibrePGP" split, which threatens interoperability for the *PGP ecosystem as a whole. Maybe the end result of this will be to put a nail in *PGP's coffin, and we'll all just go back to bespoke cryptographic implementations that have no stable reference other than the source code, and little
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
On 09/22/2014 04:07 AM, Elmar Stellnberger wrote: Am 22.09.14 um 01:52 schrieb Paul Wise: The Debian archive does not allow files to change their checksum, so every signature addition requires a new version number. That sounds like a bad idea to me. Yes, that is something we definitely do not want. Nonetheless it would still be an issue to have the package and the signatures in one file because we usually need them together. My only idea to realize this in spite of the said objection would be another proposal: Put the .deb and the signatures into one .ar called .sdeb and make tools like dpkg work on .sdebs or on .deb + signatures respecively. Whenever someone offers some packages for download that will be in the form of .sdebs while official debian repositories may separate both kinds of files. User interfaces like http://debtags.debian.net/search/ could then generate .sdebs on the fly to satisfy petted users. This is almost exactly what i proposed a couple days ago on the reproducible-builds mailing list [0], except that i used the extension .debs instead of .sdeb :) --dkg [0] http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20140915/000432.html signature.asc Description: OpenPGP digital signature
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
On 09/21/2014 02:04 PM, Elmar Stellnberger wrote: a well programmed dpkg-cmp. ... and as long as the tool should not be available simply un-ar and compare the data.tar.gz-s. fwiw, this suggestion fails to compare the contents of control.tar.gz, which includes the maintainer scripts (preinst, postinst, etc). If someone wanted to damage your system with a modified package, modified preinst and postinst scripts would be much more effective (they run as root, automatically upon package installation!) than just tweaking a given binary. i just wanted to point out that this theoretical dpkg-cmp is at least slightly more complex than the above suggestion makes it out to be. And of course there are many other tools already that use plain old cmp or digest comparisons against .deb packages already, and thinking about how to interoperate with existing infrastructure is important. --dkg signature.asc Description: OpenPGP digital signature
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
On 09/19/2014 06:07 AM, Elmar Stellnberger wrote: Isn`t there really any way to include the signatures in the header of the .deb files? Why not simply add multiple signature files in the control.tar.gz of a .deb just next to the md5sums which should in deed be a sha256sums (otherwise there is no way to establish a 'chain of trust'). That would not add any non-determinism because if it is done right then we can have all the signers in the package! If we succeed in creating reproducible builds (we're farther along toward that goal than i had dared hope, it's exciting!) then one of the nice opportunites we have is for other people or organizations to corroborate the build after the package is first distributed. For example, an upload to sid might have one signature (by the original uploader), but maybe it waits to transition to testing until there are corroborations from multiple builders. (Note: this is not a concrete proposal or an expectation of exactly what will happen, just a thought experiment) In this scenario, how do you propose to add those signatures into the package? If we bundle them into the .deb, then the size and digest of the .deb itself changes after it is first distributed. This seems like it would violate all sorts of existing expectations -- i can't imagine how many different tools and pieces of infrastructure expect that foo_1.2-3_mipsel.deb should always have the same size and digest. It would be far better than detaching the signatures from the package because the general use case where you need package signatures is the manual download of packages. Detached signatures are completely useless for such a use case! I don't think this is the case. People who download a .deb and verify it could also download the associated .buildinfo file and whichever signatures they'd like (or all of them) and verify the package that way. --dkg signature.asc Description: OpenPGP digital signature
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
On 09/19/2014 12:34 AM, Paul Wise wrote: On Fri, Sep 19, 2014 at 9:30 AM, Hans-Christoph Steiner wrote: Finally did this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762153 Please note that you proposal to add signatures to .deb files will break reproducible builds because the hash of the .deb will differ depending on who signed it: https://wiki.debian.org/ReproducibleBuilds I think it would be far better to ship detached signatures in the archive since that allows for reproducible builds and also means there could be more than one signer (say one buildd, one Debian sponsor and one package maintainer). I agree with pabs on this. fwiw, i'm also hoping that we can ship at least one other signature for the upstream tarball (where such a thing exists): https://bugs.debian.org/759478 We also had a discussion in the reproducible-builds BoF at DC14 about how to deal with signatures on .buildinfo files, and came to the same conclusion: that a .buildinfo file should have detached signatures, to allow for multiple (corroborative) signers: https://wiki.debian.org/ReproducibleBuilds#A.buildinfo_signatures Note that a signature over a .buildinfo file should effectively cover the digest of the built .deb files, which should creates a strong cryptographic chain if you trust the hash function. Given that we would ultimately like one or more signed .buildinfo files shipped in the archive, and that they represent a way to have an builder's signature over a .deb, i think these make the idea of an internally-signed .deb redundant. Thanks to everyone who is thinking about and working on improving the cryptographic integrity of the archive! --dkg signature.asc Description: OpenPGP digital signature
Re: [SECURITY] [DSA-2010-1] New kvm packages fix several vulnerabilities
Hi Debian Security folks-- On 03/10/2010 01:18 PM, dann frazier wrote: Debian Security Advisory DSA-2010 secur...@debian.org http://www.debian.org/security/ Dann Frazier March 10, 2010 http://www.debian.org/security/faq Package: kvm Vulnerability : privilege escalation/denial of service Problem type : local Debian-specific: no CVE Id(s) : CVE-2010-0298 CVE-2010-0306 CVE-2010-0309 CVE-2010-0419 Several local vulnerabilities have been discovered in kvm, a full virtualization system. The Common Vulnerabilities and Exposures project identifies the following problems: CVE-2010-0298 CVE-2010-0306 Gleb Natapov discovered issues in the KVM subsystem where missing permission checks (CPL/IOPL) permit a user in a guest system to denial of service a guest (system crash) or gain escalated privileges with the guest. CVE-2010-0309 Marcelo Tosatti fixed an issue in the PIT emulation code in the KVM subsystem that allows privileged users in a guest domain to cause a denial of service (crash) of the host system. CVE-2010-0419 Paolo Bonzini found a bug in KVM that can be used to bypass proper permission checking while loading segment selectors. This potentially allows privileged guest users to execute privileged instructions on the host system. For the stable distribution (lenny), this problem has been fixed in version 72+dfsg-5~lenny5. For the testing distribution (squeeze), and the unstable distribution (sid), these problems will be addressed within the linux-2.6 package. We recommend that you upgrade your kvm package. Upgrade instructions wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. It's not clear to me from the instructions above whether users should re-build their kvm modules package as well as installing the revised versions. Is the vulnerability fully-resolved by simply upgrading the kvm package? (i really don't know, and figure y'all are the right folks to ask). I note that there are kvm modules shipped with the default stable kernel. If more steps are needed, maybe we need additional DSA boilerplate for these kind of announcements in the future. Thanks for all the work you do to keep debian in good shape. it's very much appreciated! --dkg signature.asc Description: OpenPGP digital signature
Re: [SECURITY] [DSA-2010-1] New kvm packages fix several vulnerabilities
On 03/10/2010 02:49 PM, dann frazier wrote: On Wed, Mar 10, 2010 at 02:18:38PM -0500, Daniel Kahn Gillmor wrote: It's not clear to me from the instructions above whether users should re-build their kvm modules package as well as installing the revised versions. Is the vulnerability fully-resolved by simply upgrading the kvm package? (i really don't know, and figure y'all are the right folks to ask). If you've never built/installed modules from the kvm-source package, this advisory does not apply to you. If you have - you will need to update your kernel-source package and rebuild/reload those modules. So i have a lenny system, running 2.6.26-2-amd64. When it was running 2.6.26-1-amd64, i built and installed modules from the kvm_source. but when i upgraded to 2.6.26-2-amd64, i didn't bother to build new modules, and just went with the kvm modules shipped in the stock linux-image-2.6.26-2-amd64 package. A literal reading of your response above makes me think i need to do rebuild for that system, but if i'm actually understanding you, it sounds like i *don't* need to do a module rebuild. argh. sorry if this line of questioning is annoying or frustrating. i'm not trying to be obnoxious or pedantic, i'm trying to make sure i actually understand the issue. I note that there are kvm modules shipped with the default stable kernel. Yes, these issues are being tracked there as well (3/4 are already fixed in the latest stable update) Nice, thanks for the info. So would the 4th be fixed if i went ahead and rebuilt from the kvm_source package referenced by DSA-2010-1? Regards, --dkg signature.asc Description: OpenPGP digital signature
[Fwd: Re: [SECURITY] [DSA-2010-1] New kvm packages fix several vulnerabilities]
sorry, this proposed boilerplate change was meant to go to the list, not just to dann. Thanks for all your work, folks. --dkg ---BeginMessage--- On 03/10/2010 04:53 PM, dann frazier wrote: On Wed, Mar 10, 2010 at 04:09:48PM -0500, Daniel Kahn Gillmor wrote: So would the 4th be fixed if i went ahead and rebuilt from the kvm_source package referenced by DSA-2010-1? Yes. Thank you for your prompt explanations, and for your patience, dann. I think i understand the situation now. Here is proposed boilerplate for future notices like this about kvm: Where it used to say: We recommend that you upgrade your kvm package. It could say: We recommend that you upgrade your kvm package. If your system is currently using a kvm-modules package built from previous versions of the kvm-source package, we recommend that you upgrade your kvm-source package, re-build a new kvm-modules package and install it. You should subsequently unload the old kvm modules from your kernel and reload the newly built kernel modules. The simplest way to accomplish this kernel module unload/reload is a system restart. Feel free to edit it as you see fit, of course. Regards, --dkg signature.asc Description: OpenPGP digital signature ---End Message--- signature.asc Description: OpenPGP digital signature
