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

[Guillem Jover]

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 interface to some common baseline
> OpenPGP semantics -- in particular, the "Stateless OpenPGP" interface,
> or "sop", as documented here:
> 
>https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/

> If your part of Debian's infrastructure depends on GnuPG, consider
> making it depend on a sop implementation instead, so we don't end up
> stuck on a single OpenPGP implementation in the future.  If the sop
> semantics are insufficient for your purposes, please report your needs
> at https://gitlab.com/dkg/openpgp-stateless-cli !

I think this is the way to go, and to try to support that goal I
started a wiki page to track what might need to be switched:

https://gitlab.com/dkg/openpgp-stateless-cli/-/wikis/Stateless-OpenPGP-status

I listed there some potential issues I could come up with for such
migrations. Also at the time, something that felt like a soft blocker
was that the schism was not widely known, so having to give that full
context first for every contacted project seemed a bit awkward, which
now should be out of the way, and a reference to some of the published
articles should be enough.

Time and energy permitting, I'd like to start at least filing issues
for these projects, and ideally provide patches. Help with any of that
would be highly appreciated! Including how to best integrate SOP into
a distribution (I'll be updating one of the tickets for a potentially
better «alternatives» usage pattern).

Also if a project uses perl, and using the Dpkg::OpenPGP modules would
make sense there, please reach out so that we can see what might be
missing so that they can be stabilized to make them public interfaces.

Thanks,
Guillem

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

[Simon Richter]

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 installed".


The latter can only happen if there is also a "defaults" package that 
pulls in the metapackage we currently designate as default, and the 
"defaults" package must allow the dependency to be fulfilled by any of 
the choices. APT will prefer not to uninstall packages if it doesn't 
have to.


As a result, any user will stick to whatever was default when they 
installed the package, even if they have not explicitly expressed a 
preference, until that option is no longer available -- the same happens 
with the alternatives system only in manual mode, which is an explicit 
choice -- and when it happens, the alternatives system will explicitly 
tell the user that their choice is no longer available and the setting 
has reverted to automatic mode.


The only way to speed up a transition is to add an explicit hard 
dependency somewhere and override the user's choice -- which then adds 
an installation ordering constraint that might be the exact opposite of 
the order we want.


   Simon

Re: Reaction to potential PGP schism

[Steve McIntyre]

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 to use
>gnupg, gnupg is the first thing I would consider.
>
>I hated and still hate every single moment I spent having to interface
>with gnupg. The protocol to interact with it is custom, hydiosincratic,
>poorly documented, and very hard to speak correctly. When in the end I
>managed to make things work, I was always left with the feeling that
>there would still be a corner case that I missed, or that will be
>introduced in a future gnupg release, waiting to become a security issue
>in our infrastructure, despite having asked for peer review from
>appropriate people in Debian.
>
>New releases make things harder rather than easier. Now gnupg is a
>mini-ecosystem of security-critical daemons that need to be brought up
>and killed, that may time out or run partly off sync with configuration,
>which adds even more know-how to the amount require to survive as
>downstream consumer of that one single "API".

^^^ 100% on all of that.

Trying to drive gnupg with automation is *such* a hateful,
error-prone, *inconsistent* experience. Trying to do (what should be)
simple things is really hard and messy. Simply trying to identify keys
reliably is harder than it should be. Semantics of command lines
change from one version to the next.

>I've been wanting for literally decades something with language
>bindings, or with a protocol that is built on existing well-known
>standards, outputting data that I can parse with an existing and tested
>parser library, using I/O channels that I can manage using an existing
>and tested communication library.

Again 100% on this. Just like you, I've spent countless hours writing
code to parse GPG output because of this mess.

