Hi Sébastien-- On Thu 2024-08-08 00:53:04 +0200, Sébastien Noel wrote:
> Thank you very much again for taking the time to respond to my offensive > email that i'm not proud of :/ I appreciate your retraction of the offensive parts of your message. I understand the frustration (i've been in your shoes myself), and i hope we can figure out how to collaborate. > I am in no position to have done any security analysis of any GnuPG > component. > But I am the kind of person that trust upstream devs. So if GnuPG offers > a binary that browsers can use IF they clear the way by providing a file > with some kind of UID to identify extensions that are permitted to use > it, i'm the kind of person that will blindly trust the system. > Call me naive but that's who i am. I get it, and i think we're all scattered along a spectrum to some extent. No downstream packager or redistributor is going to understand any piece of software as well as its upstream authors. But this is not a black-and-white situation. As packagers, we still have an obligation to attempt some analysis along these lines, however faulty or limited it might be. For example, when a security issue is reported (this *will* happen, for sensitive software like GnuPG), as packagers we need to be able to understand the security issue, its proposed fixes or workarounds, and how those changes might affect other parts of the tooling. If we offer packaging without even a first attempt at understanding the problem space, we're merely putting off starting the kind of analysis that we'll be forced to engage in eventually. And we're passing the buck to our own downstreams -- our direct users and the users of derivative distros that depend on debian's vetting and maintenance processes. I think we have an obligation to try to be more responsible than that. > The goal is to allows Mailvelope to talk to secret key material. > Only Mailvelope. Thanks, this is a useful scope for this work; it would probably be useful to have some Mailvelope developers commenting on this thread if that's the end goal here, if they're interested in this kind of support on Debian and related systems. > And i want to emphase that it *talks* to secret key material, it doesn't > have access to it (secrets keys still doesn't leave the > opengpgcard/yubikey/whatever-hardware-you-have) I'm not particularly motivated by this distinction, fwiw, though i used to be more excited by it. I currently see this kind of argument (prioritizing defenses against "kleptography" as it were) as a sort of cryptographic fetishism -- the confidentiality and authenticity that we care about is confidentiality and authenticity *of the material we're communicating*. That's not to say that i want to leave secret key material unguarded. I do understand the motivation to defend it. But i think emphasizing "doesn't have access to the secret key material" fundamentally misunderstands the priorities of cryptographic communication, which is *to secure the communication*. "Mere" ability to *use* the key material still risks the truly sensitive stuff, which is the content. > except for the part where you ask for an analysis, i'm sure I can answer > to everything else. I will do that promptly. I hope we can work on the analysis part as well, there are several questions that i've asked on the MR. Perhaps we can address some of them, even if not all. I appreciate that some security analysis has been done by upstream already. Maybe there are pointers to that work that could be a useful start? I also note in https://mailvelope.com/en/faq#gnupg that mailvelope doesn't depend on GnuPG specifically -- by default it uses OpenPGP.js, but *may* communicate with GnuPG for the secret key material. If you're using Mailvelope, can you confirm that this is the case? Do you currently use it without GnuPG? Regards, --dkg
signature.asc
Description: PGP signature
