SOP migration (was Re: Reaction to potential PGP schism)

Hi! Daniel thanks for all your work on the OpenPGP working group, and on SOP! :) On Wed, 2023-12-20 at 22:16:28 -0500, Daniel Kahn Gillmor wrote: > # What Can Debian Do About This? > > I've attempted to chart one possible path out of part of this situation > by proposing a minimized, simplified

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

Hi, More metapackages will make transitions harder though, I believe we want to avoid that. In what way would transitions become harder? The alternatives system has "manual" and "automatic" modes for each group, these would probably correspond to "manually installed" and "automatically

Re: Reaction to potential PGP schism

Enrico Zini wrote: > >I maintain critical code that calls out to gnupg, in part because at the >time I wrote it that was the only thing available, and in part because >I'm supposed to offer the broadest possible compatibility with what >other people in Debian are using, so if everyone else seems

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

On Thu, 28 Dec 2023 at 03:01, Simon Richter wrote: > > Hi, > > On 12/28/23 04:28, Luca Boccassi wrote: > > > if you want to activate a new alternative, you have to download a new > > package that provides it anyway, so there's no difference. Subsequent > > switches will use the cached package,

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

Hi, On 12/28/23 04:28, Luca Boccassi wrote: if you want to activate a new alternative, you have to download a new package that provides it anyway, so there's no difference. Subsequent switches will use the cached package, and if you have issues downloading a 3 kilobytes metapackage then just

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

Metapackage approach is not the same for many reasons. First, I have seen Debian installations which doesn’t have internet access, but setup with many alternatives of the same application (e.g.: Java). Moreover, apt automatically purges its cache after a successful transaction. As I said

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

On Sun, 24 Dec 2023 at 22:48, Stephan Seitz wrote: > > Am So, Dez 24, 2023 at 10:06:09 +0100 schrieb Gioele Barabucci: > >After the installation there would be no /usr/bin/gpg. Once the user > >installs, say, ggp-is-gnupg then /usr/bin/gpg will point to > >/usr/bin/gpg-gnupg. Users (and scripts)

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

However, shoehorning X-is-X to apt for replacing alternatives is a very unoptimal (and even backwards) approach, because it’s not only for simple applications. Some of the daily alternatives I see are: - x-www-Browser - java (and the whole toolchain) - editor - vi - pager … The list goes on and

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

Am So, Dez 24, 2023 at 10:06:09 +0100 schrieb Gioele Barabucci: After the installation there would be no /usr/bin/gpg. Once the user installs, say, ggp-is-gnupg then /usr/bin/gpg will point to /usr/bin/gpg-gnupg. Users (and scripts) are still free to install the And if you want to change it,

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

On 24/12/23 08:54, Alastair McKinstry wrote: While we are on the topic of alternatives, I hope to see the maintscript-based /etc/alternatives paradigm deprecated in favor of the package-based X-is-X paradigm introduced by `python-is-python3`. They have different use-cases.  alternatives

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

On 23/12/2023 14:34, Gioele Barabucci wrote: On 22/12/23 00:40, Daniel Kahn Gillmor wrote: 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

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

On Sat, 23 Dec 2023 at 18:43, Gioele Barabucci wrote: > > On 22/12/23 00:40, Daniel Kahn Gillmor wrote: > > 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

Re: Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

On 17086 March 1977, Gioele Barabucci wrote: While we are on the topic of alternatives, I hope to see the maintscript-based /etc/alternatives paradigm deprecated in favor of the package-based X-is-X paradigm introduced by `python-is-python3`. In this scenario gnupg will ship gpg as

Deprecation of /etc/alternatives? (Re: Reaction to potential PGP schism)

On 22/12/23 00:40, Daniel Kahn Gillmor wrote: 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

Re: Reaction to potential PGP schism

Hi Daniel, Quick backstory: I stayed away from hardware crypto for a long while since there were so many incompatibilities, partial support, or side patches to get basic things to work. Over time, it seems it got to a point where it's mainstream enough that you can buy a Yubikey without much of a

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)? >

Re: Reaction to potential PGP schism

Interesting point in this talk: The APT team is already working on non- PGP signatures. https://wiki.debian.org/Teams/Apt/Spec/AptSign I can see the advantages of that for release signatures which use a rarely changing set of keys. However, I do not see any good alternative for PGP for personal

Re: Reaction to potential PGP schism

On Wed, Dec 20, 2023 at 10:16:28PM -0500, Daniel Kahn Gillmor wrote: > # Why is GnuPG on Debian's Critical Path? > > In 2023, I believe GnuPG is baked into our infrastructure largely due to > that project's idiosyncratic interface. It is challenging even for a > sophisticated engineer to figure

Re: Reaction to potential PGP schism

On 21/12/23 04:16, Daniel Kahn Gillmor wrote: # What Can Debian Do About This? I've attempted to chart one possible path out of part of this situation by proposing a minimized, simplified interface to some common baseline OpenPGP semantics -- in particular, the "Stateless OpenPGP" interface, or

Re: Reaction to potential PGP schism

Thank you very much  for your explanation  On Thu, Dec 21, 2023 at 2:13 AM, Christoph Biedl wrote: Daniel Kahn Gillmor wrote...(...)Thanks for your exhaustive description. I'd just like to point out onepoint:> In practice, i think it makes the most sense to

Re: Reaction to potential PGP schism

Daniel Kahn Gillmor wrote... (...) Thanks for your exhaustive description. I'd just like to point out one point: > In practice, i think it makes the most sense to engage with > well-documented, community-reviewed, interoperably-tested standards, and > the implementations that try to follow

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

Re: Reaction to potential PGP schism

On Thu, 14 Dec 2023 23:00:41 +0100, Joerg Jaspert wrote: >On 17077 March 1977, Stephan Verbücheln wrote: > >> How can Debian deal with this? Should Debian intervene to prevent the >> worst? > >We, as Debian, look and wait what comes out. And then *MAY* at some >point decide to add (or switch to)

Re: Reaction to potential PGP schism

On 17077 March 1977, Stephan Verbücheln wrote: How can Debian deal with this? Should Debian intervene to prevent the worst? We, as Debian, look and wait what comes out. And then *MAY* at some point decide to add (or switch to) a new thing, if that appears better. Also, it will be a high bar

Re: Reaction to potential PGP schism

Hi, Personal view here. Stephan Verbücheln wrote on 14/12/2023 at 11:29:17+0100: > [[PGP Signed Part:No public key for 603542590A3C7C62 created at > 2023-12-14T11:29:17+0100 using EDDSA]] > Hello everyone > > As you probably know, Debian relies heavily on GnuPG for various > purposes,