>I hate it every single time I need to use gnupg, but still I use it
>because I understand it's what Debian has been expecting me to use, so I
>add that requirement to the pile of historical quirks that geologically
>accrete in our community, which make our barrier of entry so stylishly
>high, and make us appear oh so fearfully smart.
>
>
>> # What Can Debian Do About This?
>> 
>> If you are implementing or maintaining an OpenPGP implementation in
>> debian, please consider encouraging upsteam to add a sop frontend, and
>> get it tested in the interop test suite!
>
>This. 
>
>I don't know if it should be sop or a protocol or a standard, but I'd
>like to see Debian clearly document its expectations on its crypto
>requirements, and stand behind it.
>
>I personally believe that we should depend, for our core security, on an
>interoperable standard with multiple implementations rather than a
>project that follows the hydiosincracies of a single isolated upstream.
>
>Whatever we do, though, I want that to be official. As things stand I'll
>keep suffering with gnupg until at a DebConf I'll have at least 5 people
>look at me wide-eyed and say "are you still using THAT? Everyone moved
>to THIS instead!"
>
>I'd like to ask for what mature OpenPGP implementations exist today,
>pick one I feel I can confidently control, and then when somebody comes
>and says "my gpg/$TOOL segfaults on your input", I want to be able to
>point them at a documented decision and say "please report a bug to
>$TOOL" instead of taking a week off to port everything again to gpg.
>
>Thank you for all the work you've done on this over the years! I've
>appreciated it with great gratitude and a big hope that some day, thanks
>to you and others like you, those >=5 people at a DebConf will really
>look at me wide-eyed and show me a way out of the pit.

*grin* I look forwards to it!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

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

[Luca Boccassi]

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, and if you have issues
> > downloading a 3 kilobytes metapackage then just ensure the cache is
> > never cleared.
>
> More metapackages will make transitions harder though, I believe we want
> to avoid that.

In what way would transitions become harder?

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

[Simon Richter]

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 ensure the cache is
never cleared.


More metapackages will make transitions harder though, I believe we want 
to avoid that.


   Simon

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

[Hakan Bayındır]

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 in my previous message, many things from browsers to pagers are 
configured over alternatives subsystem, and this will create tons of headache 
over many edge cases. 

Lastly, a user may have sudo privileges for update-alternatives, to switch 
stuff around if things prove to be problematic (e.g.: again Java, compilers, 
etc.) without having package management privileges (e.g.: remotely managed 
developer workstation).

Alternatives work fine as-is. Fiddling with it only open more can of worms down 
the line. It’s there for a reason to begin with. 

Cheers,

H.
Sent from my iPhone

> On 27 Dec 2023, at 22:29, Luca Boccassi  wrote:
> 
> 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) are still free to install the
>> 
>> And if you want to change it, you have to download and install a new
>> package (and remove another) instead of using a local command
>> (update-alternatives) that doesn’t need an internet connection?
> 
> 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 ensure the cache is
> never cleared.
> 

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

[Luca Boccassi]

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) are still free to install the
>
> And if you want to change it, you have to download and install a new
> package (and remove another) instead of using a local command
> (update-alternatives) that doesn’t need an internet connection?

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 ensure the cache is
never cleared.

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

[Hakan Bayındır]

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 on.

Alternatives provides a very elegant and usable way for handling multiple 
installed applications. Yet it adds a bit of packaging overhead, but it’s not 
that complicated, and is one of the neat parts of Debian.

I think it’s fine as-is, and it’s an essential part of machinery for Debian. If 
there are some shortcomings, which I failed to bump into while working with it, 
it can be improved, but I’m very against of its removal.

Cheers, 

Hakan

> On 24 Dec 2023, at 12:06, Gioele Barabucci  wrote:
> 
> 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 allows for co-installability 
>> (and importantly - co-"buildability" with dependencies). the X-is-X 
>> guarantees essentially the opposite.
> 
> I don't see X-is-X as a different use case when it comes to applications: 
> both gnupg and sq-chameleon-gnupg could be installed at the same time.
> 
> 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 other 
> package and use /usr/bin/gpg-sq. The only Conflicts: here would be between 
> gpg-is-gnupg and gpg-is-sq-chameleon.
> 
> Regards,
> 
> -- 
> Gioele Barabucci
> 

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

[Stephan Seitz]

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, you have to download and install a new 
package (and remove another) instead of using a local command 
(update-alternatives) that doesn’t need an internet connection?


Sorry, this is bullshit. -100.

Stephan

--
|If your life was a horse, you'd have to shoot it.|

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

