.woodpecker/doc-pages.yml

@@ -3,7 +3,7 @@
 
 steps:
   pages:
-    image: woodpeckerci/plugin-docker-buildx:6.0.2
+    image: woodpeckerci/plugin-docker-buildx
     settings:
       output: type=local,dest=public
       # do not push, push cannot be used with output simultaneously anyway
@@ -11,14 +11,10 @@ steps:
       # do not refresh image
       pull_image: false
       purge: false
-    when:
-      event: push
 
   pages-pr-preview:
     image: bitnami/git
-    environment:
-      CODEBERG_TOKEN:
-        from_secret: codeberg_token
+    secrets: [ codeberg_token ]
     commands:
       - git config --global user.email heiko.schaefer+boiler@posteo.de
       - git config --global user.name "Page Renderer"
@@ -39,9 +35,7 @@ steps:
 
   pages-publish:
     image: bitnami/git
-    environment:
-      CODEBERG_TOKEN:
-        from_secret: codeberg_token
+    secrets: [ codeberg_token ]
     commands:
       - git config --global user.email heiko.schaefer+boiler@posteo.de
       - git config --global user.name "Page Renderer"

README.md

@@ -11,7 +11,7 @@ The "Notes on OpenPGP" project aims to produce accessible documentation for the
 
 A book for application developers who want to integrate OpenPGP functionality into their software.
 
-This book serves as a standalone introduction to the concepts of OpenPGP. It also introduces readers to the [OpenPGP RFC 9580](https://www.rfc-editor.org/rfc/rfc9580.html).
+This book serves as a standalone introduction to the concepts of OpenPGP. It also introduces readers to the [OpenPGP RFC](https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/).
 
 ## Rendered versions of this text
 

book/source/adv/signatures.md

@@ -52,4 +52,4 @@ That is:
 
 Note that some historical version 3 signature packets may still be relevant for applications that handle old OpenPGP data[^sig-v3]. These version 3 signature packets will have been generated by version 4 keys.
 
-[^sig-v3]: Version 4 signature packets were introduced in [RFC 2440](https://datatracker.ietf.org/doc/html/rfc2440#section-5.2) in 1998, which specifies that applications SHOULD generate v4 signature, however generation of v3 signature packets has remained allowed through [RFC 4880](https://www.rfc-editor.org/rfc/rfc4880.html#section-5.2).
+[sig-v3]Version 4 signature packets were introduced in [RFC 2440](https://datatracker.ietf.org/doc/html/rfc2440#section-5.2) in 1998, which specifies that applications SHOULD generate v4 signature, however generation of v3 signature packets has remained allowed through [RFC 4880](https://www.rfc-editor.org/rfc/rfc4880.html#section-5.2).

book/source/encryption.md

@@ -35,7 +35,7 @@ Above, "plaintext" means one of:
 - *signed message*.
 
 A *signed message*, in turn, is a packet sequence that either
-- resembles an *inline-signed message* (a *Literal Data* packet sandwiched between one or more *One-Pass-Signature* and their respective *Signature* packets), or a
+- resembles an *inline-signed message* (a *Literal Data* packet sandwhiched between one or more *One-Pass-Signature* and their respective *Signature* packets), or a
 - *prefixed-signed* message (one or more *Signature* packets followed by a single *Literal Data* packet).
 ```
 

book/source/migration.md

@@ -110,5 +110,5 @@ In conclusion, converting v4 key material to v6 to verify old signatures is not
 Being able to read old messages using a converted key is also not really viable, since it is equally simple to just re-create the PKESK headers for a fresh v6 key.
 
 ```{note}
-Also see <https://www.openpgp.org/community/email-summit/2023/minutes/#Historical_email_archive>
+Also see <https://wiki.gnupg.org/OpenPGPEmailSummit202305Notes>
 ```

book/source/openpgp.md

@@ -84,21 +84,20 @@ Software and protocol development sometimes skips version numbers due to reasons
 
 ### OpenPGP version 6
 
-[RFC 9580](https://www.rfc-editor.org/rfc/rfc9580.html) has been published in July 2024, it specifies new OpenPGP version 6 formats.
-For this revision of the standard, the [IETF OpenPGP working group](https://datatracker.ietf.org/wg/openpgp/about/#autoid-1) has focused on updating the cryptographic mechanisms, adding new algorithms, and the deprecation of obsolete algorithms.
+As of this writing (in 2023), [version 6 of OpenPGP](https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/) is approaching publication as an RFC.
+The [IETF OpenPGP working group](https://datatracker.ietf.org/wg/openpgp/about/#autoid-1) is focused on updating the cryptographic mechanisms, adding new algorithms, and the deprecation of obsolete algorithms.
 
 This document describes OpenPGP version 6, while pointing out differences to previous versions that are relevant to application developers.
 
-At this point, support for RFC 9580 and OpenPGP version 6 is available in many implementations, including:
+Significant support for OpenPGP version 6 has already been achieved for multiple implementations, including:
 
-- [Bouncy Castle Java](https://github.com/bcgit/bc-java/) (since version 1.82),
-- [GopenPGP](https://github.com/ProtonMail/gopenpgp/) (since version 3.0.0),
-- [OpenPGP.js](https://github.com/openpgpjs/openpgpjs/) (since version 6.0.0),
-- [PGPainless](https://github.com/pgpainless/pgpainless/) (since version 2.0.0),
-- [PGPy](https://github.com/dkg/PGPy/tree/dkg/crypto-refresh) (in a fork of the project),
-- [RNP](https://github.com/rnpgp/rnp/) (since version 0.18),
-- [rPGP](https://github.com/rpgp/rpgp/) (since version 0.14.0),
-- [Sequoia PGP](https://gitlab.com/sequoia-pgp/sequoia/) (since version 2.0.0).
+- [Bouncy Castle Java](https://github.com/bcgit/bc-java/issues/1421),
+- [GopenPGP](https://github.com/ProtonMail/gopenpgp/tree/v3),
+- [OpenPGP.js](https://github.com/openpgpjs/openpgpjs/releases/tag/v6.0.0-alpha.0),
+- [PGPy](https://github.com/dkg/PGPy/tree/dkg/crypto-refresh),
+- [Sequoia PGP](https://gitlab.com/sequoia-pgp/sequoia/-/tree/crypto-refresh).
+
+Initial efforts to incorporate support for OpenPGP version 6 have been undertaken in the PGPainless and RNP implementations.
 
 ### Post-quantum cryptography in OpenPGP