[Gioele Barabucci]

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 allows for 
co-installability (and importantly - co-"buildability" with 
dependencies). the X-is-X guarantees essentially the opposite.


I don't see X-is-X as a different use case when it comes to 
applications: both gnupg and sq-chameleon-gnupg could be installed at 
the same time.


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 
other package and use /usr/bin/gpg-sq. The only Conflicts: here would be 
between gpg-is-gnupg and gpg-is-sq-chameleon.


Regards,

--
Gioele Barabucci

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

[Alastair McKinstry]

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 the
"chameleon", i would want to see some significant archive-wide testing
done before we even consider inflicting that on our normal users.


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 allows for 
co-installability (and importantly - co-"buildability" with 
dependencies). the X-is-X guarantees essentially the opposite.


This becomes key if we have two different approaches desired or needed 
simultaneously: eg the adios parallel I/O library builds for both 
openmpi and mpich variants of MPI; different variants preferred for 
different architectures.


Regards

Alastair McKinstry




--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie

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

[Luca Boccassi]

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 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.
>
> 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 /usr/bin/gpg-gnupg, while
> sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the
> user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the
> distro-wide preference expressed setting the appropriate Recommends in
> gnupg or sequoia-chameleon-gnupg).
>
> Regards,

Yes, that would be very nice, all those moving parts make the
installation/upgrade processes so unnecessarily difficult and error
prone. It's a maintenance nightmare that I'd be very happy to stop
having to deal with anymore.

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

[Joerg Jaspert]

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 /usr/bin/gpg-gnupg, while 
sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the 
user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the 
distro-wide preference expressed setting the appropriate Recommends in 
gnupg or sequoia-chameleon-gnupg).


Ugh no, and have tons of near-empty packages for no good reason and also 
make local admins life harder.


--
bye, Joerg

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

[Gioele Barabucci]

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 significant archive-wide testing
done before we even consider inflicting that on our normal users.


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 /usr/bin/gpg-gnupg, while 
sequoia-chameleon-gnupg will ship its gpg as /usr/bin/gpg-sq. Then the 
user can decide to install gpg-is-gnupg or gpg-is-sequoia (with the 
distro-wide preference expressed setting the appropriate Recommends in 
gnupg or sequoia-chameleon-gnupg).


Regards,

--
Gioele Barabucci

Re: Reaction to potential PGP schism

[Cyril Brulebois]

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 second thought, and get GPG to work out of the box on it…

Daniel Kahn Gillmor  (2023-12-20):
> OpenPGP implementations have generally learned from those failures, and
> many of them are now much more resilient and can support the kinds of
> upgrade path that we need to consider.  For most of our
> signing/verifying-focused work, that means:
> 
>  - verifying tools should ignore signatures and certificates that they
>don't understand, while still validating signatures from certificates
>that they do understand
> 
>  - signing tools can make pairs of signatures, one "compatibility"
>signature and one "modern" signature
> 
> This means that for a debian signing/verification context, like package
> distribution, which has a global workflow, starting from an existing
> OpenPGP implementation, signing key and corresponding verification
> certificate, it looks like:
> 
>  0) upgrade the signing tool, and start upgrading some of the
>  verification tooling.
> 
>  1) create a new signing certificate with the new version, algorithm, or 
> feature.
> 
>  2) distribute the old+new certificates for the verifiers.
> 
>  3) make signatures with old+new in parallel
> 
>  4) complete upgrade of all verification tooling
> 
>  5) stop making signatures with old signing certificates

… what does this mean for anything that involves hardware-backed crypto?
I'm thinking Yubikeys and the like, but also HSMs that might be on the
critical path to sign things like GRUB, linux (at least for now), etc.

Even if we end up with a brand new gnupg release on the relevant signing
host(s), I fear hardware devices might not feature all the bits that are
needed for those new features?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Reaction to potential PGP schism

[Daniel Kahn Gillmor]

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

[Stephan Verbücheln]

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
signatures such as developer communication and maintainer uploads. PGP
is really handy because once trust of the key fingerprint for a person
is established, the person can easily make changes such as adding
subkeys, editing the expiration date, revoking keys, etc. at any time.

This would also be less convenient with a CMS-PKI-CA-hierarchy based
system.

Regards
Stephan


signature.asc
Description: This is a digitally signed message part

Re: Reaction to potential PGP schism

[Enrico Zini]

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 out how to get GnuPG to (probably,
> hopefully!) fulfill a cryptographic task in their project.  Once that is
> done, it's especially painful to consider moving to a different OpenPGP
> implementation, because the interface to another implementation rarely
> lines up cleanly with GnuPG's interface.

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 to use
gnupg, gnupg is the first thing I would consider.

I hated and still hate every single moment I spent having to interface
with gnupg. The protocol to interact with it is custom, hydiosincratic,
poorly documented, and very hard to speak correctly. When in the end I
managed to make things work, I was always left with the feeling that
there would still be a corner case that I missed, or that will be
introduced in a future gnupg release, waiting to become a security issue
in our infrastructure, despite having asked for peer review from
appropriate people in Debian.

New releases make things harder rather than easier. Now gnupg is a
mini-ecosystem of security-critical daemons that need to be brought up
and killed, that may time out or run partly off sync with configuration,
which adds even more know-how to the amount require to survive as
downstream consumer of that one single "API".

I've been wanting for literally decades something with language
bindings, or with a protocol that is built on existing well-known
standards, outputting data that I can parse with an existing and tested
parser library, using I/O channels that I can manage using an existing
and tested communication library.

I hate it every single time I need to use gnupg, but still I use it
because I understand it's what Debian has been expecting me to use, so I
add that requirement to the pile of historical quirks that geologically
accrete in our community, which make our barrier of entry so stylishly
high, and make us appear oh so fearfully smart.


> # What Can Debian Do About This?
> 
> If you are implementing or maintaining an OpenPGP implementation in
> debian, please consider encouraging upsteam to add a sop frontend, and
> get it tested in the interop test suite!

This. 

I don't know if it should be sop or a protocol or a standard, but I'd
like to see Debian clearly document its expectations on its crypto
requirements, and stand behind it.

I personally believe that we should depend, for our core security, on an
interoperable standard with multiple implementations rather than a
project that follows the hydiosincracies of a single isolated upstream.

Whatever we do, though, I want that to be official. As things stand I'll
keep suffering with gnupg until at a DebConf I'll have at least 5 people
look at me wide-eyed and say "are you still using THAT? Everyone moved
to THIS instead!"

I'd like to ask for what mature OpenPGP implementations exist today,
pick one I feel I can confidently control, and then when somebody comes
and says "my gpg/$TOOL segfaults on your input", I want to be able to
point them at a documented decision and say "please report a bug to
$TOOL" instead of taking a week off to port everything again to gpg.

Thank you for all the work you've done on this over the years! I've
appreciated it with great gratitude and a big hope that some day, thanks
to you and others like you, those >=5 people at a DebConf will really
look at me wide-eyed and show me a way out of the pit.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Reaction to potential PGP schism

[Gioele Barabucci]

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 "sop", as documented here:

https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/


Hi, thanks for the detailed overview.

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


Regards,

[1] https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg not yet in 
Debian AFAIK


--
Gioele Barabucci

Re: Reaction to potential PGP schism

[Meso Security]

   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 engage with> well-documented, community-reviewed, interoperably-tested standards, and> the implementations that try to follow them.  From my vantage point,> that looks like the OpenPGP projects that have continued to actively> engage in the IETF process, and have put in work to improve their> interoperability on the most sophisticated suite of OpenPGP tests that> we have (https://tests.sequoia-pgp.org/, maintained by the Sequoia> project for the community's benefit).  Projects that work in that way> are also likely to benefit from smoother upgrades to upcoming work in> the IETF like post-quantum cryptographic schemes:>> https://datatracker.ietf.org/doc/draft-wussler-openpgp-pqc/There was a presentation at the recent MiniDebconf in Cambridge aboutpost-quantum cryptography, including the consequences for Debian (thatwas by Andy Simpkins):https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/SimpkinsThe key point AIUI is Debian must take precautions *very* *soon* asthere's a realistic chance QC will - within the lifetime of trixie -evolve to a point where it seriously weakens the cryptographic securityas we know it. In other words, Debian must prepare for PQC within thetrixie development cycle, so within 2024.Therefore, my answer to "How can Debian deal with this [schism]?" isbasically: Debian needs to change things in that area anyway, let'sfirst find an implementation that provides what we need and has a saneimplementation. If that means turning away from GnuPG, so be it. Thetransition will be painful anyway.Christoph




publicKey - MesoSecurity@protonmail.ch - 0xA98C9ECA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Reaction to potential PGP schism

[Christoph Biedl]

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 them.  From my vantage point,
> that looks like the OpenPGP projects that have continued to actively
> engage in the IETF process, and have put in work to improve their
> interoperability on the most sophisticated suite of OpenPGP tests that
> we have (https://tests.sequoia-pgp.org/, maintained by the Sequoia
> project for the community's benefit).  Projects that work in that way
> are also likely to benefit from smoother upgrades to upcoming work in
> the IETF like post-quantum cryptographic schemes:
>
> https://datatracker.ietf.org/doc/draft-wussler-openpgp-pqc/

There was a presentation at the recent MiniDebconf in Cambridge about
post-quantum cryptography, including the consequences for Debian (that
was by Andy Simpkins):

https://wiki.debian.org/DebianEvents/gb/2023/MiniDebConfCambridge/Simpkins

The key point AIUI is Debian must take precautions *very* *soon* as
there's a realistic chance QC will - within the lifetime of trixie -
evolve to a point where it seriously weakens the cryptographic security
as we know it. In other words, Debian must prepare for PQC within the
trixie development cycle, so within 2024.

Therefore, my answer to "How can Debian deal with this [schism]?" is
basically: Debian needs to change things in that area anyway, let's
first find an implementation that provides what we need and has a sane
implementation. If that means turning away from GnuPG, so be it. The
transition will be painful anyway.

Christoph


signature.asc
Description: PGP signature

Re: Reaction to potential PGP schism

[Daniel Kahn Gillmor]

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: Reaction to potential PGP schism

[Marc Haber]

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) a new thing, if that appears better. 

In summary, this is bad news for the security of people, since there
will be ANOTHER competing and incompatible standard which will make
finding a basis for communication significantly harder, raising the
bar for a beginner even higher than it is already today.

Sad Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Reaction to potential PGP schism

[Joerg Jaspert]

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 for that.[1]


Individuals, including Debian developers, are - of course - free to jump 
in and take part in this.


[1] not counting the usage/scriptability of gnupg, that bar is somewhere 
down DEEEP in the earth, its so horrible.


--
bye, Joerg

Re: Reaction to potential PGP schism

[Pierre-Elliott Bécue]

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, including:
> - developer communication
> - signing of tarballs and patches
> - automated processes such as update validation by APT
>
> The OpenPGP Working Group at IETF is currently working on a new
> standard.
>
> https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/
>
> Due to different opinions, some people (including notably the GnuPG
> team) have quit the IETF Working Group and proposed their own LibrePGP
> standard.
>
> https://librepgp.org/
>
> Notably remaining in the IETF Working Group are people from Proton Mail
> (maintaining OpenPGP.JS) and Sequoia PGP (free implementation in Rust).
>
> The disagreements are about details such as algorithms and file formats
> which make both standards incompatible.
>
> How can Debian deal with this?

By doing nothing.

> Should Debian intervene to prevent the worst?

No.

-- 
PEB


signature.asc
Description: PGP signature

Reaction to potential PGP schism

[Stephan Verbücheln]

Hello everyone

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

The OpenPGP Working Group at IETF is currently working on a new
standard.

https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/

Due to different opinions, some people (including notably the GnuPG
team) have quit the IETF Working Group and proposed their own LibrePGP
standard.

https://librepgp.org/

Notably remaining in the IETF Working Group are people from Proton Mail
(maintaining OpenPGP.JS) and Sequoia PGP (free implementation in Rust).

The disagreements are about details such as algorithms and file formats
which make both standards incompatible.

How can Debian deal with this? Should Debian intervene to prevent the
worst?

Regards
Stephan



signature.asc
Description: This is a digitally signed message part