/)) { continue; }
- if (match ($0, /^<\/div>/)) { continue; }
- print $0
- }
- close(newest)
- }
-
- function insertindex (tag) {
- file = "index.headlines.tmp";
- print "
"
- while (getline < file) {
- split($0, a, "|")
- printf " %s \n", a[1], a[2];
- }
- print " "
- close (file)
- }
- '
-mv index.tmp index.html || echo "upload: error updating index.html" >&2
-
-# Update the feed file
-echo "upload: Updating feed file" >&2
-
-
-
-# Rename headlines file
-mv index.headlines.tmp headlines.txt
-
-if [ $opt_upload = yes ]; then
- echo "upload: Uploading files" >&2
- rsync -vr --links --exclude '*~' --exclude upload --exclude '*tmp' \
- --exclude '*.org' \
- . werner@trithemius.gnupg.org:/var/www/www/www.gnupg.org/misc/blog/
-fi
-
-#eof
diff --git a/misc/bugs.gnupg.org/index.html b/misc/bugs.gnupg.org/index.html
index 4b45f1a..d68d9ad 100644
--- a/misc/bugs.gnupg.org/index.html
+++ b/misc/bugs.gnupg.org/index.html
@@ -1,153 +1,159 @@
g10 Code's bug tracker
Becoming a registered user
To enter a bug into our bug tracker you need to be a registered user.
A registered user will be assigned a provisional user role
which allows to enter new bugs and to edit these bugs. The user
role will be granted by an administrator on demand. Just add
remark to your bug report that you wish to work more with the bug
tracker. We have these strict rules to avoid spam and keep trolls
away from the tracker.
Note that some actions (e.g. closing a bug) are even restricted from
regular users. A developer account is required for these actions.
The rationale is that only a developer will be able to fix things and
thus decides whether a bug is to be closed. A bug may be re-opened at
any time.
How to add a new bug
Please note that this bug tracker is a public resource and everything
you enter there will be available for the whole networked world. It
is similar to a public mailing list and there is no easy way to
retract any information.
You should follow these steps to enter a new bug (issue):
Review the documentation and the mailing list archives to see
whether your problem has already been addressed. Often bugs are
mere configuration problems.
Check that the bug has not yet been entered and that there is no
similar bug in the tracker. Use the search option for this. It
is best to also look through the already closed
(resolved ) issue.
+
If you consider the bug a severe security problem and you do not
+ want to publish it, please write to security at gnupg.org to ask
+ for advice and our encryption keys. See also the AUTHORS file in
+ each package.
+
+
Select the Create New menu entry. An empty page will be
presented.
Come up with a meaningful short description of the bug and enter
this into the title field.
Assign a priority for the bug. These priorities are
defined:
bug Use this for a regular bug.
urgent Use this if you believe that the problem should
be fixed soon.
critical Use this if your problem is really severe and inhibits
you from working with the software. Do not use it if you can
find a workaround for the problem.
minor-bug Use this for a minor bug
feature Use this for a technical feature requests.
wish Use this for everything else, for example to
request better documentation or a new FAQ entry.
See whether you can assign category to the bug. There is a drop
down list with all available categories. A category is in
general the name of the application with the bug, but might also
be a library. If you can't figure out the category, keep it at
- no selection - . The dirmngr category is only
used for the old standalone package; since GnuPG 2.1 dirmngr
is part of GnuPG proper; thus use gnupg as category and
add dirmngr to the topic field.
Now for the most important field: The description of the problem.
You enter this information into the Change Note field.
Please take care to use hard line breaks and format the report
as you would do by mail. No HTML please.
Make sure that you describe the bug as good as possible and try
to come up with a minimal recipe on how to replicate the bug. We
need to know the version of the software and if
you are using a non-released version the GIT commit id. The type
and version of your operating system is usually important, so
please tell us. In particular tell us if you are problem occurs
on a non Unix system, i.e. MS Windows.
If you need to enter more information, you may upload any kind of
file. However, please do this only if you are sure that these
information are important and that they do not contain
confidential data. This file will be public and it won't be
possible to retract it anymore. Avoid screen shots unless you
are asked for them.
The problem with screen shots or, worse, screen casts is that we
would need to transcript them to text for evaluating the problem.
That takes away time we better spend solving the problem; it
is easy to help us by providing a transcription
If you are sure that your bug is MS Windows specific, please
enter the string "w32" into the Topics field. You do
not need to do it if you select a Windows specific category (like
"gpgol").
If you want to refer to an external bug description (for example
a similar entry in Debian's bug tracker), enter the URL into the
ExtLink field.
If everything is as you want it, select the Submit New
Entry button. This entry as well as all future changes will
also be mailed to you.
Contact information available at the g10 Code main pages .
+href="https://www.g10code.com">g10 Code main pages.
Copyright (C) 2006 g10 Code GmbH, Erkrath-Hochdahl.
Verbatim copying and distribution of this entire article is
permitted in any medium, provided this notice is preserved.
diff --git a/misc/bugs.gnupg.org/roundup-topics.html b/misc/bugs.gnupg.org/roundup-topics.html
index 208707d..d78cf28 100644
--- a/misc/bugs.gnupg.org/roundup-topics.html
+++ b/misc/bugs.gnupg.org/roundup-topics.html
@@ -1,111 +1,115 @@
g10 Code's bug tracker - Topics
Roundup has a feature named "Topics" which allows to assign one or
more keywords to a certain bug ("issue" in Roundup parlance). These
keywords may for example be used in a search. As keywords are
usually short, there meaning and suggested usage ist not always
clear. This list shall help to make sensible use of the keywords.
Topics used in the GnuPG bug tracker
Name Description
Keywords describing the location
agent Related to the gpg-agent
keyserver Keyserver or keyserver protocol
related
scd Related to the scd-daemon or general
smart card access problem
pinentry Related to the Pinentry
ssh Related to gpg-agent's ssh-agent
implementation
gpgtar Related to gpgtar
iobuf Related to gpg's iobuf mechanism
openpgp OpenPGP protocol
smime S/MIME (CMS, X.509) protocol
gpg4win Related to the Gpg4win installer
uiserver Related to the UI-Server (cf. gpg4win)
doc Related to documentation
gpg14 Related to GnuPG 1.4.
gpg20 Related to GnuPG 2.0.
gpg21 Related to GnuPG 2.1.
i18n Related to internationalization
ipc Related to inter process communication
npth Related to nPth
Keywords describing the environment
asm Problem with low-level assembler code
cross Bug pertaining to cross-compiling
- osx Mac OS/X specific problem
+ macos MacOS specific problem
w32 MS Windows specific problem
w64 MS Windows 64 bit specific problem
Keywords describing the action taken
backport This needs to be ported to older branches.
forwardport This needs to be ported to newer branches.
faq This should be made an entry into the
FAQ or is already answered there.
+ gpg22 To be fixed for GnuPG 2.2.
+ gpg23 Will be addressed in GnuPG 2.2.
patch Patch included
noinfo Not enough information given
notdup Problem duplicating the bug
dup A similar bug report already exists
nobug This is not a bug (maybe even a feature).
Note that there is also a category of
the same name.
+ rc Release critical report
+
sillyUB Silly interpretation of undefined
behaviour by a compiler. Needs fix so
that gcc et al do not break the
code.
tooold The report is too old. Spending time
on it is not justified.
wontfix The bug will not be fixed.
mistaken Empty report or unrelated to GnuPG.
endoflife Software version has reached EOL status.
question A question and not a bug report
Contact information available at the g10 Code main pages .
+href="https://www.g10code.com">g10 Code main pages.
Copyright (C) 2006 g10 Code GmbH, Erkrath-Hochdahl.
Verbatim copying and distribution of this entire article is
permitted in any medium, provided this notice is preserved.
diff --git a/misc/git.gnupg.org/index.html b/misc/git.gnupg.org/index.html
index af532e4..0909b73 100644
--- a/misc/git.gnupg.org/index.html
+++ b/misc/git.gnupg.org/index.html
@@ -1,213 +1,214 @@
The GnuPG Repositories
· English ·
The GnuPG Repositories
-Use our GIT
+Use our GIT
Viewer to browse the GIT
-repository. Activity reports
+repository. Activity reports
are also available.
Here is a list of shortcuts to often used repositories:
GnuPG
-
+
Libgcrypt
-
+
Gpg4win
+
For actual work you should clone a repository; use
+
+ git clone https://dev.gnupg.org/source/foo.git
+
+or
git clone git://git.gnupg.org/foo.git
and replace foo by the name of the project (e.g. gnupg
-or libgcrypt ).
+or libgcrypt ). Many commits and all tags are signed using
+GnuPG. To verify the signatures on a tag (e.g. gnupg-2.1.15 )
+do
-
-
-
-
+
+ git tag -v gnupg-2.1.15
+
Notes
Here is a list of projects now hosted on other servers:
diff --git a/misc/git.gnupg.org/logo-gnupg-light-purple-bg.png b/misc/git.gnupg.org/logo-gnupg-light-purple-bg.png
new file mode 100644
index 0000000..41264d9
Binary files /dev/null and b/misc/git.gnupg.org/logo-gnupg-light-purple-bg.png differ
diff --git a/misc/git.gnupg.org/logo-sponsor.png b/misc/git.gnupg.org/logo-sponsor.png
new file mode 100644
index 0000000..e01ada7
Binary files /dev/null and b/misc/git.gnupg.org/logo-sponsor.png differ
diff --git a/misc/git.gnupg.org/pace.png b/misc/git.gnupg.org/pace.png
new file mode 100644
index 0000000..d627c9a
Binary files /dev/null and b/misc/git.gnupg.org/pace.png differ
diff --git a/misc/git.gnupg.org/site.css b/misc/git.gnupg.org/site.css
new file mode 100644
index 0000000..884dad5
--- /dev/null
+++ b/misc/git.gnupg.org/site.css
@@ -0,0 +1,209 @@
+A:link {
+ color: #784c6c;
+ font-weight: bold;
+ text-decoration: none;
+}
+A:hover {
+ background-color: #d0dce8;
+ font-weight: bold;
+ text-decoration: none;
+}
+A:visited {
+ color: #5c6064;
+ font-weight: bold;
+ text-decoration: none;
+}
+A.img:hover {
+ background-color: #f0f0fc;
+}
+BLOCKQUOTE {
+ border: 1px solid black;
+ padding: 1em;
+}
+BODY {
+ margin-left: 0px;
+ margin-right: 0px;
+ text-align: left;
+ color: black;
+ background-color: #f0f0fc;
+ font-family: sans-serif;
+ font-weight: normal;
+ text-decoration: none;
+}
+DD {
+ padding-bottom: 1em;
+}
+H1,
+H2 {
+ font-size: large;
+}
+H1:first-letter,
+H2:first-letter {
+ font-size: x-large;
+}
+H3:first-letter {
+ font-size: large;
+}
+H1,
+H2,
+H3 {
+ color: #5c6064;
+ font-weight: bold;
+ font-variant: small-caps;
+ letter-spacing: 0.1em;
+}
+H1:first-letter,
+H2:first-letter,
+H3:first-letter {
+ color: #784c6c;
+}
+IMG {
+ border: none;
+}
+LI.important {
+ color: red;
+}
+P.out-of-date {
+ font-style: italic;
+ font-size: small;
+}
+PRE,
+DIV.samp {
+ background-color: #ebebf4;
+ margin: 1em;
+ border: 1px solid black;
+ padding: 1em;
+ font-size: small;
+}
+SPAN.important {
+ color: red;
+}
+DIV.urgent {
+ width: 85%;
+ text-align: center;
+ border: solid red;
+ font-weight: bold;
+}
+TABLE.layout {
+ background-color: transparent;
+ border-collapse: separate;
+ border: none;
+}
+TD.layout {
+ border: 1px none black;
+ padding: 0px;
+ text-align: right;
+ vertical-align: top;
+}
+TABLE.frame {
+ background-color: transparent;
+ border-collapse: collapse;
+ border: 1px none black;
+}
+TD.frame-right {
+ border-left: 2px solid #784c6c;
+}
+TD.frame-bottom,
+TD.frame-bottom-lang,
+TD.frame-bottom-mirror {
+ color: #5c6064;
+ border-top: 2px solid #5c6064;
+ text-align: left;
+ font-size: small;
+ font-weight: bold;
+}
+TD.frame-bottom-lang,
+TD.frame-bottom-mirror {
+ font-size: x-small;
+}
+TD.frame-bottom-mirror {
+ text-align: right;
+}
+TD.frame-corner {
+ border-top: 2px solid #5c6064;
+ border-left: 2px solid #784c6c;
+}
+TD.frame-spacing {
+ border: none;
+ height: 30px;
+}
+TD.frame-head {
+ padding: 0px 0px 1em 0px;
+ border: none;
+ text-align: center;
+ vertical-align: middle;
+ font-size: large;
+ font-variant: small-caps;
+ font-weight: bold;
+ letter-spacing: 0.3em;
+}
+TD.frame-head-blockquote {
+ padding: 0px 1em 1em 1em;
+ border-bottom: 2px solid #5c6064;
+ vertical-align: middle;
+ font-family: sans-serif;
+ text-align: center;
+ text-decoration: none;
+ font-size: x-small;
+ font-variant: small-caps;
+ letter-spacing: 0.3em;
+}
+SPAN.g {
+ color: #784c6c;
+ font-size: x-large;
+}
+SPAN.nu {
+ color: #784c6c;
+}
+SPAN.pg {
+ color: #5c6064;
+ font-size: x-large;
+}
+A.lang {
+ font-size: x-small;
+}
+A.lang:visited {
+ color: #784c6c;
+}
+TD.frame-navb {
+ padding: 0px 0.3em 0.5em 0.3em;
+ text-align: left;
+ font-size: small;
+}
+UL.frame-navb {
+ margin: 0px;
+ margin-left: 1em;
+ padding-left: 1em;
+}
+UL.frame-navb:first-line {
+ margin: 0px;
+ padding-left: 1em;
+}
+LI.frame-navb {
+}
+TD.frame-cont {
+ padding: 0px 1em 1.5em 1em;
+ text-align: left;
+ vertical-align: top;
+}
+DIV.frame-foot {
+ text-align: center;
+ font-size: x-small;
+ color: #5c6064;
+}
+A.foot:link {
+ color: #5c6064;
+ font-size: x-small;
+ font-weight: normal;
+ text-decoration: underline;
+}
+A.foot:visited {
+ color: #5c6064;
+ font-size: x-small;
+ font-weight: normal;
+ text-decoration: underline;
+}
+A.foot:hover {
+ font-size: x-small;
+ font-weight: normal;
+}
diff --git a/misc/howtos.gnupg.org/card-howto/en/apa.html b/misc/howtos.gnupg.org/card-howto/en/apa.html
index c6ada87..fa4b0fe 100644
--- a/misc/howtos.gnupg.org/card-howto/en/apa.html
+++ b/misc/howtos.gnupg.org/card-howto/en/apa.html
@@ -1,251 +1,251 @@
Appendix A. Appendix
A.1. A small OpenPGP card FAQ
CHV
Card Holder Verification, commonly followed by a number denoting which CHV is meant. The OpenPGP card uses three CHVs: CHV1, CHV2, CHV3. They are often also referenced as PIN 1, PIN2, PIN 3. CHV3 is used as the so called Admin PIN (which is sometimes also called S(ecurity)O(fficer) PIN).
PC/SC
Personal computer/Smart Card. The standard framework for Smart Card access on Windows Platforms (included in Windows2000). There are also implementations for GNU/Linux and other Free OSes (i.e. pcsclite).
CCID
Chip Card Interface Description. The specification for the USB device class used for chip card readers is 11 (0x0B).
OpenPGP
OpenPGP is a non-proprietary protocol for encrypting email using public key cryptography. It is based on PGP as originally developed by Phil Zimmermann. The OpenPGP protocol defines standard formats for encrypted messages, signatures, and certificates for exchanging public keys.
diff --git a/misc/howtos.gnupg.org/card-howto/en/ch02s02.html b/misc/howtos.gnupg.org/card-howto/en/ch02s02.html
index b340c94..8250b9b 100644
--- a/misc/howtos.gnupg.org/card-howto/en/ch02s02.html
+++ b/misc/howtos.gnupg.org/card-howto/en/ch02s02.html
@@ -1,251 +1,251 @@
2.2. Required Hardware
First you need an OpenPGP compatible smart card which can, for example, be obtained by becoming a fellow of the Free Software Foundation Europe .
-
Card readers (NOT those used for flash memory cards) can be obtained from computer stores (e.g. http://www.kernelconcepts.de/products/security-en.shtml ).
+
Card readers (NOT those used for flash memory cards) can be obtained from computer stores (e.g. https://www.floss-shop.de/en/security-privacy/ ).
2.2.1. A List of tested Readers
Please note that the USB device class for USB readers is 11 (or 0x0B in hex).
This is a small USB reader (CCID; 65*45*8mm)
supported by GnuPG directly as well as by pcsclite.
This very device is actually the first reader
supported by GnuPG and the reason for the internal
CCID driver as no CCID driver was available at that
time.
This is a USB (CCID)/serial reader with a
numerical keypad and three extra buttons. The pinpad
may be used to securely enter the PIN without using
the attached computer (since GnuPG 2.0.1). Only USB
has been tested.
This reader comes in two types: serial and USB. Both readers are very similar and of the same size (65*45*8mm). As far as we know these readers are no longer manufactured have been replaced by the SCR335 from SCM Microsystems.
Omnikey Cardman 3121 (and 2020)
This USB card reader supports CCID and PC/SC. The older Omnikey Cardman 2020 is no longer produced. The newer reader has not been tested, but Omnikey says that the two readers are compatible.
Omnikey Cardman 3111 (and 2010)
This serial card reader supports PC/SC. The
older Omnikey Cardman 2010 (photo) is out of
production. The serial version of this reader has not
yet been tested.
This USB card reader is supported by PC/SC as well as
by GnuPG's internal driver. This is actual a dual reader with
a second device to access RFID tokens; this is
supported by the forthcoming librfid..
This is an USB keyboard with integrated CCID
card reader. It is supported by PC/SC as well as be
GnuPG's internal driver. The mueric keyblock may be
used to securely enter the PIN without using the
attached computer (since GnuPG 2.0.3).
This USB card reader is supported by PC/SC as
well as by GnuPG's internal driver. The pinpad may be
used to securely enter the PIN without using the
attached computer (since GnuPG 2.0.1).
This is a CardBus (PCMICA) reader to be used
with Laptops. The SVN version of GnuPG supports this
reader trough its internal driver. There is no free
PC/SC support. A recent Linux version (2.6.15.3) is
required. Very handy and useful devices so you can
expect any problems to be solved fast.
This is a compact reader with USB or serial
interface. It works fine with PC/SC (pcscd,
libasedrive-usb or libasedrive-serial Debian
packages).
This is a CCID reader for ID-000 sized cards. It
works fine with GnuPG's internal driver and should
also work with PC/SC.
If you want to cut a full sized card down to ID-000
format, take care to remove all burr and round the
edges a bit. This is in particular important so
that you are able to remove the card using the tiny
blue lever.
diff --git a/misc/howtos.gnupg.org/card-howto/en/smartcard-howto-single.html b/misc/howtos.gnupg.org/card-howto/en/smartcard-howto-single.html
index dea3cde..1065d90 100644
--- a/misc/howtos.gnupg.org/card-howto/en/smartcard-howto-single.html
+++ b/misc/howtos.gnupg.org/card-howto/en/smartcard-howto-single.html
@@ -1,409 +1,409 @@
How to use the Fellowship Smartcard How to use the Fellowship Smartcard
The GnuPG Smartcard HOWTO
Rebecca Ehlers
Thorsten Ehlers
Werner Koch
Matthias Kirschner Copyright © 2005 Free Software Foundation Europe e.V.
This file is free software; as a special exception the authors give unlimited permission to copy and/or distribute it, with or without modifications, as long as this notice is preserved.
This file is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY, to the extent permitted by law; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
With GnuPG everybody has the chance to secure his communication.
To work with GnuPG on different machines (private PC, at work, with laptop etc.) the secret key has to be present on every machine. Distributing the secret key to a lot of different machines does not support its secrecy. Especially at work where other peple have root access on your machine it is not save to store your secret key. Starting with version 1.3.3 GnuPG supports smart cards to save your keys.
This Howto describes how to use GnuPG with a smart card distributed to fellows of the Free Software Foundation Europe .
In general cards that implement the OpenPGP card specification in version 1.0 or higher are supported by GnuPG.
The OpenPGP Card is a smart card (standard size; ISO 7816-4,-8 compatible).
Features of this card are:
3 independent 1024 bit RSA keys (signing,encryption,authentication).
Key generation on card or import of existing keys.
Signature counter.
Data object to store an URL to access the full OpenPGP public key.
Data objects for card holder name etc.
Data object for login specific data.
Length of PIN between 6 and 254 characters; not restricted to numbers.
T=1 protocol; compatible with most readers.
Specification freely available and usable without any constraints.
Reasonably priced.
Chapter 2. Installation for GNU/LinuxSince version 1.3.90 GnuPG supports smart cards by default.
Please make sure that libusb is available prior to building GnuPG. It can be obtained from http://prdownloads.sourceforge.net/libusb . On Debian GNU/Linux a simple apt-get install libusb-dev
should be sufficient.
If you are not using an USB reader please also install libpcsclite and libpcsclite-dev. On Debian GNU/Linux a simple apt-get install libpcsclite libpcsclite-dev
should be sufficient.
If your reader is a native USB device and supports the CCID (Chip Card Interface Description) specification it is directly supported by GnuPG.
Most USB readers today still behave like serial readers. In this case you need the kernel module pl2303 to access the reader. This module is a "USB Serial Driver" which can be found under
->->->
- in the 2.6 kernel configuration. This module makes sure that the proprietary reader protocol is translated to a standard protocol.
2.1.1. Installation of GnuPGWithout an installation of GnuPG the OpenPGP card will be of little use. So, please, go ahead and install it.
GnuPG can be downloaded from http://www.gnupg.org/download/index.html . Please use the recent stable version.
After downloading and patching the sources GnuPG is installed with the usual ./configure
, make
, make install
. For further information please refer to the installation instructions shipped with GnuPG.
Note If you are running Debian GNU/Linux you can also build your own Debian package with dh_make
and debuild
in the source directory. After that you can install it the usual way with dpkg -i gnupg-version.deb
If you are using the 1.9 branch of GnuPG and plan to use the PC/SC driver you should now install the software to make sure that the pcsc wrapper binary will be available at the right place.
First you need an OpenPGP compatible smart card which can, for example, be obtained by becoming a fellow of the Free Software Foundation Europe .
Card readers (NOT those used for flash memory cards) can be obtained from computer stores (e.g. http://www.kernelconcepts.de/products/security-en.shtml ).
2.2.1. A List of tested ReadersPlease note that the USB device class for USB readers is 11 (or 0x0B in hex).
This is a small USB reader (CCID; 65*45*8mm)
+ in the 2.6 kernel configuration. This module makes sure that the proprietary reader protocol is translated to a standard protocol.
2.1.1. Installation of GnuPGWithout an installation of GnuPG the OpenPGP card will be of little use. So, please, go ahead and install it.
GnuPG can be downloaded from http://www.gnupg.org/download/index.html . Please use the recent stable version.
After downloading and patching the sources GnuPG is installed with the usual ./configure
, make
, make install
. For further information please refer to the installation instructions shipped with GnuPG.
Note If you are running Debian GNU/Linux you can also build your own Debian package with dh_make
and debuild
in the source directory. After that you can install it the usual way with dpkg -i gnupg-version.deb
If you are using the 1.9 branch of GnuPG and plan to use the PC/SC driver you should now install the software to make sure that the pcsc wrapper binary will be available at the right place.
First you need an OpenPGP compatible smart card which can, for example, be obtained by becoming a fellow of the Free Software Foundation Europe .
Card readers (NOT those used for flash memory cards) can be obtained from computer stores (e.g. https://www.floss-shop.de/en/security-privacy/ ).
2.2.1. A List of tested ReadersPlease note that the USB device class for USB readers is 11 (or 0x0B in hex).
This is a small USB reader (CCID; 65*45*8mm)
supported by GnuPG directly as well as by pcsclite.
This very device is actually the first reader
supported by GnuPG and the reason for the internal
CCID driver as no CCID driver was available at that
time.
This is a USB (CCID)/serial reader with a
numerical keypad and three extra buttons. The pinpad
may be used to securely enter the PIN without using
the attached computer (since GnuPG 2.0.1). Only USB
has been tested.
This reader comes in two types: serial and USB. Both readers are very similar and of the same size (65*45*8mm). As far as we know these readers are no longer manufactured have been replaced by the SCR335 from SCM Microsystems.
Omnikey Cardman 3121 (and 2020)This USB card reader supports CCID and PC/SC. The older Omnikey Cardman 2020 is no longer produced. The newer reader has not been tested, but Omnikey says that the two readers are compatible.
Omnikey Cardman 3111 (and 2010)This serial card reader supports PC/SC. The
older Omnikey Cardman 2010 (photo) is out of
production. The serial version of this reader has not
yet been tested.
This USB card reader is supported by PC/SC as well as
by GnuPG's internal driver. This is actual a dual reader with
a second device to access RFID tokens; this is
supported by the forthcoming librfid..
This is an USB keyboard with integrated CCID
card reader. It is supported by PC/SC as well as be
GnuPG's internal driver. The mueric keyblock may be
used to securely enter the PIN without using the
attached computer (since GnuPG 2.0.3).
This USB card reader is supported by PC/SC as
well as by GnuPG's internal driver. The pinpad may be
used to securely enter the PIN without using the
attached computer (since GnuPG 2.0.1).
This is a CardBus (PCMICA) reader to be used
with Laptops. The SVN version of GnuPG supports this
reader trough its internal driver. There is no free
PC/SC support. A recent Linux version (2.6.15.3) is
required. Very handy and useful devices so you can
expect any problems to be solved fast.
This is a compact reader with USB or serial
interface. It works fine with PC/SC (pcscd,
libasedrive-usb or libasedrive-serial Debian
packages).
This is a CCID reader for ID-000 sized cards. It
works fine with GnuPG's internal driver and should
also work with PC/SC.
If you want to cut a full sized card down to ID-000
format, take care to remove all burr and round the
edges a bit. This is in particular important so
that you are able to remove the card using the tiny
blue lever.
2.3. Installation of Card ReaderTwo standard protocols are used by GnuPG to access card readers.
2.3.1. CCID (Chip Card Interface Description)The driver to access CCID cards is built into GnuPG. This driver will be used by default.
To use this driver follow the instructions and make sure you have sufficient permission (see below) to access the USB device for reading and writing.
With udev (preferred installation)First of all, you will need to download two files for udev and copy them to the udev configuration directories, in order to let it identify your card reader:
Now, open a terminal and become root (you will be asked for your root password):
archi@foobar:~ > su -
On Ubuntu systems, you should run (and then you will be asked for the user password):
archi@foobar:~ > sudo su -
Then you will have to move the files from the directory you have saved them to, to the udev configuration directories:
# cd /home/directory/where/you/saved/the/file (change for the right path)
# cp gnupg-ccid.rules /etc/udev/gnupg-ccid.rules
# cp gnupg-ccid /etc/udev/scripts/gnupg-ccid
# chmod +x /etc/udev/scripts/gnupg-ccid
# ln -s /etc/udev/gnupg-ccid.rules /etc/udev/rules.d/gnupg-ccid.rules
All the configuration files are in the right place and with the right permissions by now.
You will now create a group scard, give this group permission to access the smart card reader, and include the users who should have access to the card reader to this group.
# addgroup scard
# addgroup yourusername scard (change for the right username)
# exit (to logout the root user)
With hotplug (deprecated in modern systems)The described hotplugging mechanism assigns permission for all CCID devices to the users in scard group.
Create the following two files. The first file is a mapping file which decides on the script to run when detecting a CCID device. The second file is the script that should be run if a device with the matching parameters is plugged in. This script is the one to actually assign the permissions.
script states the script that should be run if a device matching the parameters is plugged in via USB.
match_flags is one of the given USB_MATCH_XXX options. The idVendor and the idProduct can be figured out by calling lsusb
. The output looks something like this:
The values given behind ID are idVendor:idProduct and with a leading 0x could be used in gnupg-ccid.usermap in combination with USB_MATCH_VENDOR or USB_MATCH_PRODUCT .
This script changes the permissions and the ownership of a USB device under /proc/bus/usb to grant acces to this device to users in the specified group. The group in this example is scard . ACTION and DEVICE are passed via the hotplug mechanism.
Note Do not forget to run chmod +x
on the script.
You should also create the group scard and then add the users to access the card reader to the group. This is done by the following commands: addgroup scard
and addgroup <user> scard
.
Note Brian Gough <bjg@network-theory.co.uk> made the following remark: The hotplug package in Debian woody requires all the numbers in gnupg-ccid.usermap to have a 0x prefix otherwise it gives an "unparseable line" error and the i.e. gnupg-ccid 0x0003 0x04e6 0xe003 0x0 0x0 0x0 0x0 0x00 0x0B 0x00 0x00 0x00000000
instead of gnupg-ccid 0x0003 0x04e6 0xe003 0 0 0 0 0x00 0x0B 0x00 0x00 0x00000000
. After installing the modified file call update-usb.usermap
.
Please make sure that you can mount a USB device. This can be achieved by accessing the USB stack via libusb through the usbfs (USB filesystem). If you are using USB < 2.0 the filesystem is called usbdevfs .
To accomplish this goal please add the following line to your /etc/fstab .
To make sure that a specific user has read and write access to the USB device add devuid=[user id] to the defaults, user options. With devgid=[group id] access will be granted to the given group.
This approach creates a major security problem. The owner of the files has full permissions to ALL connected USB devices. It does not matter what kind of device is connected. Therefore it is strongly suggested to use the hotplug method.
2.3.2. PC/SC (Personal computer/Smart Card) TODO
To use PC/SC make sure you disable CCID by passing the --disable-ccid option to GnuPG.
Note You can easily check your installation by inserting the card in the card reader and entering gpg --card-status
(more about this command in Chapter 3, Administrating the Card ).
Chapter 3. Administrating the CardWarning Whenever your are asked to enter a PIN make sure you know which PIN is meant. There are two PINs for the card - the PIN and the AdminPIN . Please make sure you do not mix them up.
Note During the writing of this HowTo it seemed that every once in a while GnuPG did not want to talk with the card reader. We were quite sure we have not changed anything in the configuration but for some reason it just did not work. Werner knows this problem and it will hopefully soon be fixed. Note that we never encountered this problem with Linux kernels 2.4.x - only with most 2.6 kernels.
This phenomenom occurs when the card reader has been in use for quite some time. It might help to re-plug the reader.
The error message displayed looks like this:
To check if your card (and installation) is working please put your OpenPGP card in the reader and run gpg --card-status
. For an empty card the output should look like this:
The information displayed is the standard output for the Fellowship smartcard we are using. Cards from other manufacturers might produce a different output.
3.1.1. Describing the outputNote The output depends on manufacturer and specification.
Application ID The manufacture's ID. This includes the type of the card, the implemented version of the specification, the manufacturer and the serial number. This is a unique identifier for any card.
Version The used OpenPGP specification.
Manufacturer The card's manufacturer.
Serial number A unique number for all cards from this manufacturer.
Name of cardholder The holder of this card. Only plain ASCII characters are Allowed here. gpg does not use this field.
Language prefs The card holder's language preferences. gpg ignores this value.
Sex Male or female. gpg ignores this value.
URL of public key Used by the fetch
command of gpg --edit-card
. It may contain an URL to be used to retrieve the public key.
Login data This field may be used to store the account name of the card holder. It may be used for login purposes. gpg does not enforce any match of this name with a name used in the key. See the source (app-openpgp.c) for some special features of the login-name field.
Private DO 1 This is a field reserved for arbitrary data.
Private DO 2 This is a field reserved for arbitrary data.
Signature PIN When set to "forced", gpg requests the entry of a PIN for each signature operation. When set to "non forced", gpg may cache the PIN as long as the card has not been removed from the reader.
Max. PIN lengths This field is unchangeable. The values are put on the card right after personalisation - this is the moment after the chip has been glued on the card.
PIN retry counter This field saves how many tries still are left to enter the right PIN. They are decremented whenever a wrong PIN is entered. They are reset whenever a correct AdminPIN is entered. The first and second PIN are for the standard PIN. gpg makes sure that the two numbers are synchronized. The second PIN is only required due to peculiarities of the ISO-7816 standard; gpg tries to keep this PIN in sync with the first PIN. The third PIN represents the retry counter for the AdminPIN.
Signature counter This number keeps track of the signatures performed with the stored key. It is only reset if a new signature key is created on or imported to the card.
Signature key This key is commonly used as the primary OpenPGP key.
Encryption key This key is commonly used as an encryption subkey.
Authentication key This key is not used by gpg at all. Other tools like PAM modules or ssh use this key for authentication services.
General key info This primary user ID is shown if the corresponding public OpenPGP key is available.
3.2.1. General Information about PINsA new card has the following default PINs stored. The AdminPIN's value is 12345678. The normal PIN is 123456. Please note that the second PIN is two digits shorter.
You might have received a card with a few data
fields already personalized (e.g. the FSFE Fellowship
card). Please check the documentation which comes with
this card to see whether the default PINs are really to be
used or from where to get the actual PINs. Often the
AdminPIN is send by separate mail.
If a wrong PIN has been entered three times in a row the card will be blocked. It can be unblocked with the AdminPIN.
Warning It is also important to know that entering a wrong AdminPIN three times in a row destroys(!) the card . There is no way to unblock the card when a wrong AdminPIN has been entered three times.
To access the PIN operations enter gpg --change-pin
. Different options for PIN management will be displayed. To select a command enter the number displayed in front of the command.
You are first asked to enter the current PIN. Afterwards you are asked to enter the new PIN. Then you are asked to re-enter the new PIN. The cursor will not move forward to indicate your typing.
The PIN has been successfully changed. The AdminPIN is not affected by these changes.
Use this command to unblock a blocked PIN.
First you are asked for the AdminPIN and then to enter and re-enter a new PIN. The AdminPIN is not affected by this procedure.
Please note that an AdminPIN cannot be unblocked.
Changing the AdminPIN is the same procedure as changing the PIN. Enter the current AdminPIN. Then enter a new AdminPIN and re-enter it. The normal PIN is not affected by these changes.
PINs can also be managed via --card-edit
commands.
3.3. Initialising the cardTo follow the instructions in this chapter make sure that the card reader works and the card can be accessed (Chapter 3, Administrating the Card , command gpg --card-status
).
To initialise a card enter gpg --card-edit
. Basic information about the card is shown. The output is the same as gpg --card-status
. The difference is that the output is now followed by a command prompt.
To get a list of all commands available enter help
.
These commands are not very useful because data stored on the card cannot be changed.
For a list of useful commands enter admin
and then help
.
3.3.1. Personalising the cardSave the name of the card owner on the card. Technically this is not required but it will prove useful if more than one card is around.
Enter name
and follow the prompts. You are seperately asked for sur- and given name. After entering the data you are asked for the AdminPIN.
Note In general the AdminPin is cached through a session. So if you do not remove the card you will not be asked again to enter it. As always there are exceptions to this rule.
If you like you can also enter the language you prefer (lang
) and the sex (sex
). gpg does not use this information so you might want to omit it.
To generate a key on the card enter generate
. You will be asked if you would like to make an off-card copy of the encryption key. It is useful to say yes here.
Note Without a backup you will not be able to access any data you encrypted with the card if it gets lost or damaged.
If a key exists on the card a security question has to be answered to avoid accidental overwriting.
The whole process of key generation looks like this.
Note You might be asked for the PINs at different times.
Six signing operations are done during the creation of the public and secret key (one self-signature to bind the name to the key and two key-binding signatures for each key). Future versions of gpg might just need three signing operations.
The card is now ready for use.
Note Please save the backup key, transfer it to a different medium and store it in a safe place.
It is important that you delete the copy of the key from the hard disk, too. The best choices here are tools like shred
from the GNU coreutils package or wipe
to make sure that the original content gets overwritten.
A key can also be stored as a printout. Normally you do not need it, but in case your card breaks and the backup copy is not available you still have the chance to re-enter the key. gpg --enarmor
may be used to convert the backup key into a printable format.
Now you should be able to do all the stuff with your smartcard, which you have previously done with your usual GnuPG setup.
4.1. Signing and encrypting filesYou can sign, de- and encrypt files the usual way. The only difference is, that if you are asked for your passphrase you have to enter the PIN of the smartcard.
4.2. Signing and encrypting mailsOf course you can also use your smartcard to sign and encrypt mails. The only difference is, same as signing and encrypting files, that you have to type in the PIN instead of your passphrase.
Chapter 5. Advanced FeaturesWarning Please make sure to make a backup of you key before experimenting with any of the following commands.
5.1. Moving an existing key to the cardTheoretically you can move any existing key to the card. It does not make a difference if you want to import a primary key or a subkey. Practically there are some restrictions. First, the card does not support DSA keys. Second, only 1024 bit RSA keys are currently supported by the card.
Use the keytocard
command to move the key. gpg will do the checking for you and will also tell you if it is possible to move the key or not.
5.2. Using the card only for subkeysUsing the card this way is suggested if you already have a key with a lot of key signatures.
Subkeys are keys to use in every day life. They are bound to your private key and are used for signing and decrypting. They normally have a set expiration date. Even overlapping subkeys for a single private key are possible. However, there is one limitation to a full featured private key - subkeys cannot be used for key signing.
Therefore they are a perfect alternative to use on a smartcard.
5.2.2. Moving a Subkey to the CardThe card does not support DSA keys. Even if you are using a RSA key you might encounter problems. The cards available at the moment only support 1024 bit keys.
The suggestion is to use the key on the card only for signing and decrypting but NOT for key signing.
Note Warning Secret keys stored on a computer accessible via network can be compromised.
Initialise your card but do not call generate
- call quit
. Start gpg
calling --edit-key <your_keyid>
. Now enter addcardkey
and make your decision to either create a signature, an encryption or an authentication key.
First create a signing key. If this kind of key already exists on the card, a security question has to be answered. Run save
to commit the changes to the card. The key on the card will not be removed if you do not save
the changes. You can create another subkey by again calling addcardkey
. Choose the encryption key and proceed as explained.
Note gpg will always use the latest created key of a given type.
There is no direct way to create a backup key of the card's decryption key like it is done with the generate
command.
Note Make a copy of your secret key before running the following commands. Otherwise the whole procedure will be pointless.
A few steps more will help you to achieve this goal. First create a regular RSA subkey of 1024 bit length using the addkey
command. Then select this new key and run keytocard
. gpg transfers the key to the card and replaces the existing secret key with a stub.
A.1. A small OpenPGP card FAQCHV Card Holder Verification, commonly followed by a number denoting which CHV is meant. The OpenPGP card uses three CHVs: CHV1, CHV2, CHV3. They are often also referenced as PIN 1, PIN2, PIN 3. CHV3 is used as the so called Admin PIN (which is sometimes also called S(ecurity)O(fficer) PIN).
PC/SC Personal computer/Smart Card. The standard framework for Smart Card access on Windows Platforms (included in Windows2000). There are also implementations for GNU/Linux and other Free OSes (i.e. pcsclite).
CCID Chip Card Interface Description. The specification for the USB device class used for chip card readers is 11 (0x0B).
OpenPGP OpenPGP is a non-proprietary protocol for encrypting email using public key cryptography. It is based on PGP as originally developed by Phil Zimmermann. The OpenPGP protocol defines standard formats for encrypted messages, signatures, and certificates for exchanging public keys.
diff --git a/misc/howtos.gnupg.org/card-howto/en/smartcard-howto.txt b/misc/howtos.gnupg.org/card-howto/en/smartcard-howto.txt
index fd62399..0723ea9 100644
--- a/misc/howtos.gnupg.org/card-howto/en/smartcard-howto.txt
+++ b/misc/howtos.gnupg.org/card-howto/en/smartcard-howto.txt
@@ -1,1294 +1,1294 @@
How to use the Fellowship Smartcard
The GnuPG Smartcard HOWTO
Rebecca Ehlers
Thorsten Ehlers
Werner Koch
Matthias Kirschner
Copyright 2005 Free Software Foundation Europe e.V.
This file is free software; as a special exception the authors give
unlimited permission to copy and/or distribute it, with or without
modifications, as long as this notice is preserved. This file is
distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY, to the extent permitted by law; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
June 29, 2006
_________________________________________________________________
Table of Contents
[1]1. Introduction
[2]1.1. The OpenPGP card
[3]2. Installation for GNU/Linux
[4]2.1. Prerequisites
[5]2.1.1. Installation of GnuPG
[6]2.2. Required Hardware
[7]2.2.1. A List of tested Readers
[8]2.3. Installation of Card Reader
[9]2.3.1. CCID (Chip Card Interface Description)
[10]2.3.2. PC/SC (Personal computer/Smart Card)
[11]3. Administrating the Card
[12]3.1. Looking at the card
[13]3.1.1. Describing the output
[14]3.2. Managing PINs
[15]3.2.1. General Information about PINs
[16]3.2.2. PIN operations
[17]3.3. Initialising the card
[18]3.3.1. Personalising the card
[19]3.3.2. Generating keys
[20]4. Daily usage
[21]4.1. Signing and encrypting files
[22]4.2. Signing and encrypting mails
[23]5. Advanced Features
[24]5.1. Moving an existing key to the card
[25]5.2. Using the card only for subkeys
[26]5.2.1. What are Subkeys?
[27]5.2.2. Moving a Subkey to the Card
[28]A. Appendix
[29]A.1. A small OpenPGP card FAQ
[30]Glossary
[31]Further resources
Chapter 1. Introduction
Table of Contents
[32]1.1. The OpenPGP card
With GnuPG everybody has the chance to secure his communication.
To work with GnuPG on different machines (private PC, at work, with
laptop etc.) the secret key has to be present on every machine.
Distributing the secret key to a lot of different machines does not
support its secrecy. Especially at work where other peple have root
access on your machine it is not save to store your secret key.
Starting with version 1.3.3 GnuPG supports smart cards to save your
keys.
This Howto describes how to use GnuPG with a smart card distributed to
[33]fellows of the [34]Free Software Foundation Europe.
In general cards that implement the [35]OpenPGP card specification in
version 1.0 or higher are supported by GnuPG.
1.1. The OpenPGP card
The OpenPGP Card is a smart card (standard size; ISO 7816-4,-8
compatible). Features of this card are:
* 3 independent 1024 bit RSA keys
(signing,encryption,authentication).
* Key generation on card or import of existing keys.
* Signature counter.
* Data object to store an URL to access the full OpenPGP public key.
* Data objects for card holder name etc.
* Data object for login specific data.
* Length of PIN between 6 and 254 characters; not restricted to
numbers.
* T=1 protocol; compatible with most readers.
* Specification freely available and usable without any constraints.
* Reasonably priced.
Chapter 2. Installation for GNU/Linux
Table of Contents
[36]2.1. Prerequisites
[37]2.1.1. Installation of GnuPG
[38]2.2. Required Hardware
[39]2.2.1. A List of tested Readers
[40]2.3. Installation of Card Reader
[41]2.3.1. CCID (Chip Card Interface Description)
[42]2.3.2. PC/SC (Personal computer/Smart Card)
Since version 1.3.90 GnuPG supports smart cards by default.
2.1. Prerequisites
Please make sure that libusb is available prior to building GnuPG. It
can be obtained from [43]http://prdownloads.sourceforge.net/libusb. On
Debian GNU/Linux a simple apt-get install libusb-dev should be
sufficient.
If you are not using an USB reader please also install libpcsclite and
libpcsclite-dev. On Debian GNU/Linux a simple apt-get install
libpcsclite libpcsclite-dev should be sufficient.
If your reader is a native USB device and supports the CCID (Chip Card
Interface Description) specification it is directly supported by
GnuPG.
Most USB readers today still behave like serial readers. In this case
you need the kernel module pl2303 to access the reader. This module is
a "USB Serial Driver" which can be found under Device
Drivers->USB-Support->USB Serial Converter Support->USB Prolitic 2303
in the 2.6 kernel configuration. This module makes sure that the
proprietary reader protocol is translated to a standard protocol.
2.1.1. Installation of GnuPG
Without an installation of GnuPG the OpenPGP card will be of little
use. So, please, go ahead and install it.
GnuPG can be downloaded from
[44]http://www.gnupg.org/download/index.html. Please use the recent
stable version.
After downloading and patching the sources GnuPG is installed with the
usual ./configure, make, make install. For further information please
refer to the installation instructions shipped with GnuPG.
Note
If you are running Debian GNU/Linux you can also build your own Debian
package with dh_make and debuild in the source directory. After that
you can install it the usual way with dpkg -i gnupg-version.deb
If you are using the 1.9 branch of GnuPG and plan to use the PC/SC
driver you should now install the software to make sure that the pcsc
wrapper binary will be available at the right place.
2.2. Required Hardware
First you need an OpenPGP compatible smart card which can, for
example, be obtained by [45]becoming a fellow of the [46]Free Software
Foundation Europe.
Card readers (NOT those used for flash memory cards) can be obtained
from computer stores (e.g.
- [47]http://www.kernelconcepts.de/products/security-en.shtml).
+ [47]https://www.floss-shop.de/en/security-privacy/).
2.2.1. A List of tested Readers
Please note that the USB device class for USB readers is 11 (or 0x0B
in hex).
SCM Microsystems SCR335
[scr335-small.jpg]
This is a small USB reader (CCID; 65*45*8mm) supported by GnuPG
directly as well as by pcsclite. This very device is actually the
first reader supported by GnuPG and the reason for the internal CCID
driver as no CCID driver was available at that time.
SCM Microsystems SPR532
[spr532-small.jpg]
This is a USB (CCID)/serial reader with a numerical keypad and three
extra buttons. The pinpad may be used to securely enter the PIN
without using the attached computer (since GnuPG 2.0.1). Only USB has
been tested.
Towitoko Chipdrive micro
[chipdrive-small.jpg]
This reader comes in two types: serial and USB. Both readers are very
similar and of the same size (65*45*8mm). As far as we know these
readers are no longer manufactured have been replaced by the SCR335
from SCM Microsystems.
Omnikey Cardman 3121 (and 2020)
This USB card reader supports CCID and PC/SC. The older Omnikey
Cardman 2020 is no longer produced. The newer reader has not been
tested, but Omnikey says that the two readers are compatible.
Omnikey Cardman 3111 (and 2010)
[cm2010-small.jpg]
This serial card reader supports PC/SC. The older Omnikey Cardman 2010
(photo) is out of production. The serial version of this reader has
not yet been tested.
Omnikey Cardman 5121
[cm5121-small.jpg]
This USB card reader is supported by PC/SC as well as by GnuPG's
internal driver. This is actual a dual reader with a second device to
access RFID tokens; this is supported by the forthcoming librfid..
Cherry XX44 USB keyboard
[cherry-XX44-small.jpg]
This is an USB keyboard with integrated CCID card reader. It is
supported by PC/SC as well as be GnuPG's internal driver. The mueric
keyblock may be used to securely enter the PIN without using the
attached computer (since GnuPG 2.0.3).
Kobil KAAN Advanced
[kaanadv-small.jpg]
This USB card reader is supported by PC/SC as well as by GnuPG's
internal driver. The pinpad may be used to securely enter the PIN
without using the attached computer (since GnuPG 2.0.1).
Omnikey CardMan 4040
[cm4040-small.jpg]
This is a CardBus (PCMICA) reader to be used with Laptops. The SVN
version of GnuPG supports this reader trough its internal driver.
There is no free PC/SC support. A recent Linux version (2.6.15.3) is
required. Very handy and useful devices so you can expect any problems
to be solved fast.
Athena ASE drive IIIe
[athena_asedrive-small.jpg]
This is a compact reader with USB or serial interface. It works fine
with PC/SC (pcscd, libasedrive-usb or libasedrive-serial Debian
packages).
Omnikey Cardman 6121
[cm6121-small.jpg]
This is a CCID reader for ID-000 sized cards. It works fine with
GnuPG's internal driver and should also work with PC/SC. If you want
to cut a full sized card down to ID-000 format, take care to remove
all burr and round the edges a bit. This is in particular important so
that you are able to remove the card using the tiny blue lever.
2.3. Installation of Card Reader
Two standard protocols are used by GnuPG to access card readers.
2.3.1. CCID (Chip Card Interface Description)
The driver to access CCID cards is built into GnuPG. This driver will
be used by default.
To use this driver follow the instructions and make sure you have
sufficient permission (see below) to access the USB device for reading
and writing.
With udev (preferred installation)
First of all, you will need to download two files for udev and copy
them to the udev configuration directories, in order to let it
identify your card reader:
* [48]gnupg-ccid.rules
* [49]gnupg-ccid
Now, open a terminal and become root (you will be asked for your root
password):
archi@foobar:~ > su -
On Ubuntu systems, you should run (and then you will be asked for the
user password):
archi@foobar:~ > sudo su -
Then you will have to move the files from the directory you have saved
them to, to the udev configuration directories:
# cd /home/directory/where/you/saved/the/file (change for the right path)
# cp gnupg-ccid.rules /etc/udev/gnupg-ccid.rules
# cp gnupg-ccid /etc/udev/scripts/gnupg-ccid
# chmod +x /etc/udev/scripts/gnupg-ccid
# ln -s /etc/udev/gnupg-ccid.rules /etc/udev/rules.d/gnupg-ccid.rules
All the configuration files are in the right place and with the right
permissions by now.
You will now create a group scard, give this group permission to
access the smart card reader, and include the users who should have
access to the card reader to this group.
# addgroup scard
# addgroup yourusername scard (change for the right username)
# exit (to logout the root user)
With hotplug (deprecated in modern systems)
The described hotplugging mechanism assigns permission for all CCID
devices to the users in scard group.
Create the following two files. The first file is a mapping file which
decides on the script to run when detecting a CCID device. The second
file is the script that should be run if a device with the matching
parameters is plugged in. This script is the one to actually assign
the permissions.
/etc/hotplug/usb/gnupg-ccid.usermap
# The entries below are used to detect CCID devices and run a script
#
# USB_MATCH_VENDOR 0x0001
# USB_MATCH_PRODUCT 0x0002
# USB_MATCH_DEV_LO 0x0004
# USB_MATCH_DEV_HI 0x0008
# USB_MATCH_DEV_CLASS 0x0010
# USB_MATCH_DEV_SUBCLASS 0x0020
# USB_MATCH_DEV_PROTOCOL 0x0040
# USB_MATCH_INT_CLASS 0x0080
# USB_MATCH_INT_SUBCLASS 0x0100
# USB_MATCH_INT_PROTOCOL 0x0200
#
# script match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi
# bDeviceClass bDeviceSubClass bDeviceProtocol
# bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info
#
# flags V P Bcd C S Prot Clas Sub Prot Info
#
# Generic CCID device
gnupg-ccid 0x0080 0x0 0x0 0x0 0x0 0x0 0x0 0x00 0x0B 0x00 0x00 0x00000000
# SPR532 is CCID but without the proper CCID class
gnupg-ccid 0x0003 0x04e6 0xe003 0x0 0x0 0x0 0x0 0x00 0x0B 0x00 0x00 0x00000000
# SCR33x is CCID but without the proper CCID class
gnupg-ccid 0x0003 0x04e6 0x5115 0x0 0x0 0x0 0x0 0x00 0x0B 0x00 0x00 0x00000000
script states the script that should be run if a device matching the
parameters is plugged in via USB.
match_flags is one of the given USB_MATCH_XXX options. The idVendor
and the idProduct can be figured out by calling lsusb. The output
looks something like this:
archi@foobar:~ > lsusb
Bus 001 Device 009: ID 04e6:5115 SCM Microsystems, Inc.
The values given behind ID are idVendor:idProduct and with a leading
0x could be used in gnupg-ccid.usermap in combination with
USB_MATCH_VENDOR or USB_MATCH_PRODUCT.
/etc/hotplug/usb/gnupg-ccid
#!/bin/bash
#
# taken from libgphoto2
#
# Sets up newly plugged in card reader so that only members of the
# group can access it
GROUP=scard
# can access it from user space. (Replace scard with the name of the
# group you want to have access to the card reader.)
#
# Note that for this script to work, you'll need all of the following:
# a) a line in the file /etc/hotplug/gnupg-ccid.usermap that corresponds
# to the card reader you are using.
# b) a group "scard" where all users allowed access to the
# card reader are listed
# c) a Linux kernel supporting hotplug and usbdevfs
# d) the hotplug package (http://linux-hotplug.sourceforge.net/)
#
# In the usermap file, the first field "usb module" should be named
# "gnupg-ccid" like this script.
#
if [ "${ACTION}" = "add" ] && [ -f "${DEVICE}" ]
then
chmod o-rwx "${DEVICE}"
chgrp "${GROUP}" "${DEVICE}"
chmod g+rw "${DEVICE}"
fi
This script changes the permissions and the ownership of a USB device
under /proc/bus/usb to grant acces to this device to users in the
specified group. The group in this example is scard. ACTION and DEVICE
are passed via the hotplug mechanism.
Note
Do not forget to run chmod +x on the script.
You should also create the group scard and then add the users to
access the card reader to the group. This is done by the following
commands: addgroup scard and addgroup
scard.
Note
Brian Gough made the following remark: The
hotplug package in Debian woody requires all the numbers in
gnupg-ccid.usermap to have a 0x prefix otherwise it gives an
"unparseable line" error and the i.e. gnupg-ccid 0x0003 0x04e6 0xe003
0x0 0x0 0x0 0x0 0x00 0x0B 0x00 0x00 0x00000000 instead of gnupg-ccid
0x0003 0x04e6 0xe003 0 0 0 0 0x00 0x0B 0x00 0x00 0x00000000. After
installing the modified file call update-usb.usermap.
With usbdevfs
Please make sure that you can mount a USB device. This can be achieved
by accessing the USB stack via libusb through the usbfs (USB
filesystem). If you are using USB < 2.0 the filesystem is called
usbdevfs.
To accomplish this goal please add the following line to your
/etc/fstab.
/etc/fstab
none /proc/bus/usb usbfs defaults,user 0 0
To make sure that a specific user has read and write access to the USB
device add devuid=[user id] to the defaults, user options. With
devgid=[group id] access will be granted to the given group.
This approach creates a major security problem. The owner of the files
has full permissions to ALL connected USB devices. It does not matter
what kind of device is connected. Therefore it is strongly suggested
to use the hotplug method.
2.3.2. PC/SC (Personal computer/Smart Card)
TODO
To use PC/SC make sure you disable CCID by passing the --disable-ccid
option to GnuPG.
Note
You can easily check your installation by inserting the card in the
card reader and entering gpg --card-status (more about this command in
[50]Chapter 3, Administrating the Card).
Chapter 3. Administrating the Card
Table of Contents
[51]3.1. Looking at the card
[52]3.1.1. Describing the output
[53]3.2. Managing PINs
[54]3.2.1. General Information about PINs
[55]3.2.2. PIN operations
[56]3.3. Initialising the card
[57]3.3.1. Personalising the card
[58]3.3.2. Generating keys
Warning
Whenever your are asked to enter a PIN make sure you know which PIN is
meant. There are two PINs for the card - the PIN and the AdminPIN.
Please make sure you do not mix them up.
Note
During the writing of this HowTo it seemed that every once in a while
GnuPG did not want to talk with the card reader. We were quite sure we
have not changed anything in the configuration but for some reason it
just did not work. Werner knows this problem and it will hopefully
soon be fixed. Note that we never encountered this problem with Linux
kernels 2.4.x - only with most 2.6 kernels.
This phenomenom occurs when the card reader has been in use for quite
some time. It might help to re-plug the reader.
The error message displayed looks like this:
gpg: ccid_transceive failed: (0x1000a)
gpg: apdu_send_simple(0) failed: card I/O error
3.1. Looking at the card
To check if your card (and installation) is working please put your
OpenPGP card in the reader and run gpg --card-status. For an empty
card the output should look like this:
archi@foobar: > gpg --card-status
Application ID ...: D2760001240101010001000000490000
Version ..........: 1.1
Manufacturer .....: PPC Card Systems
Serial number ....: 00000049
Name of cardholder: [not set]
Language prefs ...: de
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Private DO 1 .....: [not set]
Private DO 2 .....: [not set]
Signature PIN ....: forced
Max. PIN lengths .: 254 254 254
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: [not set]
Encryption key....: [not set]
Authentication key: [not set]
General key info..: [none]
The information displayed is the standard output for the Fellowship
smartcard we are using. Cards from other manufacturers might produce a
different output.
3.1.1. Describing the output
Note
The output depends on manufacturer and specification.
Application ID
The manufacture's ID. This includes the type of the card, the
implemented version of the specification, the manufacturer and
the serial number. This is a unique identifier for any card.
Version
The used OpenPGP specification.
Manufacturer
The card's manufacturer.
Serial number
A unique number for all cards from this manufacturer.
Name of cardholder
The holder of this card. Only plain ASCII characters are
Allowed here. gpg does not use this field.
Language prefs
The card holder's language preferences. gpg ignores this value.
Sex
Male or female. gpg ignores this value.
URL of public key
Used by the fetch command of gpg --edit-card. It may contain an
URL to be used to retrieve the public key.
Login data
This field may be used to store the account name of the card
holder. It may be used for login purposes. gpg does not enforce
any match of this name with a name used in the key. See the
source (app-openpgp.c) for some special features of the
login-name field.
Private DO 1
This is a field reserved for arbitrary data.
Private DO 2
This is a field reserved for arbitrary data.
Signature PIN
When set to "forced", gpg requests the entry of a PIN for each
signature operation. When set to "non forced", gpg may cache
the PIN as long as the card has not been removed from the
reader.
Max. PIN lengths
This field is unchangeable. The values are put on the card
right after personalisation - this is the moment after the chip
has been glued on the card.
PIN retry counter
This field saves how many tries still are left to enter the
right PIN. They are decremented whenever a wrong PIN is
entered. They are reset whenever a correct AdminPIN is entered.
The first and second PIN are for the standard PIN. gpg makes
sure that the two numbers are synchronized. The second PIN is
only required due to peculiarities of the ISO-7816 standard;
gpg tries to keep this PIN in sync with the first PIN. The
third PIN represents the retry counter for the AdminPIN.
Signature counter
This number keeps track of the signatures performed with the
stored key. It is only reset if a new signature key is created
on or imported to the card.
Signature key
This key is commonly used as the primary OpenPGP key.
Encryption key
This key is commonly used as an encryption subkey.
Authentication key
This key is not used by gpg at all. Other tools like PAM
modules or ssh use this key for authentication services.
General key info
This primary user ID is shown if the corresponding public
OpenPGP key is available.
3.2. Managing PINs
3.2.1. General Information about PINs
A new card has the following default PINs stored. The AdminPIN's value
is 12345678. The normal PIN is 123456. Please note that the second PIN
is two digits shorter.
You might have received a card with a few data fields already
personalized (e.g. the FSFE Fellowship card). Please check the
documentation which comes with this card to see whether the default
PINs are really to be used or from where to get the actual PINs. Often
the AdminPIN is send by separate mail.
If a wrong PIN has been entered three times in a row the card will be
blocked. It can be unblocked with the AdminPIN.
Warning
It is also important to know that entering a wrong AdminPIN three
times in a row destroys(!) the card. There is no way to unblock the
card when a wrong AdminPIN has been entered three times.
3.2.2. PIN operations
To access the PIN operations enter gpg --change-pin. Different options
for PIN management will be displayed. To select a command enter the
number displayed in front of the command.
Changing PIN
You are first asked to enter the current PIN. Afterwards you are asked
to enter the new PIN. Then you are asked to re-enter the new PIN. The
cursor will not move forward to indicate your typing.
The PIN has been successfully changed. The AdminPIN is not affected by
these changes.
Unblocking PIN
Use this command to unblock a blocked PIN.
First you are asked for the AdminPIN and then to enter and re-enter a
new PIN. The AdminPIN is not affected by this procedure.
Please note that an AdminPIN cannot be unblocked.
Changing AdminPIN
Changing the AdminPIN is the same procedure as changing the PIN. Enter
the current AdminPIN. Then enter a new AdminPIN and re-enter it. The
normal PIN is not affected by these changes.
PINs can also be managed via --card-edit commands.
3.3. Initialising the card
To follow the instructions in this chapter make sure that the card
reader works and the card can be accessed ([59]Chapter 3,
Administrating the Card, command gpg --card-status).
To initialise a card enter gpg --card-edit. Basic information about
the card is shown. The output is the same as gpg --card-status. The
difference is that the output is now followed by a command prompt.
To get a list of all commands available enter help.
Command> help
quit quit this menu
admin show admin commands
help show this help
list list all available data
fetch fetch the key specified in the card URL
passwd menu to change or unblock the PIN
These commands are not very useful because data stored on the card
cannot be changed.
For a list of useful commands enter admin and then help.
Command> admin
Admin commands are allowed
Command> help
quit quit this menu
admin show admin commands
help show this help
list list all available data
name change card holder's name
url change URL to retrieve key
fetch fetch the key specified in the card URL
login change the login name
lang change the language preferences
sex change card holder's sex
cafpr change a CA fingerprint
forcesig toggle the signature force PIN flag
generate generate new keys
passwd menu to change or unblock the PIN
3.3.1. Personalising the card
Save the name of the card owner on the card. Technically this is not
required but it will prove useful if more than one card is around.
Enter name and follow the prompts. You are seperately asked for sur-
and given name. After entering the data you are asked for the
AdminPIN.
Note
The name is stored in an ISO format. This format distinguishes between
the different name parts and is also used for machine readable
passports.
In general the AdminPin is cached through a session. So if you do not
remove the card you will not be asked again to enter it. As always
there are exceptions to this rule.
If you like you can also enter the language you prefer (lang) and the
sex (sex). gpg does not use this information so you might want to omit
it.
3.3.2. Generating keys
To generate a key on the card enter generate. You will be asked if you
would like to make an off-card copy of the encryption key. It is
useful to say yes here.
Note
Without a backup you will not be able to access any data you encrypted
with the card if it gets lost or damaged.
Command> generate
Make off-card backup of encryption key? (Y/n)
If a key exists on the card a security question has to be answered to
avoid accidental overwriting.
gpg: NOTE: keys are already stored on the card!
Replace existing keys? (y/N)
The whole process of key generation looks like this.
Note
You might be asked for the PINs at different times.
Command> generate
Make off-card backup of encryption key? (Y/n) Y
gpg: 3 Admin PIN attempts remaining before card is permanently locked
Admin PIN
PIN
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) "
Real name: Archibald Goodwin
Email address: archi@foobar.example
Comment: tester
You selected this USER-ID:
"Archibald Goodwin (tester) "
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
gpg: generating new key
gpg: please wait while key is being generated ...
gpg: key generation completed (45 seconds)
gpg: signatures created so far: 0
gpg: signatures created so far: 0
You need a Passphrase to protect your secret key.
+++++
..+++++
gpg: NOTE: backup of card key saved to `/home/archi/.gnupg/sk_26D728A8F09033F1.
gpg'
gpg: signatures created so far: 2
gpg: signatures created so far: 2
gpg: generating new key
gpg: please wait while key is being generated ...
gpg: key generation completed (25 seconds)
gpg: signatures created so far: 4
gpg: signatures created so far: 4
gpg: key FF19F200 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub 1024R/FF19F200 2005-03-05
Key fingerprint = 884B 9142 F645 1A72 4B92 EB94 DF80 CCEF FF19 F200
uid Archibald Goodwin (The Tester)
sub 1024R/F09033F1 2005-03-05
sub 1024R/3239D981 2005-03-05
Six signing operations are done during the creation of the public and
secret key (one self-signature to bind the name to the key and two
key-binding signatures for each key). Future versions of gpg might
just need three signing operations.
Command> list
Application ID ...: D2760001240101010001000000490000
Version ..........: 1.1
Manufacturer .....: PPC Card Systems
Serial number ....: 00000049
Name of cardholder: Archibald Goodwin
Language prefs ...: de
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: not forced
Max. PIN lengths .: 254 254 254
PIN retry counter : 3 3 3
Signature counter : 6
Signature key ....: 884B 9142 F645 1A72 4B92 EB94 DF80 CCEF FF19 F200
created ....: Sat Mar 5 19:56:42 2005 CET
Encryption key....: 31C1 2190 FCF1 A684 5AF9 D719 26D7 28A8 F090 33F1
created ....: Sat Mar 5 19:56:43 2005 CET
Authentication key: 811F C45F 911A C15A F6DC 5BD6 58BA B8D1 3239 D981
created ....: Sat Mar 5 19:57:19 2005 CET
General key info..:
pub 1024R/FF19F200 2005-03-05 Archibald Goodwin (The Tester)
The card is now ready for use.
Note
Please save the backup key, transfer it to a different medium and
store it in a safe place.
It is important that you delete the copy of the key from the hard
disk, too. The best choices here are tools like shred from the GNU
coreutils package or wipe to make sure that the original content gets
overwritten.
A key can also be stored as a printout. Normally you do not need it,
but in case your card breaks and the backup copy is not available you
still have the chance to re-enter the key. gpg --enarmor may be used
to convert the backup key into a printable format.
Chapter 4. Daily usage
Table of Contents
[60]4.1. Signing and encrypting files
[61]4.2. Signing and encrypting mails
Now you should be able to do all the stuff with your smartcard, which
you have previously done with your usual GnuPG setup.
4.1. Signing and encrypting files
You can sign, de- and encrypt files the usual way. The only difference
is, that if you are asked for your passphrase you have to enter the
PIN of the smartcard.
4.2. Signing and encrypting mails
Of course you can also use your smartcard to sign and encrypt mails.
The only difference is, same as signing and encrypting files, that you
have to type in the PIN instead of your passphrase.
Chapter 5. Advanced Features
Table of Contents
[62]5.1. Moving an existing key to the card
[63]5.2. Using the card only for subkeys
[64]5.2.1. What are Subkeys?
[65]5.2.2. Moving a Subkey to the Card
Warning
Please make sure to make a backup of you key before experimenting with
any of the following commands.
5.1. Moving an existing key to the card
Theoretically you can move any existing key to the card. It does not
make a difference if you want to import a primary key or a subkey.
Practically there are some restrictions. First, the card does not
support DSA keys. Second, only 1024 bit RSA keys are currently
supported by the card.
Use the keytocard command to move the key. gpg will do the checking
for you and will also tell you if it is possible to move the key or
not.
archi@foobar:~ > gpg --edit-key 4A1D3D53
gpg (GnuPG) 1.4.0; Copyright (C) 2004 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Secret key is available.
pub 1024R/4A1D3D53 created: 2005-03-05 expires: never usage: CS
trust: ultimate validity: ultimate
[ultimate] (1). Archibald Goodwin (2) (The Tester)
Command> toggle
sec 1024R/4A1D3D53 created: 2005-03-05 expires: never
(1) Archibald Goodwin (2) (The Tester)
Command> keytocard
Really move the primary key? (y/N) y
Signature key ....: 5140 AA49 39A0 01D1 29A9 9042 28D4 524A 2AB4 B711
Encryption key....: E684 AB4A AD27 DEC3 986E C90F 2AEB 898F F651 8D6B
Authentication key: AF53 357B 5E13 9D2A 4E14 AEB7 07A6 51FA 53CD 8E68
Please select where to store the key:
(1) Signature key
(3) Authentication key
Your selection? 3
gpg: WARNING: such a key has already been stored on the card!
Replace existing key? (y/N) y
You need a passphrase to unlock the secret key for
user: "Archibald Goodwin (2) (The Tester) "
1024-bit RSA key, ID 4A1D3D53, created 2005-03-05
gpg: 3 Admin PIN attempts remaining before card is permanently locked
Admin PIN
sec 1024R/4A1D3D53 created: 2005-03-05 expires: never
card-no: 0001 00000049 // Indicating the key has been move
d to the card.
(1) Archibald Goodwin (2) (The Tester)
5.2. Using the card only for subkeys
Using the card this way is suggested if you already have a key with a
lot of key signatures.
5.2.1. What are Subkeys?
Subkeys are keys to use in every day life. They are bound to your
private key and are used for signing and decrypting. They normally
have a set expiration date. Even overlapping subkeys for a single
private key are possible. However, there is one limitation to a full
featured private key - subkeys cannot be used for key signing.
Therefore they are a perfect alternative to use on a smartcard.
5.2.2. Moving a Subkey to the Card
The card does not support DSA keys. Even if you are using a RSA key
you might encounter problems. The cards available at the moment only
support 1024 bit keys.
The suggestion is to use the key on the card only for signing and
decrypting but NOT for key signing.
Note
By keeping the primary key offline it is not exposed to remote
attacks. gpg has offered this feature for many years. Werner in fact
has been using this method for his 5B0358A2 key since 1999. Using this
method was not easy at first since some OpenPGP implementations and
the keyservers were not able to cope with signing subkeys. Times have
changed and signing subkeys is state of the art today.
Warning
Secret keys stored on a computer accessible via network can be
compromised.
Initialise your card but do not call generate - call quit. Start gpg
calling --edit-key . Now enter addcardkey and make your
decision to either create a signature, an encryption or an
authentication key.
archi@foobar:~ > gpg --edit-key FF19F200
gpg (GnuPG) 1.4.0; Copyright (C) 2004 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Secret key is available.
pub 1024R/FF19F200 created: 2005-03-05 expires: never usage: CS
trust: ultimate validity: ultimate
sub 1024R/F09033F1 created: 2005-03-05 expires: never usage: E
sub 1024R/3239D981 created: 2005-03-05 expires: never usage: A
[ultimate] (1). Archibald Goodwin (The Tester)
Command> addcardkey
Signature key ....: 884B 9142 F645 1A72 4B92 EB94 DF80 CCEF FF19 F200
Encryption key....: 31C1 2190 FCF1 A684 5AF9 D719 26D7 28A8 F090 33F1
Authentication key: 811F C45F 911A C15A F6DC 5BD6 58BA B8D1 3239 D981
Please select the type of key to generate:
(1) Signature key
(2) Encryption key
(3) Authentication key
Your selection? 2
gpg: WARNING: such a key has already been stored on the card!
Replace existing key? (y/N) y
gpg: 3 Admin PIN attempts remaining before card is permanently locked
Admin PIN
PIN
Key is protected.
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y
Really create? (y/N) y
gpg: existing key will be replaced
gpg: please wait while key is being generated ...
gpg: key generation completed (27 seconds)
gpg: signatures created so far: 6
gpg: signatures created so far: 6
pub 1024R/FF19F200 created: 2005-03-05 expires: never usage: CS
trust: ultimate validity: ultimate
sub 1024R/F09033F1 created: 2005-03-05 expires: never usage: E
sub 1024R/3239D981 created: 2005-03-05 expires: never usage: A
sub 1024R/F6518D6B created: 2005-03-05 expires: never usage: E
[ultimate] (1). Archibald Goodwin (The Tester)
First create a signing key. If this kind of key already exists on the
card, a security question has to be answered. Run save to commit the
changes to the card. The key on the card will not be removed if you do
not save the changes. You can create another subkey by again calling
addcardkey. Choose the encryption key and proceed as explained.
Note
gpg will always use the latest created key of a given type.
There is no direct way to create a backup key of the card's decryption
key like it is done with the generate command.
Note
Make a copy of your secret key before running the following commands.
Otherwise the whole procedure will be pointless.
A few steps more will help you to achieve this goal. First create a
regular RSA subkey of 1024 bit length using the addkey command. Then
select this new key and run keytocard. gpg transfers the key to the
card and replaces the existing secret key with a stub.
Appendix A. Appendix
Table of Contents
[66]A.1. A small OpenPGP card FAQ
[67]Glossary
[68]Further resources
A.1. A small OpenPGP card FAQ
A.1.1. [69]If I'm correctly informed GnuPG and smartcards use 1024 Bit
RSA. Some say the security level of RSA-1024 is comparable too
about 80 Bit symmetric key and cannot be regarded as highly
secure.
A.1.2. [70]Where do I get a reader?
A.1.3. [71]How do I use the cryptocard on MacOSX?
A.1.4. [72]I am having problems, where do I get further help?
A.1.1.
If I'm correctly informed GnuPG and smartcards use 1024 Bit RSA. Some
say the security level of RSA-1024 is comparable too about 80 Bit
symmetric key and cannot be regarded as highly secure.
The quality and security of the implementation and the entire
environment and not the length of the key protect the secret key
against a compromise by any non-physical attack.
2048 bit RSA is possible but at the moment far too expensive. The
specification allows for 2048 Bit RSA cards. Feel free to build one.
A.1.2.
Where do I get a reader?
Currently we know that you may order card readers from
- [73]kernelconcepts. The website is only in German, but you can order
+ [73]FLOSS-Shop. The website is only in German, but you can order
the "USB Chip-Karten Lesegeraet SCM SCR-335" for 29,00 EUR from all
over Europe; either by prepayment via bank transfer or paypal. You
- have to sent your orders via email to <[74]order@kernelconcepts.de>.
+ have to sent your orders via email to <[74]order@floss-shop.de>.
If you have questions considering the order you can contact
- <[75]info@kernelconcepts.de> in English or German.
+ <[75]info@floss-shop.de> in English or German.
In the UK, SCM card readers can be purchased online from
[76]http://www.crownhill.co.uk/.
A.1.3.
How do I use the cryptocard on MacOSX?
There is a description on
[77]http://www.py-soft.co.uk/~benjamin/download/mac-gpg/.
A.1.4.
I am having problems, where do I get further help?
If you need further help, please take a look at the [78]GnuPG mailing
lists.
Glossary
CHV
Card Holder Verification, commonly followed by a number
denoting which CHV is meant. The OpenPGP card uses three CHVs:
CHV1, CHV2, CHV3. They are often also referenced as PIN 1,
PIN2, PIN 3. CHV3 is used as the so called Admin PIN (which is
sometimes also called S(ecurity)O(fficer) PIN).
PC/SC
Personal computer/Smart Card. The standard framework for Smart
Card access on Windows Platforms (included in Windows2000).
There are also implementations for GNU/Linux and other Free
OSes (i.e. pcsclite).
CCID
Chip Card Interface Description. The specification for the USB
device class used for chip card readers is 11 (0x0B).
OpenPGP
OpenPGP is a non-proprietary protocol for encrypting email
using public key cryptography. It is based on PGP as originally
developed by Phil Zimmermann. The OpenPGP protocol defines
standard formats for encrypted messages, signatures, and
certificates for exchanging public keys.
Further resources
Online
[79]Canonical address of this document. .
Free Software Foundation Europe. [80]Fellowship of FSFE.
g10 Code. [81]The OpenPGP Card.
Olaf Kirch. [82]Smart Cards on Linux.
References
1. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2456468
2. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2456489
3. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2456320
4. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2456329
5. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2456428
6. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2503306
7. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2503342
8. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2503642
9. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2503652
10. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2504251
11. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#features
12. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2505522
13. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2505566
14. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2505886
15. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2505892
16. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2505933
17. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2506015
18. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2506118
19. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2506175
20. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507475
21. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507486
22. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2506860
23. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507402
24. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507414
25. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507429
26. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507440
27. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507460
28. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507278
29. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507283
30. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2508366
31. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2508441
32. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2456489
33. http://www.fsfe.org/
34. http://www.fsfeurope.org/
35. http://g10code.com/docs/openpgp-card-1.1.pdf
36. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2456329
37. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2456428
38. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2503306
39. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2503342
40. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2503642
41. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2503652
42. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2504251
43. http://prdownloads.sourceforge.net/libusb
44. http://www.gnupg.org/download/index.html
45. https://www.fsfe.org/join_us/
46. http://www.fsfeurope.org/
- 47. http://www.kernelconcepts.de/products/security-en.shtml
+ 47. https://www.floss-shop.de/en/security-privacy/
48. http://www.fsfe.org/en/content/download/17665/125518/file/gnupg-ccid.rules
49. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html
50. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#features
51. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2505522
52. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2505566
53. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2505886
54. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2505892
55. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2505933
56. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2506015
57. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2506118
58. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2506175
59. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#features
60. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507486
61. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2506860
62. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507414
63. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507429
64. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507440
65. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507460
66. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507283
67. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2508366
68. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2508441
69. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507296
70. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2507324
71. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2508313
72. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html#id2508338
- 73. http://www.kernelconcepts.de/products/security.shtml
- 74. mailto:order@kernelconcepts.de
- 75. mailto:info@kernelconcepts.de
+ 73. https://www.floss-shop.de/en/security-privacy/
+ 74. mailto:order@floss-shop.de
+ 75. mailto:info@floss-shop.de
76. file://localhost/home/wk/w/card-howto/build/smartcard-howto-single.html
77. http://www.py-soft.co.uk/~benjamin/download/mac-gpg/
78. http://www.gnupg.org/documentation/mailing-lists.html
79. http://www.gnupg.org/documentation/howtos.html#GnuPG-cardHOWTO
80. http://www.fsfe.org/
81. http://www.g10code.com/p-card.html
82. http://www.opensc.org/talks/linux-kongress03/linux-kongress03.pdf
diff --git a/misc/id/common/README b/misc/id/common/README
index 5afef41..4b6302d 100644
--- a/misc/id/common/README
+++ b/misc/id/common/README
@@ -1,2 +1,3 @@
Online references can be found at:
- http://xml.resource.org/public/rfc/bibxml3/
+ http://xml.resource.org/public/rfc/bibxml-rfcs/
+ http://xml.resource.org/public/rfc/bibxml3/
diff --git a/misc/id/openpgp-webkey-service/Makefile b/misc/id/openpgp-webkey-service/Makefile
index dad63f1..c1d2ce8 100644
--- a/misc/id/openpgp-webkey-service/Makefile
+++ b/misc/id/openpgp-webkey-service/Makefile
@@ -1,26 +1,27 @@
MD_EXAMPLE_FIX = '(defun org-md-example-block (example-block contents info) \
"with fixed indentation" \
(replace-regexp-in-string \
"^" " " \
(org-remove-indentation \
(org-export-format-code-default example-block info))))'
draft.txt, draft.xml: draft.org
- emacs --batch \
+ emacs23 --batch \
--eval "(require 'org)" \
--eval "(require 'ox-md)" \
--eval $(MD_EXAMPLE_FIX) \
--visit "draft.org" \
--eval "(org-md-export-to-markdown)"
+ sed -i 's/\*\*\(.*\):\*\*/"\1":/' draft.md
sed template.xml
sed tmp-abstract.md
sed tmp-middle.md
sed tmp-back.md
pandoc2rfc tmp-abstract.md tmp-middle.md tmp-back.md
pandoc2rfc -X tmp-abstract.md tmp-middle.md tmp-back.md
rm template.xml tmp-abstract.md tmp-middle.md tmp-back.md draft.md
diff --git a/misc/id/openpgp-webkey-service/draft-koch-openpgp-webkey-service-02.txt b/misc/id/openpgp-webkey-service/draft-koch-openpgp-webkey-service-02.txt
new file mode 100644
index 0000000..0ac9ab9
--- /dev/null
+++ b/misc/id/openpgp-webkey-service/draft-koch-openpgp-webkey-service-02.txt
@@ -0,0 +1,896 @@
+
+
+
+
+Network Working Group W. Koch
+Internet-Draft GnuPG Project
+Intended status: Informational October 5, 2016
+Expires: April 8, 2017
+
+
+ OpenPGP Web Key Service
+ draft-koch-openpgp-webkey-service-02
+
+Abstract
+
+ This specification describes a service to locate OpenPGP keys by mail
+ address using a Web service and the HTTPS protocol. It also provides
+ a method for secure communication between the key owner and the mail
+ provider to publish and revoke the public key.
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on April 8, 2017.
+
+Copyright Notice
+
+ Copyright (c) 2016 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Koch Expires April 8, 2017 [Page 1]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2
+ 3. Web Key Directory . . . . . . . . . . . . . . . . . . . . . . 2
+ 3.1. Key Discovery . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Web Key Directory Update Protocol . . . . . . . . . . . . . . 4
+ 4.1. The Submission Address . . . . . . . . . . . . . . . . . 5
+ 4.2. The Submission Mail . . . . . . . . . . . . . . . . . . . 6
+ 4.3. The Confirmation Request . . . . . . . . . . . . . . . . 6
+ 4.4. The Confirmation Response . . . . . . . . . . . . . . . . 8
+ 4.5. Policy Flags . . . . . . . . . . . . . . . . . . . . . . 8
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
+ 6.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 9
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
+ 8. Normative References . . . . . . . . . . . . . . . . . . . . 10
+ Appendix A. Sample Protocol Run . . . . . . . . . . . . . . . . 10
+ A.1. Sample Keys . . . . . . . . . . . . . . . . . . . . . . . 10
+ A.2. Sample Messages . . . . . . . . . . . . . . . . . . . . . 11
+ Appendix B. Changes Since -01 . . . . . . . . . . . . . . . . . 15
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
+
+1. Introduction
+
+ This memo describes a method to associate OpenPGP keys with a mail
+ address and how to look them up using a web service with a well-known
+ URI. In addition a mail based protocol is given to allow a client to
+ setup such an association and to maintain it.
+
+2. Notational Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. Web Key Directory
+
+ A major use case for OpenPGP is the encryption of mail. A common
+ difficulty of sending encrypted mails to a new communication partner
+ is to find the appropriate public key of the recipient. Unless an
+ off-channel key exchange has been done, there are no easy ways to
+ discover the required key. The common practice is to search the
+ network of public key servers for a key matching the recipient's mail
+ address. This practise bears the problem that the keyservers are not
+ able to give a positive confirmation that a key actually belongs to
+ the mail addresses given in the key. Further, there are often
+ several keys matching a mail address and thus one needs to pick a key
+
+
+
+Koch Expires April 8, 2017 [Page 2]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+ on good luck. This is clearly not a secure way to setup an end-to-
+ end encryption. Even if the need for a trusted key for an initial
+ mail message is relinquished, a non-authenticated key may be a wrong
+ one and the actual recipient would receive a mail which she can't
+ decrypt, due to the use of a wrong key.
+
+ Methods to overcome this problem are
+
+ o sending an initial unencrypted message with the public key
+ attached,
+
+ o using the OpenPGP DANE protocol to lookup the recipients key via
+ the DNS.
+
+ The first method has the obvious problems of not even trying to
+ encrypt the initial mail, an extra mail round-trip, and problems with
+ unattended key discovery.
+
+ The latter method works fine but requires that mail providers need to
+ set up a separate DNS resolver to provide the key. The
+ administration of a DNS zone is often not in the hands of small mail
+ installations. Thus an update of the DNS resource records needs to
+ be delegated to the ISP running the DNS service. Further, DNS
+ lookups are not encrypted and missing all confidentially. Even if
+ the participating MUAs are using STARTTLS to encrypt the mail
+ exchange, a DNS lookup for the key unnecessarily identifies the
+ local-part of the recipients mail address to any passive
+ eavesdroppers.
+
+ This memo specified a new method for key discovery using an encrypted
+ https connection.
+
+3.1. Key Discovery
+
+ Although URIs are able to encode all kind of characters,
+ straightforward implementations of a key directory may want to store
+ the "local-part" of a mail address directly in the file system. This
+ forbids the use of certain characters in the "local-part". To allow
+ for such an implementation method the URI uses an encoded form of the
+ "local-part" which can be directly mapped to a file name.
+
+ OpenPGP defines its User IDs, and thus the mail address, as UTF-8
+ strings. To help with the common pattern of using capitalized names
+ (e.g. "Joe.Doe@example.org") for mail addresses, and under the
+ premise that almost all MTAs treat the "local-part" case-insensitive
+ and that the "domain-part" is required to be compared case-
+ insensitive anyway, all upper-case ASCII characters in a User ID are
+ mapped to lowercase. Non-ASCII characters are not changed.
+
+
+
+Koch Expires April 8, 2017 [Page 3]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+ The so mapped "local-part" is hashed using the SHA-1 algorithm. The
+ resulting 160 bit digest is encoded using the Z-Base-32 method as
+ described in [RFC6189], section 5.1.6. The resulting string has a
+ fixed length of 32 octets. To form the URI, the scheme "https://" is
+ concatenated with the mapped "domain-part", the fixed string "/.well-
+ known/openpgpkey/hu/", and the above constructed 32 octet string.
+
+ For example the URI to lookup the key for Joe.Doe@Example.ORG is:
+
+ https://example.org/.well-known/openpgpkey/
+ hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q
+
+ (line has been wrapped for rendering purposes)
+
+ The HTTP GET method MUST return the binary representation of the
+ OpenPGP key for the given mail address. The key needs to carry a
+ User ID packet ([RFC4880]) with that mail address. Note that the key
+ may be revoked or expired - it is up to the client to handle such
+ conditions. To ease distribution of revoked keys, a server may
+ return revoked keys in addition to a new key. The keys are returned
+ by a single request as concatenated key blocks.
+
+ The server MUST accept the HTTP HEAD method to allow a client to
+ check for the existence of a key.
+
+ The server SHOULD return "application/octet-string" as the Content-
+ Type for the data but clients SHOULD also accept any other Content-
+ Type. The server MUST NOT return an ASCII armored version of the
+ key.
+
+4. Web Key Directory Update Protocol
+
+ To put keys into the key directory a protocol to automate the task is
+ desirable. The protocol defined here is entirely based on mail and
+ the assumption that a mail provider can securely deliver mail to the
+ INBOX of a user (e.g. an IMAP folder). Note that the same protocol
+ may also be used for submitting keys for use with OpenPGP DANE.
+
+ We assume that the user already created a key for her mail account
+ alice@example.org. To install the key at her provider's Web Key
+ Directory, she performs the following steps:
+
+ 1. She retrieves a file which contains one line with the mail
+ address used to submit the key to the mail provider. See below
+ for the syntax of that file. For a mail address at the domain
+ "example.org" the URI of the file is
+
+ https://example.org/.well-known/openpgpkey/submission-address
+
+
+
+Koch Expires April 8, 2017 [Page 4]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+ 2. She sends her key using SMTP (or any other transport mechanism)
+ to the provider using the submission address and key format as
+ specified by PGP/MIME.
+
+ 3. The provider checks that the received key has a User ID which
+ matches an account name of the provider.
+
+ 4. The provider sends an encrypted message containing a nonce and
+ the fingerprint of the key to the mail account of the user. Note
+ that a similar scheme is used by the well known caff(1) tool to
+ help with key signing parties.
+
+ 5. A legitimate user will be able to decrypt the message because she
+ created the key and is in charge of the private key. This step
+ verifies that the submitted key has actually been created by the
+ owner of the account.
+
+ 6. The user sends the decrypted nonce back to the submission address
+ as a confirmation that the private key is owned by her and that
+ the provider may now publish the key. Although technically not
+ required, it is suggested that the mail to the provider is
+ encrypted. The public key for this is retrieved using the key
+ lookup protocol described above.
+
+ 7. The provider receives the nonce, matches it with its database of
+ pending confirmations and then publishes the key. Finally the
+ provider sends a mail back to the user to notify her of the
+ publication of her key.
+
+ The message data structures used for the above protocol are specified
+ in detail below. In the following sections the string "WELLKNOWN"
+ denotes the first part of an URI specific for a domain. In the
+ examples the domain "example.org" is assumed, thus
+
+ WELLKNOWN := https://example.org/.well-known/openpgpkey
+
+ The term "target key" denotes the to be published key, the term
+ "submission key" the key associated with the submission-address of
+ the mail provider.
+
+4.1. The Submission Address
+
+ The address of the submission file is
+
+ WELLKNOWN/submission-address
+
+ The file consists of exactly one line, terminated by a LF, or the
+ sequence of CR and LF, with the full mail address to be used for
+
+
+
+Koch Expires April 8, 2017 [Page 5]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+ submission of a key to the mail provider. For example the content of
+ the file may be
+
+ key-submission-example.org@directory.example.org
+
+4.2. The Submission Mail
+
+ The mail used to submit a key to the mail provider MUST comply to the
+ PGP/MIME specification ([RFC3156], section 7), which states that the
+ Content-Type must be "application/pgp-keys", there are no required or
+ optional parameters, and the body part contains the ASCII-armored
+ transferable Public Key Packets as defined in [RFC4880], section
+ 11.1.
+
+ The mail provider MUST publish a key capable of signing and
+ encryption for the submission-address in the Web Key Directory or via
+ DANE. The key to be published MUST be submitted using a PGP/MIME
+ encrypted message ([RFC3156], section 4). The message MUST NOT be
+ signed (because the authenticity of the signing key has not yet been
+ confirmed). After decryption of the message at the mail provider a
+ single "application/pgp-keys" part, as specified above, is expected.
+
+4.3. The Confirmation Request
+
+ The mail provider sends a confirmation mail in response to a received
+ key publication request. The message MUST be sent from the
+ submission-address of the mail provider to the mail address extracted
+ from the target key. The message needs to be a PGP/MIME signed
+ message using the submission key of the provider for the signature.
+ The signed message MUST have two parts:
+
+ The first part MUST have "text" as its Content-Type and can be used
+ to explain the purpose of the mail. For example it may point to this
+ RFC and explain on how to manually perform the protocol.
+
+ The second part jMUST have "application/vnd.gnupg.wkd" as its
+ Content-Type and carry an OpenPGP encrypted message in ASCII Armor
+ format. The message MUST be encrypted to the target key and MUST not
+ be signed. After decryption a text file in the Web Key data format
+ must be yielded.
+
+ That data format consists of name-value pairs with one name-value
+ pair per LF or CR+LF terminated line. Empty lines are allowed and
+ will be ignored by the receiver. A colon is used to terminate a
+ name.
+
+ In a confirmation request the following names MUST be send in the
+ specified order:
+
+
+
+Koch Expires April 8, 2017 [Page 6]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+ o "type": The value must be "confirmation-request".
+
+ o "sender": This is the mailbox the user is expected to sent the
+ confirmation response to. The value must match the mailbox part
+ of the "From:" address of this request. Exactly one address MUST
+ be given.
+
+ o "address": The value is the addr-spec part of the target key's
+ mail address. The value SHOULD match the addr-spec part of the
+ recipient's address. The value MUST be UTF-8 encoded as required
+ for an OpenPGP User ID.
+
+ o "fingerprint": The value is the fingerprint of the target key.
+ The fingerprint is given in uppercase hex encoding without any
+ interleaving spaces.
+
+ o "nonce": The value is a string with a minimum length of 16 octets
+ and a maximum length of 64 octets. The string must entirely be
+ made up of random ASCII letters or digits. This nonce will be
+ sent back to the mail provider as proof that the recipient is the
+ legitimate owner of the target-key.
+
+ The receiver of that message is expected to verify the outer
+ signature and disregard the entire message if it can't be verified or
+ has not been signed by the key associated with the submission
+ address.
+
+ After the message as been verified the receiver decrypts the second
+ part of the message, checks that the "fingerprint" matches the target
+ key, checks that the "address" matches a User ID of the target key,
+ and checks the other constrains of the request format. If any
+ constraint is not asserted, or the fingerprint or User ID do not
+ match the target key, or there is no pending publication requests
+ (i.e. a mail recently sent o the submission address), the user MAY be
+ notified about this fake confirmation attempt.
+
+ In other cases the confirmation request is legitimate and the MUA
+ shall silently send a response as described in the next section.
+
+ The rationale for the outer signature used with this request is to
+ allow early detection of spam mails. This can be done prior to the
+ decryption step and avoids asking the user to enter a passphrase to
+ perform the decryption for a non-legitimate message. The use of a
+ simple encrypted attachment, instead of using PGP/MIME encryption, is
+ to convey the Content-Type of that attachment in the clear and also
+ to prevent automatic decryption of that attachment by PGP/MIME aware
+ clients. The MUA may in fact detect this confirmation request and
+ present a customized dialog for confirming that request.
+
+
+
+Koch Expires April 8, 2017 [Page 7]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+4.4. The Confirmation Response
+
+ A response to a confirmation request MUST only be send in the
+ positive case; there is no negative confirmation response. A mail
+ service provider is expected to cancel a pending key submission after
+ a suitable time without a confirmation. The mail service provider
+ SHOULD NOT retry the sending of a confirmation request after the
+ first request has been send successfully.
+
+ The user MUST send the confirmation response from her target mail
+ address to the "from" address of the confirmation request. The
+ message MUST be signed and encrypted using the PGP/MIME Combined
+ format ([RFC3156], section 6.2). The signing key is the target key
+ and the encryption key is the key associated with the provider's
+ submission address.
+
+ The Content-Type used for the plaintext message MUST also be
+ "application/vnd.gnupg.wkd". The format is the same as described
+ above for the Confirmation Request. The body must contain three
+ name-value pairs in this order:
+
+ o "type": The value must be "confirmation-response".
+
+ o "sender": The value must match the mailbox part of the "From:"
+ address of this response. Exactly one address MUST be given.
+
+ o "nonce": The value is the value of the "nonce" parameter from the
+ confirmation request.
+
+4.5. Policy Flags
+
+ For key generation and submission it is sometimes useful to tell the
+ client about certain properties of the mail provider in advance.
+ This can be done with a file at the URL
+
+ WELLKNOWN/policy
+
+ The file contains keywords and optioanlly values, one per line with
+ each line terminated by a LF or the sequence of CR and LF. Empty
+ lines and lines starting with a '#' character are considered comment
+ lines. A keyword is made up of lowercase letters, digits, hyphens,
+ or dots. An underscore is allowed as a name space delimiters; see
+ below. The first character must be a letter. Keywords which are
+ defined to require a value are directly followed by a colon and then
+ after optional white space the value. Clients MUST use case-
+ insensitive matching for the keyword.
+
+ Currently defined keywords are:
+
+
+
+Koch Expires April 8, 2017 [Page 8]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+ o "mailbox-only": The mail server provider does only accept keys
+ with only a mailbox in the User ID. In particular User IDs with a
+ real name in addition to the mailbox will be rejected as invalid.
+
+ o "dane-only": The mail server provider does not run a Web Key
+ Directory but only an OpenPGP DANE service. The Web Key Directory
+ Update protocol is used to update the keys for the DANE service.
+
+ o "auth-submit": The submission of the mail to the server is done
+ using an authenticated connection. Thus the submitted key will be
+ published immediately without any confirmation request.
+
+ More keywords will be defined in updates to this I-D. There is no
+ registry except for this document. For experimental use of new
+ features or for provider specific settings, keywords MUST be prefixed
+ with a domain name and an underscore.
+
+5. Security Considerations
+
+ The use of SHA-1 for the mapping of the "local-part" to a fixed
+ string is not a security feature but merely used to map the local-
+ part to a fixed-sized string made from a well defined set of
+ characters. It is not intended to conceal information about a mail
+ address.
+
+ The domain name part of the mail address is not part of the hash to
+ avoid problems with internationalized domain names. Instead a
+ separate URL is required for each domain name.
+
+6. IANA Considerations
+
+6.1. Well-Known URI
+
+ IANA is requested to assign a well-known URI in the "Well-Known URIs"
+ registry as defined by [RFC5785]:
+
+ URI suffix: openpgpkey
+
+ Change controller: IETF
+
+ Specification document: This
+
+7. Acknowledgments
+
+ The author would like to acknowledge the help of the individuals who
+ kindly voiced their opinions on the GnuPG mailing lists, in
+ particular, the help of Bernhard Reiter and Guilhem Moulin.
+
+
+
+
+Koch Expires April 8, 2017 [Page 9]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+8. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
+ "MIME Security with OpenPGP", RFC 3156, August 2001.
+
+ [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+ Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
+
+ [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
+ Uniform Resource Identifiers (URIs)", RFC 5785, DOI
+ 10.17487/RFC5785, April 2010,
+ .
+
+ [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
+ Media Path Key Agreement for Unicast Secure RTP", RFC
+ 6189, DOI 10.17487/RFC6189, April 2011,
+ .
+
+Appendix A. Sample Protocol Run
+
+ The following non-normative example can be used by implementors as
+ guidance.
+
+ Note that GnuPG version 2.1.12 supports the key discovery described
+ in version -00 of this document (auto-key-locate method "wkd").
+ Version 2.1.16 can run the protocol decribed in this document but is
+ also able to run the protocol version specified by -01.
+
+A.1. Sample Keys
+
+ This is the provider's submission key:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires April 8, 2017 [Page 10]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+ -----BEGIN PGP PRIVATE KEY BLOCK-----
+
+ lFgEV/TAohYJKwYBBAHaRw8BAQdAB/k9YQfSTI8qQqqK1KimH/BsvzsowWItSQPT
+ FP+fOC4AAP46uJ3Snno3Vy+kORye3rf0VvWvuz82voEQLxG6WpfHhREEtBprZXkt
+ c3VibWlzc2lvbkBleGFtcGxlLm5ldIh5BBMWCAAhBQJX9MCiAhsDBQsJCAcCBhUI
+ CQoLAgQWAgMBAh4BAheAAAoJEKhtNooW0cqEWMUA/0e9XaeptszWC9ZvPg8INL6a
+ BvRqPBYGU7PGmuXsxBovAQDyckOykG0UAfHVyN1w4gSK/biMcnqVr857i8/HuvjW
+ C5xdBFf0wKISCisGAQQBl1UBBQEBB0Apvaoe4MtSEJ1fpds/4DFl2kXXBpnVji/s
+ Wg9btdthNQMBCAcAAP9FJX99T1LEJzBnvBBnc6bimnT6/1OKM9RdO4R0/uVP6BFL
+ iGEEGBYIAAkFAlf0wKICGwwACgkQqG02ihbRyoTlGwD9FBr92osjL7HkhhZZ7Z2D
+ My3b9zpoZeMjvPg5YPqpdKMA/jhZoHuZCRMBYf7YRFb8aXtuyetDFZYrkjnum+OG
+ HFAD
+ =Hnwd
+ -----END PGP PRIVATE KEY BLOCK-----
+
+ This is the target key to be published:
+
+ -----BEGIN PGP PRIVATE KEY BLOCK-----
+
+ lFgEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
+ nTEoBRkAAP94nCZMM4WY2IORXfM6phLGSz3RsHvs/vA1Opaus4+R3BKJtBtwYXRy
+ aWNlLmx1bXVtYmFAZXhhbXBsZS5uZXSIeQQTFggAIQUCV2o9XQIbAwULCQgHAgYV
+ CAkKCwIEFgIDAQIeAQIXgAAKCRATlWNoKgINCpkNAQDFDcwJUzsxu7aJUiPdpYXj
+ 4uVarrXakxEE8mGFotWhLAD9GH4rqLDYIE3NKEU0s+Okt4tEIwJaV8H1NNPPPMiK
+ 3g2cXQRXaj2NEgorBgEEAZdVAQUBAQdAFnnmZc99TuKk5iCq9wmYZUVF2RcXN2Cs
+ qAl8iGQQUWsDAQgHAAD/VN/VGmlcwGBPcLTya2hfU4t37nMcFCKdNSXjJ5DFA0AP
+ PohhBBgWCAAJBQJXaj2NAhsMAAoJEBOVY2gqAg0Ky4UA/0GmVaXzXemLvv1Xw4yx
+ Eaz/KfKKGc4RJ+38fyqUzw8NAQCohQ+ki3I5f84EXLZEiUiLsnVtOn1HNxvND/gW
+ TiFZBA==
+ =GHi7
+ -----END PGP PRIVATE KEY BLOCK-----
+
+A.2. Sample Messages
+
+ The first message triggeres the publication requests.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires April 8, 2017 [Page 11]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+ From: patrice.lumumba@example.net
+ To: key-submission@example.net
+ Subject: Key publishing request
+ MIME-Version: 1.0
+ Content-Type: multipart/encrypted;
+ protocol="application/pgp-encrypted";
+ boundary="=-=01-e8k41e11ob31eefa36wo=-="
+ Date: Wed, 05 Oct 2016 10:15:51 +0000
+
+
+ --=-=01-e8k41e11ob31eefa36wo=-=
+ Content-Type: application/pgp-encrypted
+
+ Version: 1
+
+ --=-=01-e8k41e11ob31eefa36wo=-=
+ Content-Type: application/octet-stream
+
+ -----BEGIN PGP MESSAGE-----
+
+ hF4DUgLY5tvmW2sSAQdAR1AcqvFpQe/fHRZbf0xcnl9Tb+AtwaX2yZnZXGELGHsw
+ 1/e3E0JptwM5tpRAVe71ooF8Zq4jl76ZgQKfj/SyjpLJxyoEDy2N5wTQaqW4JtML
+ 0ukB1vh7dIRDxBJX/LQIJC0wz8o1Q3vjcLJKFFvDb7YrerABpPIzwOAupcgIbQHj
+ 5m1+2WU5CL8ffyJy2h1jV2X4OnvWF1Sn6J6SVD6DfZpOPRt9TxSemJrN1LJ3lG0N
+ ts8AuYmCOeC1H2r5TYyxqkC98JF8+Nvyxd/fwne8IOjK9uixkNMC5H9/ZOH0YWCb
+ wBnNB4iXuym4OIPxiLkDymsVF0ww/XrODE9Y259EGmO45VFNrJAX3HFs9/PcMCVk
+ n2qMyEkr8LHiXeEPun6Z54RHUPYv2cUkEZ0hhSJ+rtBxkc/5D/cAScCEXRKFSKEF
+ jLJAvLK/u/ga5DAzVai+vh6b6Bq+YVPaD9GWMhWj4CgR90p9LULi6S/Hzwhv9Wzf
+ 8fJoJOaDjyvRDgr09jYLWamxkS9NWxqwy6MXJvxwbNdd5XtqiW4Y4o0Ll1hDJhxR
+ ljn/XvotXKwhKN+4QGhIXDVt4Dl4XxS5ptWfVTau8W8DYqDsU2obEcfsirZv53M1
+ Q9FCD8CD9+dkBt8VAJekCWVhEltcRHxlrznbk2jxm93xSD2o6gZ5X0VSaSUXyEhm
+ J+8F3gyTHGgbq/TgyjFoockWh5EtGgAFuWvmPJCF5PO/UaNeoKwgwSJBu6oTXkHx
+ R4nvvMRcj5UgTsKpZ79NiDQukbjG5ScNT5TCUiiZsBXBqBx3fD61EH6cAuh4P3Kr
+ iM7PY4fwAHo890Dx+Qlt
+ =WIhx
+ -----END PGP MESSAGE-----
+
+ --=-=01-e8k41e11ob31eefa36wo=-=--
+
+ The server decrypts this message to
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires April 8, 2017 [Page 12]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+ Content-Type: application/pgp-keys
+
+ -----BEGIN PGP PUBLIC KEY BLOCK-----
+
+ mDMEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
+ nTEoBRm0G3BhdHJpY2UubHVtdW1iYUBleGFtcGxlLm5ldIh5BBMWCAAhBQJXaj1d
+ AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEBOVY2gqAg0KmQ0BAMUNzAlT
+ OzG7tolSI92lhePi5VqutdqTEQTyYYWi1aEsAP0YfiuosNggTc0oRTSz46S3i0Qj
+ AlpXwfU00888yIreDbg4BFdqPY0SCisGAQQBl1UBBQEBB0AWeeZlz31O4qTmIKr3
+ CZhlRUXZFxc3YKyoCXyIZBBRawMBCAeIYQQYFggACQUCV2o9jQIbDAAKCRATlWNo
+ KgINCsuFAP9BplWl813pi779V8OMsRGs/ynyihnOESft/H8qlM8PDQEAqIUPpIty
+ OX/OBFy2RIlIi7J1bTp9RzcbzQ/4Fk4hWQQ=
+ =qRfF
+ -----END PGP PUBLIC KEY BLOCK-----
+
+ and returns this confirmation request
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires April 8, 2017 [Page 13]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+ From: key-submission@example.net
+ To: patrice.lumumba@example.net
+ Subject: Confirm your key publication
+ MIME-Version: 1.0
+ Content-Type: multipart/encrypted;
+ protocol="application/pgp-encrypted";
+ boundary="=-=01-wrzqued738dfx4x97u7y=-="
+ Date: Wed, 05 Oct 2016 10:16:57 +0000
+
+
+ --=-=01-wrzqued738dfx4x97u7y=-=
+ Content-Type: application/pgp-encrypted
+
+ Version: 1
+
+ --=-=01-wrzqued738dfx4x97u7y=-=
+ Content-Type: application/octet-stream
+
+ -----BEGIN PGP MESSAGE-----
+
+ hF4DkYWHjk/NdMASAQdAluQeqhECpU2T0zEyBAEbFzhLkpubN160wjkFCrtUc0Mw
+ FwYgM2fp9cvTMdJ/xjkvmAcIEOT4AY/hn1yFQ4z0KG0gCkSac+8mkDylnPdxlXYw
+ 0sBSAXlbqpVA7eUpFuU2Zs10zbIXxlwe6osR5wUIJut/RCOsYQmfvxC55x8mUX5/
+ zgTnNzlMzye5ws4pTgAeQm2x0Yv018L8IZgY5KxwJLBzlss0wLZ45ZcS80hR11Fx
+ NCow1fKF8lMnOJxagTEOih807nctz8vT5bR1gx0d7N3LM+th8nAg9/6Ghf1XTpLo
+ MzwGW0FtOG7Dg1Uxbw2bjaOuRBeh6IIpmNAw1pmIfnNu7PpoRydU5w1K/R8MT06z
+ MKdJ7IW5mVGes9EGnG3e4mjuILvNaZhfYy+a73IhDSaPm3oqdl1Qx7tbNg6lGjn6
+ KStCYAcPGPp3m7aWkfsPGThOVRhEXqaFFywfwSVEj1pdIRjDFA==
+ =Cdjh
+ -----END PGP MESSAGE-----
+
+ --=-=01-wrzqued738dfx4x97u7y=-=--
+
+ The client decrypts the attachment as
+
+ Content-Type: application/vnd.gnupg.wks
+ Content-Transfer-Encoding: 8bit
+
+ type: confirmation-request
+ sender: key-submission@example.net
+ address: patrice.lumumba@example.net
+ fingerprint: B21DEAB4F875FB3DA42F1D1D139563682A020D0A
+ nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
+
+ creates this response
+
+
+
+
+
+
+Koch Expires April 8, 2017 [Page 14]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+ Content-Type: application/vnd.gnupg.wks
+ Content-Transfer-Encoding: 8bit
+
+ type: confirmation-response
+ sender: key-submission@example.net
+ address: patrice.lumumba@example.net
+ nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
+
+ and sends it encrypted to the server
+
+ From: patrice.lumumba@example.net
+ To: key-submission@example.net
+ Subject: Key publication confirmation
+ MIME-Version: 1.0
+ Content-Type: multipart/encrypted;
+ protocol="application/pgp-encrypted";
+ boundary="=-=01-iacqg4og4pqz11a5cg1o=-="
+ Date: Wed, 05 Oct 2016 10:18:52 +0000
+
+
+ --=-=01-iacqg4og4pqz11a5cg1o=-=
+ Content-Type: application/pgp-encrypted
+
+ Version: 1
+
+ --=-=01-iacqg4og4pqz11a5cg1o=-=
+ Content-Type: application/octet-stream
+
+ -----BEGIN PGP MESSAGE-----
+
+ hF4DUgLY5tvmW2sSAQdAnB1C3PMjS4AsGU0qaCqBdWQO5i6blWEyZrEsY+JZY1Qw
+ ooNq7zdVWOHhL9LPGAALAgoL3Qfz+dN2u5QamSQ/LJ2c8M0XipNs3lqlNH63yQN1
+ 0sAmAc3W8xkwul+rf6OLK/gMi6WzM4fnUhd4D1LJGIJoNUN0l3636C7ecOt2lkMl
+ 5bVAYg/SyMT3ymyfQnvtiem2T5DSnPsS1g6n6QNXWvkqvX9yGxNsNDJEHTuGJB8k
+ OJoRlfWQTEo6pgA89febWl1EdeM1pPLstQ2uZE8NPjXoY1nMxAlu+iPYsR41/4sg
+ dqwOv5BPLh/GIat8hh9SPWCA9iKlgSQ/EIv5DpjQogEzpriT55dkgfvSVYIAcOdO
+ ShZ91YKkcZffevdY72omqTk10a1SUXehPooIlRFmroDsi3VDaRKrUIo=
+ =7uve
+ -----END PGP MESSAGE-----
+
+ --=-=01-iacqg4og4pqz11a5cg1o=-=--
+
+Appendix B. Changes Since -01
+
+ o Changed the format of the confirmation request.
+
+ o Added sample messages.
+
+
+
+
+Koch Expires April 8, 2017 [Page 15]
+
+Internet-Draft OpenPGP Web Key Service October 2016
+
+
+Author's Address
+
+ Werner Koch
+ GnuPG Project
+
+ Email: wk@gnupg.org
+ URI: https://gnupg.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires April 8, 2017 [Page 16]
diff --git a/misc/id/openpgp-webkey-service/draft-koch-openpgp-webkey-service-03.txt b/misc/id/openpgp-webkey-service/draft-koch-openpgp-webkey-service-03.txt
new file mode 100644
index 0000000..12a1c90
--- /dev/null
+++ b/misc/id/openpgp-webkey-service/draft-koch-openpgp-webkey-service-03.txt
@@ -0,0 +1,952 @@
+
+
+
+
+Network Working Group W. Koch
+Internet-Draft GnuPG Project
+Intended status: Informational January 31, 2017
+Expires: August 4, 2017
+
+
+ OpenPGP Web Key Service
+ draft-koch-openpgp-webkey-service-03
+
+Abstract
+
+ This specification describes a service to locate OpenPGP keys by mail
+ address using a Web service and the HTTPS protocol. It also provides
+ a method for secure communication between the key owner and the mail
+ provider to publish and revoke the public key.
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on August 4, 2017.
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Koch Expires August 4, 2017 [Page 1]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2
+ 3. Web Key Directory . . . . . . . . . . . . . . . . . . . . . . 2
+ 3.1. Key Discovery . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Web Key Directory Update Protocol . . . . . . . . . . . . . . 5
+ 4.1. The Submission Address . . . . . . . . . . . . . . . . . 6
+ 4.2. The Submission Mail . . . . . . . . . . . . . . . . . . . 6
+ 4.3. The Confirmation Request . . . . . . . . . . . . . . . . 6
+ 4.4. The Confirmation Response . . . . . . . . . . . . . . . . 8
+ 4.5. Policy Flags . . . . . . . . . . . . . . . . . . . . . . 9
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 6.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 10
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
+ 8. Normative References . . . . . . . . . . . . . . . . . . . . 10
+ Appendix A. Sample Protocol Run . . . . . . . . . . . . . . . . 11
+ A.1. Sample Keys . . . . . . . . . . . . . . . . . . . . . . . 11
+ A.2. Sample Messages . . . . . . . . . . . . . . . . . . . . . 12
+ Appendix B. Changes Since -02 . . . . . . . . . . . . . . . . . 16
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
+
+1. Introduction
+
+ This memo describes a method to associate OpenPGP keys with a mail
+ address and how to look them up using a web service with a well-known
+ URI. In addition a mail based protocol is given to allow a client to
+ setup such an association and to maintain it.
+
+2. Notational Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. Web Key Directory
+
+ A major use case for OpenPGP is the encryption of mail. A common
+ difficulty of sending encrypted mails to a new communication partner
+ is to find the appropriate public key of the recipient. Unless an
+ off-channel key exchange has been done, there are no easy ways to
+ discover the required key. The common practice is to search the
+ network of public key servers for a key matching the recipient's mail
+ address. This practise bears the problem that the keyservers are not
+ able to give a positive confirmation that a key actually belongs to
+ the mail addresses given in the key. Further, there are often
+ several keys matching a mail address and thus one needs to pick a key
+
+
+
+Koch Expires August 4, 2017 [Page 2]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ on good luck. This is clearly not a secure way to setup an end-to-
+ end encryption. Even if the need for a trusted key for an initial
+ mail message is relinquished, a non-authenticated key may be a wrong
+ one and the actual recipient would receive a mail which she can't
+ decrypt, due to the use of a wrong key.
+
+ Methods to overcome this problem are
+
+ o sending an initial unencrypted message with the public key
+ attached,
+
+ o using the OpenPGP DANE protocol to lookup the recipients key via
+ the DNS.
+
+ The first method has the obvious problems of not even trying to
+ encrypt the initial mail, an extra mail round-trip, and problems with
+ unattended key discovery.
+
+ The latter method works fine but requires that mail providers need to
+ set up a separate DNS resolver to provide the key. The
+ administration of a DNS zone is often not in the hands of small mail
+ installations. Thus an update of the DNS resource records needs to
+ be delegated to the ISP running the DNS service. Further, DNS
+ lookups are not encrypted and missing all confidentially. Even if
+ the participating MUAs are using STARTTLS to encrypt the mail
+ exchange, a DNS lookup for the key unnecessarily identifies the
+ local-part of the recipients mail address to any passive
+ eavesdroppers.
+
+ This memo specified a new method for key discovery using an encrypted
+ https connection.
+
+3.1. Key Discovery
+
+ Although URIs are able to encode all kind of characters,
+ straightforward implementations of a key directory may want to store
+ the local-part of a mail address directly in the file system. This
+ forbids the use of certain characters in the local-part. To allow
+ for such an implementation method the URI uses an encoded form of the
+ local-part which can be directly mapped to a file name.
+
+ OpenPGP defines its User IDs, and thus the mail address, as UTF-8
+ strings. To help with the common pattern of using capitalized names
+ (e.g. "Joe.Doe@example.org") for mail addresses, and under the
+ premise that almost all MTAs treat the local-part case-insensitive
+ and that the domain-part is required to be compared case-insensitive
+ anyway, all upper-case ASCII characters in a User ID are mapped to
+ lowercase. Non-ASCII characters are not changed.
+
+
+
+Koch Expires August 4, 2017 [Page 3]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ The so mapped local-part is hashed using the SHA-1 algorithm. The
+ resulting 160 bit digest is encoded using the Z-Base-32 method as
+ described in [RFC6189], section 5.1.6. The resulting string has a
+ fixed length of 32 octets. To form the URI, the following parts are
+ concatenated:
+
+ o The scheme "https://",
+
+ o the domain-part,
+
+ o the string "/.well-known/openpgpkey/hu/",
+
+ o and the above constructed 32 octet string.
+
+ For example the URI to lookup the key for Joe.Doe@Example.ORG is:
+
+ https://example.org/.well-known/openpgpkey/
+ hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q
+
+ (line has been wrapped for rendering purposes)
+
+ DNS SRV resource records ([RFC2782]) may be used to query a different
+ host or a port other than 443. For example:
+
+ _openpgpkey._tcp.example.org. IN SRV 0 0 8443 wkd.example.org.
+
+ changes the above to query the host "wkd.example.org" at port 8443
+ instead of the host "gnupg.org" at port 443. The target (in the
+ example "wkd.example.org") MUST be a sub-domain of the domain-part
+ (here "example.org"). If the target is not a sub-domain, the SRV RR
+ MUST be be ignored. The recommended name for the sub-domain is
+ "wkd".
+
+ The HTTP GET method MUST return the binary representation of the
+ OpenPGP key for the given mail address. The key needs to carry a
+ User ID packet ([RFC4880]) with that mail address. Note that the key
+ may be revoked or expired - it is up to the client to handle such
+ conditions. To ease distribution of revoked keys, a server may
+ return revoked keys in addition to a new key. The keys are returned
+ by a single request as concatenated key blocks.
+
+ The server MUST accept the HTTP HEAD method to allow a client to
+ check for the existence of a key.
+
+ The server SHOULD use "application/octet-string" as the Content-Type
+ for the data but clients SHOULD also accept any other Content-Type.
+ The server MUST NOT return an ASCII armored version of the key.
+
+
+
+
+Koch Expires August 4, 2017 [Page 4]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+4. Web Key Directory Update Protocol
+
+ To put keys into the key directory a protocol to automate the task is
+ desirable. The protocol defined here is entirely based on mail and
+ the assumption that a mail provider can securely deliver mail to the
+ INBOX of a user (e.g. an IMAP folder). Note that the same protocol
+ may also be used for submitting keys for use with OpenPGP DANE.
+
+ We assume that the user already created a key for her mail account
+ alice@example.org. To install the key at her provider's Web Key
+ Directory, she performs the following steps:
+
+ 1. She retrieves a file which contains one line with the mail
+ address used to submit the key to the mail provider. The DNS SRV
+ rules described for the Web Key Directory apply here as well.
+ See below for the syntax of that file. For a mail address at the
+ domain "example.org" the URI of the file is
+
+ https://example.org/.well-known/openpgpkey/submission-address
+
+ 2. She sends her key using SMTP (or any other transport mechanism)
+ to the provider using the submission address and key format as
+ specified by PGP/MIME.
+
+ 3. The provider checks that the received key has a User ID which
+ matches an account name of the provider.
+
+ 4. The provider sends an encrypted message containing a nonce and
+ the fingerprint of the key to the mail account of the user. Note
+ that a similar scheme is used by the well known caff(1) tool to
+ help with key signing parties.
+
+ 5. A legitimate user will be able to decrypt the message because she
+ created the key and is in charge of the private key. This step
+ verifies that the submitted key has actually been created by the
+ owner of the account.
+
+ 6. The user sends the decrypted nonce back to the submission address
+ as a confirmation that the private key is owned by her and that
+ the provider may now publish the key. Although technically not
+ required, it is suggested that the mail to the provider is
+ encrypted. The public key for this is retrieved using the key
+ lookup protocol described above.
+
+ 7. The provider receives the nonce, matches it with its database of
+ pending confirmations and then publishes the key. Finally the
+ provider sends a mail back to the user to notify her of the
+ publication of her key.
+
+
+
+Koch Expires August 4, 2017 [Page 5]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ The message data structures used for the above protocol are specified
+ in detail below. In the following sections the string "WELLKNOWN"
+ denotes the first part of an URI specific for a domain. In the
+ examples the domain "example.org" is assumed, thus
+
+ WELLKNOWN := https://example.org/.well-known/openpgpkey
+
+ The term "target key" denotes the to be published key, the term
+ "submission key" the key associated with the submission-address of
+ the mail provider.
+
+4.1. The Submission Address
+
+ The address of the submission file is
+
+ WELLKNOWN/submission-address
+
+ The file consists of exactly one line, terminated by a LF, or the
+ sequence of CR and LF, with the full mail address to be used for
+ submission of a key to the mail provider. For example the content of
+ the file may be
+
+ key-submission-example.org@directory.example.org
+
+4.2. The Submission Mail
+
+ The mail used to submit a key to the mail provider MUST comply to the
+ PGP/MIME specification ([RFC3156], section 7), which states that the
+ Content-Type must be "application/pgp-keys", there are no required or
+ optional parameters, and the body part contains the ASCII-armored
+ transferable Public Key Packets as defined in [RFC4880], section
+ 11.1.
+
+ The mail provider MUST publish a key capable of signing and
+ encryption for the submission-address in the Web Key Directory or via
+ DANE. The key to be published MUST be submitted using a PGP/MIME
+ encrypted message ([RFC3156], section 4). The message MUST NOT be
+ signed (because the authenticity of the signing key has not yet been
+ confirmed). After decryption of the message at the mail provider a
+ single "application/pgp-keys" part, as specified above, is expected.
+
+4.3. The Confirmation Request
+
+ The mail provider sends a confirmation mail in response to a received
+ key publication request. The message MUST be sent from the
+ submission-address of the mail provider to the mail address extracted
+ from the target key. The message needs to be a PGP/MIME signed
+
+
+
+
+Koch Expires August 4, 2017 [Page 6]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ message using the submission key of the provider for the signature.
+ The signed message MUST have two parts:
+
+ The first part MUST have "text" as its Content-Type and can be used
+ to explain the purpose of the mail. For example it may point to this
+ RFC and explain on how to manually perform the protocol.
+
+ The second part MUST have "application/vnd.gnupg.wkd" as its Content-
+ Type and carry an OpenPGP encrypted message in ASCII Armor format.
+ The message MUST be encrypted to the target key and MUST NOT be
+ signed. After decryption a text file in the Web Key data format must
+ be yielded.
+
+ That data format consists of name-value pairs with one name-value
+ pair per LF or CR+LF terminated line. Empty lines are allowed and
+ will be ignored by the receiver. A colon is used to terminate a
+ name.
+
+ In a confirmation request the following names MUST be send in the
+ specified order:
+
+ o "type": The value must be "confirmation-request".
+
+ o "sender": This is the mailbox the user is expected to sent the
+ confirmation response to. The value must match the mailbox part
+ of the "From:" address of this request. Exactly one address MUST
+ be given.
+
+ o "address": The value is the addr-spec part of the target key's
+ mail address. The value SHOULD match the addr-spec part of the
+ recipient's address. The value MUST be UTF-8 encoded as required
+ for an OpenPGP User ID.
+
+ o "fingerprint": The value is the fingerprint of the target key.
+ The fingerprint is given in uppercase hex encoding without any
+ interleaving spaces.
+
+ o "nonce": The value is a string with a minimum length of 16 octets
+ and a maximum length of 64 octets. The string must entirely be
+ made up of random ASCII letters or digits. This nonce will be
+ sent back to the mail provider as proof that the recipient is the
+ legitimate owner of the target-key.
+
+ The receiver of that message is expected to verify the outer
+ signature and disregard the entire message if it can't be verified or
+ has not been signed by the key associated with the submission
+ address.
+
+
+
+
+Koch Expires August 4, 2017 [Page 7]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ After the message as been verified the receiver decrypts the second
+ part of the message, checks that the "fingerprint" matches the target
+ key, checks that the "address" matches a User ID of the target key,
+ and checks the other constrains of the request format. If any
+ constraint is not asserted, or the fingerprint or User ID do not
+ match the target key, or there is no pending publication requests
+ (i.e. a mail recently sent o the submission address), the user MAY be
+ notified about this fake confirmation attempt.
+
+ In other cases the confirmation request is legitimate and the MUA
+ shall silently send a response as described in the next section.
+
+ The rationale for the outer signature used with this request is to
+ allow early detection of spam mails. This can be done prior to the
+ decryption step and avoids asking the user to enter a passphrase to
+ perform the decryption for a non-legitimate message. The use of a
+ simple encrypted attachment, instead of using PGP/MIME encryption, is
+ to convey the Content-Type of that attachment in the clear and also
+ to prevent automatic decryption of that attachment by PGP/MIME aware
+ clients. The MUA may in fact detect this confirmation request and
+ present a customized dialog for confirming that request.
+
+4.4. The Confirmation Response
+
+ A response to a confirmation request MUST only be send in the
+ positive case; there is no negative confirmation response. A mail
+ service provider is expected to cancel a pending key submission after
+ a suitable time without a confirmation. The mail service provider
+ SHOULD NOT retry the sending of a confirmation request after the
+ first request has been send successfully.
+
+ The user MUST send the confirmation response from her target mail
+ address to the "from" address of the confirmation request. The
+ message MUST be signed and encrypted using the PGP/MIME Combined
+ format ([RFC3156], section 6.2). The signing key is the target key
+ and the encryption key is the key associated with the provider's
+ submission address.
+
+ The Content-Type used for the plaintext message MUST also be
+ "application/vnd.gnupg.wkd". The format is the same as described
+ above for the Confirmation Request. The body must contain three
+ name-value pairs in this order:
+
+ o "type": The value must be "confirmation-response".
+
+ o "sender": The value must match the mailbox part of the "From:"
+ address of this response. Exactly one address MUST be given.
+
+
+
+
+Koch Expires August 4, 2017 [Page 8]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ o "nonce": The value is the value of the "nonce" parameter from the
+ confirmation request.
+
+4.5. Policy Flags
+
+ For key generation and submission it is sometimes useful to tell the
+ client about certain properties of the mail provider in advance.
+ This can be done with a file at the URL
+
+ WELLKNOWN/policy
+
+ The file contains keywords and optioanlly values, one per line with
+ each line terminated by a LF or the sequence of CR and LF. Empty
+ lines and lines starting with a '#' character are considered comment
+ lines. A keyword is made up of lowercase letters, digits, hyphens,
+ or dots. An underscore is allowed as a name space delimiters; see
+ below. The first character must be a letter. Keywords which are
+ defined to require a value are directly followed by a colon and then
+ after optional white space the value. Clients MUST use case-
+ insensitive matching for the keyword.
+
+ Currently defined keywords are:
+
+ o "mailbox-only": The mail server provider does only accept keys
+ with only a mailbox in the User ID. In particular User IDs with a
+ real name in addition to the mailbox will be rejected as invalid.
+
+ o "dane-only": The mail server provider does not run a Web Key
+ Directory but only an OpenPGP DANE service. The Web Key Directory
+ Update protocol is used to update the keys for the DANE service.
+
+ o "auth-submit": The submission of the mail to the server is done
+ using an authenticated connection. Thus the submitted key will be
+ published immediately without any confirmation request.
+
+ More keywords will be defined in updates to this I-D. There is no
+ registry except for this document. For experimental use of new
+ features or for provider specific settings, keywords MUST be prefixed
+ with a domain name and an underscore.
+
+5. Security Considerations
+
+ The use of SHA-1 for the mapping of the local-part to a fixed string
+ is not a security feature but merely used to map the local-part to a
+ fixed-sized string made from a well defined set of characters. It is
+ not intended to conceal information about a mail address.
+
+
+
+
+
+Koch Expires August 4, 2017 [Page 9]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ The domain name part of the mail address is not part of the hash to
+ avoid problems with internationalized domain names. Instead a
+ separate URL is required for each domain name.
+
+ The use of DNS SRV records reduces the certainty that a mail address
+ belongs to a domain. For example an attacker may change the target
+ to a host in a sub-domain under their control and thus gain full
+ control over all keys. An implementation may want to weight the
+ certainty of a mapping different if it has been retrieved via a sub-
+ domain and in particular if a non-recommended name is used for the
+ sub-domain.
+
+6. IANA Considerations
+
+6.1. Well-Known URI
+
+ IANA is requested to assign a well-known URI in the "Well-Known URIs"
+ registry as defined by [RFC5785]:
+
+ URI suffix: openpgpkey
+
+ Change controller: IETF
+
+ Specification document: This
+
+7. Acknowledgments
+
+ The author would like to acknowledge the help of the individuals who
+ kindly voiced their opinions on the GnuPG mailing lists, in
+ particular, the help of Bernhard Reiter and Guilhem Moulin.
+
+8. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ DOI 10.17487/RFC2782, February 2000,
+ .
+
+ [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
+ "MIME Security with OpenPGP", RFC 3156, August 2001.
+
+ [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+ Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
+
+
+
+
+
+Koch Expires August 4, 2017 [Page 10]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
+ Uniform Resource Identifiers (URIs)", RFC 5785, DOI
+ 10.17487/RFC5785, April 2010,
+ .
+
+ [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
+ Media Path Key Agreement for Unicast Secure RTP", RFC
+ 6189, DOI 10.17487/RFC6189, April 2011,
+ .
+
+Appendix A. Sample Protocol Run
+
+ The following non-normative example can be used by implementors as
+ guidance.
+
+ Note that GnuPG version 2.1.12 supports the key discovery described
+ in version -00 of this document (auto-key-locate method "wkd").
+ Version 2.1.16 can run the protocol decribed in this document but is
+ also able to run the protocol version specified by -01.
+
+A.1. Sample Keys
+
+ This is the provider's submission key:
+
+ -----BEGIN PGP PRIVATE KEY BLOCK-----
+
+ lFgEV/TAohYJKwYBBAHaRw8BAQdAB/k9YQfSTI8qQqqK1KimH/BsvzsowWItSQPT
+ FP+fOC4AAP46uJ3Snno3Vy+kORye3rf0VvWvuz82voEQLxG6WpfHhREEtBprZXkt
+ c3VibWlzc2lvbkBleGFtcGxlLm5ldIh5BBMWCAAhBQJX9MCiAhsDBQsJCAcCBhUI
+ CQoLAgQWAgMBAh4BAheAAAoJEKhtNooW0cqEWMUA/0e9XaeptszWC9ZvPg8INL6a
+ BvRqPBYGU7PGmuXsxBovAQDyckOykG0UAfHVyN1w4gSK/biMcnqVr857i8/HuvjW
+ C5xdBFf0wKISCisGAQQBl1UBBQEBB0Apvaoe4MtSEJ1fpds/4DFl2kXXBpnVji/s
+ Wg9btdthNQMBCAcAAP9FJX99T1LEJzBnvBBnc6bimnT6/1OKM9RdO4R0/uVP6BFL
+ iGEEGBYIAAkFAlf0wKICGwwACgkQqG02ihbRyoTlGwD9FBr92osjL7HkhhZZ7Z2D
+ My3b9zpoZeMjvPg5YPqpdKMA/jhZoHuZCRMBYf7YRFb8aXtuyetDFZYrkjnum+OG
+ HFAD
+ =Hnwd
+ -----END PGP PRIVATE KEY BLOCK-----
+
+ This is the target key to be published:
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires August 4, 2017 [Page 11]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ -----BEGIN PGP PRIVATE KEY BLOCK-----
+
+ lFgEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
+ nTEoBRkAAP94nCZMM4WY2IORXfM6phLGSz3RsHvs/vA1Opaus4+R3BKJtBtwYXRy
+ aWNlLmx1bXVtYmFAZXhhbXBsZS5uZXSIeQQTFggAIQUCV2o9XQIbAwULCQgHAgYV
+ CAkKCwIEFgIDAQIeAQIXgAAKCRATlWNoKgINCpkNAQDFDcwJUzsxu7aJUiPdpYXj
+ 4uVarrXakxEE8mGFotWhLAD9GH4rqLDYIE3NKEU0s+Okt4tEIwJaV8H1NNPPPMiK
+ 3g2cXQRXaj2NEgorBgEEAZdVAQUBAQdAFnnmZc99TuKk5iCq9wmYZUVF2RcXN2Cs
+ qAl8iGQQUWsDAQgHAAD/VN/VGmlcwGBPcLTya2hfU4t37nMcFCKdNSXjJ5DFA0AP
+ PohhBBgWCAAJBQJXaj2NAhsMAAoJEBOVY2gqAg0Ky4UA/0GmVaXzXemLvv1Xw4yx
+ Eaz/KfKKGc4RJ+38fyqUzw8NAQCohQ+ki3I5f84EXLZEiUiLsnVtOn1HNxvND/gW
+ TiFZBA==
+ =GHi7
+ -----END PGP PRIVATE KEY BLOCK-----
+
+A.2. Sample Messages
+
+ The first message triggeres the publication requests.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires August 4, 2017 [Page 12]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ From: patrice.lumumba@example.net
+ To: key-submission@example.net
+ Subject: Key publishing request
+ MIME-Version: 1.0
+ Content-Type: multipart/encrypted;
+ protocol="application/pgp-encrypted";
+ boundary="=-=01-e8k41e11ob31eefa36wo=-="
+ Date: Wed, 05 Oct 2016 10:15:51 +0000
+
+
+ --=-=01-e8k41e11ob31eefa36wo=-=
+ Content-Type: application/pgp-encrypted
+
+ Version: 1
+
+ --=-=01-e8k41e11ob31eefa36wo=-=
+ Content-Type: application/octet-stream
+
+ -----BEGIN PGP MESSAGE-----
+
+ hF4DUgLY5tvmW2sSAQdAR1AcqvFpQe/fHRZbf0xcnl9Tb+AtwaX2yZnZXGELGHsw
+ 1/e3E0JptwM5tpRAVe71ooF8Zq4jl76ZgQKfj/SyjpLJxyoEDy2N5wTQaqW4JtML
+ 0ukB1vh7dIRDxBJX/LQIJC0wz8o1Q3vjcLJKFFvDb7YrerABpPIzwOAupcgIbQHj
+ 5m1+2WU5CL8ffyJy2h1jV2X4OnvWF1Sn6J6SVD6DfZpOPRt9TxSemJrN1LJ3lG0N
+ ts8AuYmCOeC1H2r5TYyxqkC98JF8+Nvyxd/fwne8IOjK9uixkNMC5H9/ZOH0YWCb
+ wBnNB4iXuym4OIPxiLkDymsVF0ww/XrODE9Y259EGmO45VFNrJAX3HFs9/PcMCVk
+ n2qMyEkr8LHiXeEPun6Z54RHUPYv2cUkEZ0hhSJ+rtBxkc/5D/cAScCEXRKFSKEF
+ jLJAvLK/u/ga5DAzVai+vh6b6Bq+YVPaD9GWMhWj4CgR90p9LULi6S/Hzwhv9Wzf
+ 8fJoJOaDjyvRDgr09jYLWamxkS9NWxqwy6MXJvxwbNdd5XtqiW4Y4o0Ll1hDJhxR
+ ljn/XvotXKwhKN+4QGhIXDVt4Dl4XxS5ptWfVTau8W8DYqDsU2obEcfsirZv53M1
+ Q9FCD8CD9+dkBt8VAJekCWVhEltcRHxlrznbk2jxm93xSD2o6gZ5X0VSaSUXyEhm
+ J+8F3gyTHGgbq/TgyjFoockWh5EtGgAFuWvmPJCF5PO/UaNeoKwgwSJBu6oTXkHx
+ R4nvvMRcj5UgTsKpZ79NiDQukbjG5ScNT5TCUiiZsBXBqBx3fD61EH6cAuh4P3Kr
+ iM7PY4fwAHo890Dx+Qlt
+ =WIhx
+ -----END PGP MESSAGE-----
+
+ --=-=01-e8k41e11ob31eefa36wo=-=--
+
+ The server decrypts this message to
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires August 4, 2017 [Page 13]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ Content-Type: application/pgp-keys
+
+ -----BEGIN PGP PUBLIC KEY BLOCK-----
+
+ mDMEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
+ nTEoBRm0G3BhdHJpY2UubHVtdW1iYUBleGFtcGxlLm5ldIh5BBMWCAAhBQJXaj1d
+ AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEBOVY2gqAg0KmQ0BAMUNzAlT
+ OzG7tolSI92lhePi5VqutdqTEQTyYYWi1aEsAP0YfiuosNggTc0oRTSz46S3i0Qj
+ AlpXwfU00888yIreDbg4BFdqPY0SCisGAQQBl1UBBQEBB0AWeeZlz31O4qTmIKr3
+ CZhlRUXZFxc3YKyoCXyIZBBRawMBCAeIYQQYFggACQUCV2o9jQIbDAAKCRATlWNo
+ KgINCsuFAP9BplWl813pi779V8OMsRGs/ynyihnOESft/H8qlM8PDQEAqIUPpIty
+ OX/OBFy2RIlIi7J1bTp9RzcbzQ/4Fk4hWQQ=
+ =qRfF
+ -----END PGP PUBLIC KEY BLOCK-----
+
+ and returns this confirmation request
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires August 4, 2017 [Page 14]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ From: key-submission@example.net
+ To: patrice.lumumba@example.net
+ Subject: Confirm your key publication
+ MIME-Version: 1.0
+ Content-Type: multipart/encrypted;
+ protocol="application/pgp-encrypted";
+ boundary="=-=01-wrzqued738dfx4x97u7y=-="
+ Date: Wed, 05 Oct 2016 10:16:57 +0000
+
+
+ --=-=01-wrzqued738dfx4x97u7y=-=
+ Content-Type: application/pgp-encrypted
+
+ Version: 1
+
+ --=-=01-wrzqued738dfx4x97u7y=-=
+ Content-Type: application/octet-stream
+
+ -----BEGIN PGP MESSAGE-----
+
+ hF4DkYWHjk/NdMASAQdAluQeqhECpU2T0zEyBAEbFzhLkpubN160wjkFCrtUc0Mw
+ FwYgM2fp9cvTMdJ/xjkvmAcIEOT4AY/hn1yFQ4z0KG0gCkSac+8mkDylnPdxlXYw
+ 0sBSAXlbqpVA7eUpFuU2Zs10zbIXxlwe6osR5wUIJut/RCOsYQmfvxC55x8mUX5/
+ zgTnNzlMzye5ws4pTgAeQm2x0Yv018L8IZgY5KxwJLBzlss0wLZ45ZcS80hR11Fx
+ NCow1fKF8lMnOJxagTEOih807nctz8vT5bR1gx0d7N3LM+th8nAg9/6Ghf1XTpLo
+ MzwGW0FtOG7Dg1Uxbw2bjaOuRBeh6IIpmNAw1pmIfnNu7PpoRydU5w1K/R8MT06z
+ MKdJ7IW5mVGes9EGnG3e4mjuILvNaZhfYy+a73IhDSaPm3oqdl1Qx7tbNg6lGjn6
+ KStCYAcPGPp3m7aWkfsPGThOVRhEXqaFFywfwSVEj1pdIRjDFA==
+ =Cdjh
+ -----END PGP MESSAGE-----
+
+ --=-=01-wrzqued738dfx4x97u7y=-=--
+
+ The client decrypts the attachment as
+
+ Content-Type: application/vnd.gnupg.wks
+ Content-Transfer-Encoding: 8bit
+
+ type: confirmation-request
+ sender: key-submission@example.net
+ address: patrice.lumumba@example.net
+ fingerprint: B21DEAB4F875FB3DA42F1D1D139563682A020D0A
+ nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
+
+ creates this response
+
+
+
+
+
+
+Koch Expires August 4, 2017 [Page 15]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+ Content-Type: application/vnd.gnupg.wks
+ Content-Transfer-Encoding: 8bit
+
+ type: confirmation-response
+ sender: key-submission@example.net
+ address: patrice.lumumba@example.net
+ nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
+
+ and sends it encrypted to the server
+
+ From: patrice.lumumba@example.net
+ To: key-submission@example.net
+ Subject: Key publication confirmation
+ MIME-Version: 1.0
+ Content-Type: multipart/encrypted;
+ protocol="application/pgp-encrypted";
+ boundary="=-=01-iacqg4og4pqz11a5cg1o=-="
+ Date: Wed, 05 Oct 2016 10:18:52 +0000
+
+
+ --=-=01-iacqg4og4pqz11a5cg1o=-=
+ Content-Type: application/pgp-encrypted
+
+ Version: 1
+
+ --=-=01-iacqg4og4pqz11a5cg1o=-=
+ Content-Type: application/octet-stream
+
+ -----BEGIN PGP MESSAGE-----
+
+ hF4DUgLY5tvmW2sSAQdAnB1C3PMjS4AsGU0qaCqBdWQO5i6blWEyZrEsY+JZY1Qw
+ ooNq7zdVWOHhL9LPGAALAgoL3Qfz+dN2u5QamSQ/LJ2c8M0XipNs3lqlNH63yQN1
+ 0sAmAc3W8xkwul+rf6OLK/gMi6WzM4fnUhd4D1LJGIJoNUN0l3636C7ecOt2lkMl
+ 5bVAYg/SyMT3ymyfQnvtiem2T5DSnPsS1g6n6QNXWvkqvX9yGxNsNDJEHTuGJB8k
+ OJoRlfWQTEo6pgA89febWl1EdeM1pPLstQ2uZE8NPjXoY1nMxAlu+iPYsR41/4sg
+ dqwOv5BPLh/GIat8hh9SPWCA9iKlgSQ/EIv5DpjQogEzpriT55dkgfvSVYIAcOdO
+ ShZ91YKkcZffevdY72omqTk10a1SUXehPooIlRFmroDsi3VDaRKrUIo=
+ =7uve
+ -----END PGP MESSAGE-----
+
+ --=-=01-iacqg4og4pqz11a5cg1o=-=--
+
+Appendix B. Changes Since -02
+
+ o Specified the use of DNS SRV.
+
+
+
+
+
+
+Koch Expires August 4, 2017 [Page 16]
+
+Internet-Draft OpenPGP Web Key Service January 2017
+
+
+Author's Address
+
+ Werner Koch
+ GnuPG Project
+
+ Email: wk@gnupg.org
+ URI: https://gnupg.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires August 4, 2017 [Page 17]
diff --git a/misc/id/openpgp-webkey-service/draft-koch-openpgp-webkey-service-04.txt b/misc/id/openpgp-webkey-service/draft-koch-openpgp-webkey-service-04.txt
new file mode 100644
index 0000000..b10fae5
--- /dev/null
+++ b/misc/id/openpgp-webkey-service/draft-koch-openpgp-webkey-service-04.txt
@@ -0,0 +1,952 @@
+
+
+
+
+Network Working Group W. Koch
+Internet-Draft GnuPG Project
+Intended status: Informational July 28, 2017
+Expires: January 29, 2018
+
+
+ OpenPGP Web Key Service
+ draft-koch-openpgp-webkey-service-04
+
+Abstract
+
+ This specification describes a service to locate OpenPGP keys by mail
+ address using a Web service and the HTTPS protocol. It also provides
+ a method for secure communication between the key owner and the mail
+ provider to publish and revoke the public key.
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on January 29, 2018.
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Koch Expires January 29, 2018 [Page 1]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2
+ 3. Web Key Directory . . . . . . . . . . . . . . . . . . . . . . 2
+ 3.1. Key Discovery . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Web Key Directory Update Protocol . . . . . . . . . . . . . . 5
+ 4.1. The Submission Address . . . . . . . . . . . . . . . . . 6
+ 4.2. The Submission Mail . . . . . . . . . . . . . . . . . . . 6
+ 4.3. The Confirmation Request . . . . . . . . . . . . . . . . 6
+ 4.4. The Confirmation Response . . . . . . . . . . . . . . . . 8
+ 4.5. Policy Flags . . . . . . . . . . . . . . . . . . . . . . 9
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 6.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 10
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
+ 8. Normative References . . . . . . . . . . . . . . . . . . . . 10
+ Appendix A. Sample Protocol Run . . . . . . . . . . . . . . . . 11
+ A.1. Sample Keys . . . . . . . . . . . . . . . . . . . . . . . 11
+ A.2. Sample Messages . . . . . . . . . . . . . . . . . . . . . 12
+ Appendix B. Changes Since -03 . . . . . . . . . . . . . . . . . 16
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
+
+1. Introduction
+
+ This memo describes a method to associate OpenPGP keys with a mail
+ address and how to look them up using a web service with a well-known
+ URI. In addition a mail based protocol is given to allow a client to
+ setup such an association and to maintain it.
+
+2. Notational Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. Web Key Directory
+
+ A major use case for OpenPGP is the encryption of mail. A common
+ difficulty of sending encrypted mails to a new communication partner
+ is to find the appropriate public key of the recipient. Unless an
+ off-channel key exchange has been done, there are no easy ways to
+ discover the required key. The common practice is to search the
+ network of public key servers for a key matching the recipient's mail
+ address. This practise bears the problem that the keyservers are not
+ able to give a positive confirmation that a key actually belongs to
+ the mail addresses given in the key. Further, there are often
+ several keys matching a mail address and thus one needs to pick a key
+
+
+
+Koch Expires January 29, 2018 [Page 2]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ on good luck. This is clearly not a secure way to setup an end-to-
+ end encryption. Even if the need for a trusted key for an initial
+ mail message is relinquished, a non-authenticated key may be a wrong
+ one and the actual recipient would receive a mail which she can't
+ decrypt, due to the use of a wrong key.
+
+ Methods to overcome this problem are
+
+ o sending an initial unencrypted message with the public key
+ attached,
+
+ o using the OpenPGP DANE protocol to lookup the recipients key via
+ the DNS.
+
+ The first method has the obvious problems of not even trying to
+ encrypt the initial mail, an extra mail round-trip, and problems with
+ unattended key discovery.
+
+ The latter method works fine but requires that mail providers need to
+ set up a separate DNS resolver to provide the key. The
+ administration of a DNS zone is often not in the hands of small mail
+ installations. Thus an update of the DNS resource records needs to
+ be delegated to the ISP running the DNS service. Further, DNS
+ lookups are not encrypted and missing all confidentially. Even if
+ the participating MUAs are using STARTTLS to encrypt the mail
+ exchange, a DNS lookup for the key unnecessarily identifies the
+ local-part of the recipients mail address to any passive
+ eavesdroppers.
+
+ This memo specified a new method for key discovery using an encrypted
+ https connection.
+
+3.1. Key Discovery
+
+ Although URIs are able to encode all kind of characters,
+ straightforward implementations of a key directory may want to store
+ the local-part of a mail address directly in the file system. This
+ forbids the use of certain characters in the local-part. To allow
+ for such an implementation method the URI uses an encoded form of the
+ local-part which can be directly mapped to a file name.
+
+ OpenPGP defines its User IDs, and thus the mail address, as UTF-8
+ strings. To help with the common pattern of using capitalized names
+ (e.g. "Joe.Doe@example.org") for mail addresses, and under the
+ premise that almost all MTAs treat the local-part case-insensitive
+ and that the domain-part is required to be compared case-insensitive
+ anyway, all upper-case ASCII characters in a User ID are mapped to
+ lowercase. Non-ASCII characters are not changed.
+
+
+
+Koch Expires January 29, 2018 [Page 3]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ The so mapped local-part is hashed using the SHA-1 algorithm. The
+ resulting 160 bit digest is encoded using the Z-Base-32 method as
+ described in [RFC6189], section 5.1.6. The resulting string has a
+ fixed length of 32 octets. To form the URI, the following parts are
+ concatenated:
+
+ o The scheme "https://",
+
+ o the domain-part,
+
+ o the string "/.well-known/openpgpkey/hu/",
+
+ o and the above constructed 32 octet string.
+
+ For example the URI to lookup the key for Joe.Doe@Example.ORG is:
+
+ https://example.org/.well-known/openpgpkey/
+ hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q
+
+ (line has been wrapped for rendering purposes)
+
+ DNS SRV resource records ([RFC2782]) may be used to query a different
+ host or a port other than 443. For example:
+
+ _openpgpkey._tcp.example.org. IN SRV 0 0 8443 wkd.example.org.
+
+ changes the above to query the host "wkd.example.org" at port 8443
+ instead of the host "example.org" at port 443. The target (in the
+ example "wkd.example.org") MUST be a sub-domain of the domain-part
+ (here "example.org"). If the target is not a sub-domain, the SRV RR
+ MUST be be ignored. The recommended name for the sub-domain is
+ "wkd".
+
+ The HTTP GET method MUST return the binary representation of the
+ OpenPGP key for the given mail address. The key needs to carry a
+ User ID packet ([RFC4880]) with that mail address. Note that the key
+ may be revoked or expired - it is up to the client to handle such
+ conditions. To ease distribution of revoked keys, a server may
+ return revoked keys in addition to a new key. The keys are returned
+ by a single request as concatenated key blocks.
+
+ The server MUST accept the HTTP HEAD method to allow a client to
+ check for the existence of a key.
+
+ The server SHOULD use "application/octet-string" as the Content-Type
+ for the data but clients SHOULD also accept any other Content-Type.
+ The server MUST NOT return an ASCII armored version of the key.
+
+
+
+
+Koch Expires January 29, 2018 [Page 4]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+4. Web Key Directory Update Protocol
+
+ To put keys into the key directory a protocol to automate the task is
+ desirable. The protocol defined here is entirely based on mail and
+ the assumption that a mail provider can securely deliver mail to the
+ INBOX of a user (e.g. an IMAP folder). Note that the same protocol
+ may also be used for submitting keys for use with OpenPGP DANE.
+
+ We assume that the user already created a key for her mail account
+ alice@example.org. To install the key at her provider's Web Key
+ Directory, she performs the following steps:
+
+ 1. She retrieves a file which contains one line with the mail
+ address used to submit the key to the mail provider. The DNS SRV
+ rules described for the Web Key Directory apply here as well.
+ See below for the syntax of that file. For a mail address at the
+ domain "example.org" the URI of the file is
+
+ https://example.org/.well-known/openpgpkey/submission-address
+
+ 2. She sends her key using SMTP (or any other transport mechanism)
+ to the provider using the submission address and key format as
+ specified by PGP/MIME.
+
+ 3. The provider checks that the received key has a User ID which
+ matches an account name of the provider.
+
+ 4. The provider sends an encrypted message containing a nonce and
+ the fingerprint of the key to the mail account of the user. Note
+ that a similar scheme is used by the well known caff(1) tool to
+ help with key signing parties.
+
+ 5. A legitimate user will be able to decrypt the message because she
+ created the key and is in charge of the private key. This step
+ verifies that the submitted key has actually been created by the
+ owner of the account.
+
+ 6. The user sends the decrypted nonce back to the submission address
+ as a confirmation that the private key is owned by her and that
+ the provider may now publish the key. Although technically not
+ required, it is suggested that the mail to the provider is
+ encrypted. The public key for this is retrieved using the key
+ lookup protocol described above.
+
+ 7. The provider receives the nonce, matches it with its database of
+ pending confirmations and then publishes the key. Finally the
+ provider sends a mail back to the user to notify her of the
+ publication of her key.
+
+
+
+Koch Expires January 29, 2018 [Page 5]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ The message data structures used for the above protocol are specified
+ in detail below. In the following sections the string "WELLKNOWN"
+ denotes the first part of an URI specific for a domain. In the
+ examples the domain "example.org" is assumed, thus
+
+ WELLKNOWN := https://example.org/.well-known/openpgpkey
+
+ The term "target key" denotes the to be published key, the term
+ "submission key" the key associated with the submission-address of
+ the mail provider.
+
+4.1. The Submission Address
+
+ The address of the submission file is
+
+ WELLKNOWN/submission-address
+
+ The file consists of exactly one line, terminated by a LF, or the
+ sequence of CR and LF, with the full mail address to be used for
+ submission of a key to the mail provider. For example the content of
+ the file may be
+
+ key-submission-example.org@directory.example.org
+
+4.2. The Submission Mail
+
+ The mail used to submit a key to the mail provider MUST comply to the
+ PGP/MIME specification ([RFC3156], section 7), which states that the
+ Content-Type must be "application/pgp-keys", there are no required or
+ optional parameters, and the body part contains the ASCII-armored
+ transferable Public Key Packets as defined in [RFC4880], section
+ 11.1.
+
+ The mail provider MUST publish a key capable of signing and
+ encryption for the submission-address in the Web Key Directory or via
+ DANE. The key to be published MUST be submitted using a PGP/MIME
+ encrypted message ([RFC3156], section 4). The message MUST NOT be
+ signed (because the authenticity of the signing key has not yet been
+ confirmed). After decryption of the message at the mail provider a
+ single "application/pgp-keys" part, as specified above, is expected.
+
+4.3. The Confirmation Request
+
+ The mail provider sends a confirmation mail in response to a received
+ key publication request. The message MUST be sent from the
+ submission-address of the mail provider to the mail address extracted
+ from the target key. The message needs to be a PGP/MIME signed
+
+
+
+
+Koch Expires January 29, 2018 [Page 6]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ message using the submission key of the provider for the signature.
+ The signed message MUST have two parts:
+
+ The first part MUST have "text" as its Content-Type and can be used
+ to explain the purpose of the mail. For example it may point to this
+ RFC and explain on how to manually perform the protocol.
+
+ The second part MUST have "application/vnd.gnupg.wks" as its Content-
+ Type and carry an OpenPGP encrypted message in ASCII Armor format.
+ The message MUST be encrypted to the target key and MUST NOT be
+ signed. After decryption a text file in the Web Key data format must
+ be yielded.
+
+ That data format consists of name-value pairs with one name-value
+ pair per LF or CR+LF terminated line. Empty lines are allowed and
+ will be ignored by the receiver. A colon is used to terminate a
+ name.
+
+ In a confirmation request the following names MUST be send in the
+ specified order:
+
+ o "type": The value must be "confirmation-request".
+
+ o "sender": This is the mailbox the user is expected to sent the
+ confirmation response to. The value must match the mailbox part
+ of the "From:" address of this request. Exactly one address MUST
+ be given.
+
+ o "address": The value is the addr-spec part of the target key's
+ mail address. The value SHOULD match the addr-spec part of the
+ recipient's address. The value MUST be UTF-8 encoded as required
+ for an OpenPGP User ID.
+
+ o "fingerprint": The value is the fingerprint of the target key.
+ The fingerprint is given in uppercase hex encoding without any
+ interleaving spaces.
+
+ o "nonce": The value is a string with a minimum length of 16 octets
+ and a maximum length of 64 octets. The string must entirely be
+ made up of random ASCII letters or digits. This nonce will be
+ sent back to the mail provider as proof that the recipient is the
+ legitimate owner of the target-key.
+
+ The receiver of that message is expected to verify the outer
+ signature and disregard the entire message if it can't be verified or
+ has not been signed by the key associated with the submission
+ address.
+
+
+
+
+Koch Expires January 29, 2018 [Page 7]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ After the message as been verified the receiver decrypts the second
+ part of the message, checks that the "fingerprint" matches the target
+ key, checks that the "address" matches a User ID of the target key,
+ and checks the other constrains of the request format. If any
+ constraint is not asserted, or the fingerprint or User ID do not
+ match the target key, or there is no pending publication requests
+ (i.e. a mail recently sent o the submission address), the user MAY be
+ notified about this fake confirmation attempt.
+
+ In other cases the confirmation request is legitimate and the MUA
+ shall silently send a response as described in the next section.
+
+ The rationale for the outer signature used with this request is to
+ allow early detection of spam mails. This can be done prior to the
+ decryption step and avoids asking the user to enter a passphrase to
+ perform the decryption for a non-legitimate message. The use of a
+ simple encrypted attachment, instead of using PGP/MIME encryption, is
+ to convey the Content-Type of that attachment in the clear and also
+ to prevent automatic decryption of that attachment by PGP/MIME aware
+ clients. The MUA may in fact detect this confirmation request and
+ present a customized dialog for confirming that request.
+
+4.4. The Confirmation Response
+
+ A response to a confirmation request MUST only be send in the
+ positive case; there is no negative confirmation response. A mail
+ service provider is expected to cancel a pending key submission after
+ a suitable time without a confirmation. The mail service provider
+ SHOULD NOT retry the sending of a confirmation request after the
+ first request has been send successfully.
+
+ The user MUST send the confirmation response from her target mail
+ address to the "from" address of the confirmation request. The
+ message MUST be signed and encrypted using the PGP/MIME Combined
+ format ([RFC3156], section 6.2). The signing key is the target key
+ and the encryption key is the key associated with the provider's
+ submission address.
+
+ The Content-Type used for the plaintext message MUST also be
+ "application/vnd.gnupg.wks". The format is the same as described
+ above for the Confirmation Request. The body must contain three
+ name-value pairs in this order:
+
+ o "type": The value must be "confirmation-response".
+
+ o "sender": The value must match the mailbox part of the "From:"
+ address of this response. Exactly one address MUST be given.
+
+
+
+
+Koch Expires January 29, 2018 [Page 8]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ o "nonce": The value is the value of the "nonce" parameter from the
+ confirmation request.
+
+4.5. Policy Flags
+
+ For key generation and submission it is sometimes useful to tell the
+ client about certain properties of the mail provider in advance.
+ This can be done with a file at the URL
+
+ WELLKNOWN/policy
+
+ The file contains keywords and optioanlly values, one per line with
+ each line terminated by a LF or the sequence of CR and LF. Empty
+ lines and lines starting with a '#' character are considered comment
+ lines. A keyword is made up of lowercase letters, digits, hyphens,
+ or dots. An underscore is allowed as a name space delimiters; see
+ below. The first character must be a letter. Keywords which are
+ defined to require a value are directly followed by a colon and then
+ after optional white space the value. Clients MUST use case-
+ insensitive matching for the keyword.
+
+ Currently defined keywords are:
+
+ o "mailbox-only": The mail server provider does only accept keys
+ with only a mailbox in the User ID. In particular User IDs with a
+ real name in addition to the mailbox will be rejected as invalid.
+
+ o "dane-only": The mail server provider does not run a Web Key
+ Directory but only an OpenPGP DANE service. The Web Key Directory
+ Update protocol is used to update the keys for the DANE service.
+
+ o "auth-submit": The submission of the mail to the server is done
+ using an authenticated connection. Thus the submitted key will be
+ published immediately without any confirmation request.
+
+ More keywords will be defined in updates to this I-D. There is no
+ registry except for this document. For experimental use of new
+ features or for provider specific settings, keywords MUST be prefixed
+ with a domain name and an underscore.
+
+5. Security Considerations
+
+ The use of SHA-1 for the mapping of the local-part to a fixed string
+ is not a security feature but merely used to map the local-part to a
+ fixed-sized string made from a well defined set of characters. It is
+ not intended to conceal information about a mail address.
+
+
+
+
+
+Koch Expires January 29, 2018 [Page 9]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ The domain name part of the mail address is not part of the hash to
+ avoid problems with internationalized domain names. Instead a
+ separate URL is required for each domain name.
+
+ The use of DNS SRV records reduces the certainty that a mail address
+ belongs to a domain. For example an attacker may change the target
+ to a host in a sub-domain under their control and thus gain full
+ control over all keys. An implementation may want to weight the
+ certainty of a mapping different if it has been retrieved via a sub-
+ domain and in particular if a non-recommended name is used for the
+ sub-domain.
+
+6. IANA Considerations
+
+6.1. Well-Known URI
+
+ IANA is requested to assign a well-known URI in the "Well-Known URIs"
+ registry as defined by [RFC5785]:
+
+ URI suffix: openpgpkey
+
+ Change controller: IETF
+
+ Specification document: This
+
+7. Acknowledgments
+
+ The author would like to acknowledge the help of the individuals who
+ kindly voiced their opinions on the GnuPG mailing lists, in
+ particular, the help of Bernhard Reiter and Guilhem Moulin.
+
+8. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ DOI 10.17487/RFC2782, February 2000,
+ .
+
+ [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
+ "MIME Security with OpenPGP", RFC 3156, August 2001.
+
+ [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+ Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
+
+
+
+
+
+Koch Expires January 29, 2018 [Page 10]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
+ Uniform Resource Identifiers (URIs)", RFC 5785, DOI
+ 10.17487/RFC5785, April 2010,
+ .
+
+ [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
+ Media Path Key Agreement for Unicast Secure RTP", RFC
+ 6189, DOI 10.17487/RFC6189, April 2011,
+ .
+
+Appendix A. Sample Protocol Run
+
+ The following non-normative example can be used by implementors as
+ guidance.
+
+ Note that GnuPG version 2.1.12 supports the key discovery described
+ in version -00 of this document (auto-key-locate method "wkd").
+ Version 2.1.16 can run the protocol decribed in this document but is
+ also able to run the protocol version specified by -01.
+
+A.1. Sample Keys
+
+ This is the provider's submission key:
+
+ -----BEGIN PGP PRIVATE KEY BLOCK-----
+
+ lFgEV/TAohYJKwYBBAHaRw8BAQdAB/k9YQfSTI8qQqqK1KimH/BsvzsowWItSQPT
+ FP+fOC4AAP46uJ3Snno3Vy+kORye3rf0VvWvuz82voEQLxG6WpfHhREEtBprZXkt
+ c3VibWlzc2lvbkBleGFtcGxlLm5ldIh5BBMWCAAhBQJX9MCiAhsDBQsJCAcCBhUI
+ CQoLAgQWAgMBAh4BAheAAAoJEKhtNooW0cqEWMUA/0e9XaeptszWC9ZvPg8INL6a
+ BvRqPBYGU7PGmuXsxBovAQDyckOykG0UAfHVyN1w4gSK/biMcnqVr857i8/HuvjW
+ C5xdBFf0wKISCisGAQQBl1UBBQEBB0Apvaoe4MtSEJ1fpds/4DFl2kXXBpnVji/s
+ Wg9btdthNQMBCAcAAP9FJX99T1LEJzBnvBBnc6bimnT6/1OKM9RdO4R0/uVP6BFL
+ iGEEGBYIAAkFAlf0wKICGwwACgkQqG02ihbRyoTlGwD9FBr92osjL7HkhhZZ7Z2D
+ My3b9zpoZeMjvPg5YPqpdKMA/jhZoHuZCRMBYf7YRFb8aXtuyetDFZYrkjnum+OG
+ HFAD
+ =Hnwd
+ -----END PGP PRIVATE KEY BLOCK-----
+
+ This is the target key to be published:
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires January 29, 2018 [Page 11]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ -----BEGIN PGP PRIVATE KEY BLOCK-----
+
+ lFgEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
+ nTEoBRkAAP94nCZMM4WY2IORXfM6phLGSz3RsHvs/vA1Opaus4+R3BKJtBtwYXRy
+ aWNlLmx1bXVtYmFAZXhhbXBsZS5uZXSIeQQTFggAIQUCV2o9XQIbAwULCQgHAgYV
+ CAkKCwIEFgIDAQIeAQIXgAAKCRATlWNoKgINCpkNAQDFDcwJUzsxu7aJUiPdpYXj
+ 4uVarrXakxEE8mGFotWhLAD9GH4rqLDYIE3NKEU0s+Okt4tEIwJaV8H1NNPPPMiK
+ 3g2cXQRXaj2NEgorBgEEAZdVAQUBAQdAFnnmZc99TuKk5iCq9wmYZUVF2RcXN2Cs
+ qAl8iGQQUWsDAQgHAAD/VN/VGmlcwGBPcLTya2hfU4t37nMcFCKdNSXjJ5DFA0AP
+ PohhBBgWCAAJBQJXaj2NAhsMAAoJEBOVY2gqAg0Ky4UA/0GmVaXzXemLvv1Xw4yx
+ Eaz/KfKKGc4RJ+38fyqUzw8NAQCohQ+ki3I5f84EXLZEiUiLsnVtOn1HNxvND/gW
+ TiFZBA==
+ =GHi7
+ -----END PGP PRIVATE KEY BLOCK-----
+
+A.2. Sample Messages
+
+ The first message triggeres the publication requests.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires January 29, 2018 [Page 12]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ From: patrice.lumumba@example.net
+ To: key-submission@example.net
+ Subject: Key publishing request
+ MIME-Version: 1.0
+ Content-Type: multipart/encrypted;
+ protocol="application/pgp-encrypted";
+ boundary="=-=01-e8k41e11ob31eefa36wo=-="
+ Date: Wed, 05 Oct 2016 10:15:51 +0000
+
+
+ --=-=01-e8k41e11ob31eefa36wo=-=
+ Content-Type: application/pgp-encrypted
+
+ Version: 1
+
+ --=-=01-e8k41e11ob31eefa36wo=-=
+ Content-Type: application/octet-stream
+
+ -----BEGIN PGP MESSAGE-----
+
+ hF4DUgLY5tvmW2sSAQdAR1AcqvFpQe/fHRZbf0xcnl9Tb+AtwaX2yZnZXGELGHsw
+ 1/e3E0JptwM5tpRAVe71ooF8Zq4jl76ZgQKfj/SyjpLJxyoEDy2N5wTQaqW4JtML
+ 0ukB1vh7dIRDxBJX/LQIJC0wz8o1Q3vjcLJKFFvDb7YrerABpPIzwOAupcgIbQHj
+ 5m1+2WU5CL8ffyJy2h1jV2X4OnvWF1Sn6J6SVD6DfZpOPRt9TxSemJrN1LJ3lG0N
+ ts8AuYmCOeC1H2r5TYyxqkC98JF8+Nvyxd/fwne8IOjK9uixkNMC5H9/ZOH0YWCb
+ wBnNB4iXuym4OIPxiLkDymsVF0ww/XrODE9Y259EGmO45VFNrJAX3HFs9/PcMCVk
+ n2qMyEkr8LHiXeEPun6Z54RHUPYv2cUkEZ0hhSJ+rtBxkc/5D/cAScCEXRKFSKEF
+ jLJAvLK/u/ga5DAzVai+vh6b6Bq+YVPaD9GWMhWj4CgR90p9LULi6S/Hzwhv9Wzf
+ 8fJoJOaDjyvRDgr09jYLWamxkS9NWxqwy6MXJvxwbNdd5XtqiW4Y4o0Ll1hDJhxR
+ ljn/XvotXKwhKN+4QGhIXDVt4Dl4XxS5ptWfVTau8W8DYqDsU2obEcfsirZv53M1
+ Q9FCD8CD9+dkBt8VAJekCWVhEltcRHxlrznbk2jxm93xSD2o6gZ5X0VSaSUXyEhm
+ J+8F3gyTHGgbq/TgyjFoockWh5EtGgAFuWvmPJCF5PO/UaNeoKwgwSJBu6oTXkHx
+ R4nvvMRcj5UgTsKpZ79NiDQukbjG5ScNT5TCUiiZsBXBqBx3fD61EH6cAuh4P3Kr
+ iM7PY4fwAHo890Dx+Qlt
+ =WIhx
+ -----END PGP MESSAGE-----
+
+ --=-=01-e8k41e11ob31eefa36wo=-=--
+
+ The server decrypts this message to
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires January 29, 2018 [Page 13]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ Content-Type: application/pgp-keys
+
+ -----BEGIN PGP PUBLIC KEY BLOCK-----
+
+ mDMEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
+ nTEoBRm0G3BhdHJpY2UubHVtdW1iYUBleGFtcGxlLm5ldIh5BBMWCAAhBQJXaj1d
+ AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEBOVY2gqAg0KmQ0BAMUNzAlT
+ OzG7tolSI92lhePi5VqutdqTEQTyYYWi1aEsAP0YfiuosNggTc0oRTSz46S3i0Qj
+ AlpXwfU00888yIreDbg4BFdqPY0SCisGAQQBl1UBBQEBB0AWeeZlz31O4qTmIKr3
+ CZhlRUXZFxc3YKyoCXyIZBBRawMBCAeIYQQYFggACQUCV2o9jQIbDAAKCRATlWNo
+ KgINCsuFAP9BplWl813pi779V8OMsRGs/ynyihnOESft/H8qlM8PDQEAqIUPpIty
+ OX/OBFy2RIlIi7J1bTp9RzcbzQ/4Fk4hWQQ=
+ =qRfF
+ -----END PGP PUBLIC KEY BLOCK-----
+
+ and returns this confirmation request
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires January 29, 2018 [Page 14]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ From: key-submission@example.net
+ To: patrice.lumumba@example.net
+ Subject: Confirm your key publication
+ MIME-Version: 1.0
+ Content-Type: multipart/encrypted;
+ protocol="application/pgp-encrypted";
+ boundary="=-=01-wrzqued738dfx4x97u7y=-="
+ Date: Wed, 05 Oct 2016 10:16:57 +0000
+
+
+ --=-=01-wrzqued738dfx4x97u7y=-=
+ Content-Type: application/pgp-encrypted
+
+ Version: 1
+
+ --=-=01-wrzqued738dfx4x97u7y=-=
+ Content-Type: application/octet-stream
+
+ -----BEGIN PGP MESSAGE-----
+
+ hF4DkYWHjk/NdMASAQdAluQeqhECpU2T0zEyBAEbFzhLkpubN160wjkFCrtUc0Mw
+ FwYgM2fp9cvTMdJ/xjkvmAcIEOT4AY/hn1yFQ4z0KG0gCkSac+8mkDylnPdxlXYw
+ 0sBSAXlbqpVA7eUpFuU2Zs10zbIXxlwe6osR5wUIJut/RCOsYQmfvxC55x8mUX5/
+ zgTnNzlMzye5ws4pTgAeQm2x0Yv018L8IZgY5KxwJLBzlss0wLZ45ZcS80hR11Fx
+ NCow1fKF8lMnOJxagTEOih807nctz8vT5bR1gx0d7N3LM+th8nAg9/6Ghf1XTpLo
+ MzwGW0FtOG7Dg1Uxbw2bjaOuRBeh6IIpmNAw1pmIfnNu7PpoRydU5w1K/R8MT06z
+ MKdJ7IW5mVGes9EGnG3e4mjuILvNaZhfYy+a73IhDSaPm3oqdl1Qx7tbNg6lGjn6
+ KStCYAcPGPp3m7aWkfsPGThOVRhEXqaFFywfwSVEj1pdIRjDFA==
+ =Cdjh
+ -----END PGP MESSAGE-----
+
+ --=-=01-wrzqued738dfx4x97u7y=-=--
+
+ The client decrypts the attachment as
+
+ Content-Type: application/vnd.gnupg.wks
+ Content-Transfer-Encoding: 8bit
+
+ type: confirmation-request
+ sender: key-submission@example.net
+ address: patrice.lumumba@example.net
+ fingerprint: B21DEAB4F875FB3DA42F1D1D139563682A020D0A
+ nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
+
+ creates this response
+
+
+
+
+
+
+Koch Expires January 29, 2018 [Page 15]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+ Content-Type: application/vnd.gnupg.wks
+ Content-Transfer-Encoding: 8bit
+
+ type: confirmation-response
+ sender: key-submission@example.net
+ address: patrice.lumumba@example.net
+ nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
+
+ and sends it encrypted to the server
+
+ From: patrice.lumumba@example.net
+ To: key-submission@example.net
+ Subject: Key publication confirmation
+ MIME-Version: 1.0
+ Content-Type: multipart/encrypted;
+ protocol="application/pgp-encrypted";
+ boundary="=-=01-iacqg4og4pqz11a5cg1o=-="
+ Date: Wed, 05 Oct 2016 10:18:52 +0000
+
+
+ --=-=01-iacqg4og4pqz11a5cg1o=-=
+ Content-Type: application/pgp-encrypted
+
+ Version: 1
+
+ --=-=01-iacqg4og4pqz11a5cg1o=-=
+ Content-Type: application/octet-stream
+
+ -----BEGIN PGP MESSAGE-----
+
+ hF4DUgLY5tvmW2sSAQdAnB1C3PMjS4AsGU0qaCqBdWQO5i6blWEyZrEsY+JZY1Qw
+ ooNq7zdVWOHhL9LPGAALAgoL3Qfz+dN2u5QamSQ/LJ2c8M0XipNs3lqlNH63yQN1
+ 0sAmAc3W8xkwul+rf6OLK/gMi6WzM4fnUhd4D1LJGIJoNUN0l3636C7ecOt2lkMl
+ 5bVAYg/SyMT3ymyfQnvtiem2T5DSnPsS1g6n6QNXWvkqvX9yGxNsNDJEHTuGJB8k
+ OJoRlfWQTEo6pgA89febWl1EdeM1pPLstQ2uZE8NPjXoY1nMxAlu+iPYsR41/4sg
+ dqwOv5BPLh/GIat8hh9SPWCA9iKlgSQ/EIv5DpjQogEzpriT55dkgfvSVYIAcOdO
+ ShZ91YKkcZffevdY72omqTk10a1SUXehPooIlRFmroDsi3VDaRKrUIo=
+ =7uve
+ -----END PGP MESSAGE-----
+
+ --=-=01-iacqg4og4pqz11a5cg1o=-=--
+
+Appendix B. Changes Since -03
+
+ o Fixed Content-Type in the description. The one used in the
+ example was correct.
+
+
+
+
+
+Koch Expires January 29, 2018 [Page 16]
+
+Internet-Draft OpenPGP Web Key Service July 2017
+
+
+Author's Address
+
+ Werner Koch
+ GnuPG Project
+
+ Email: wk@gnupg.org
+ URI: https://gnupg.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires January 29, 2018 [Page 17]
diff --git a/misc/id/openpgp-webkey-service/draft.org b/misc/id/openpgp-webkey-service/draft.org
index 5756e7d..6290b2e 100644
--- a/misc/id/openpgp-webkey-service/draft.org
+++ b/misc/id/openpgp-webkey-service/draft.org
@@ -1,447 +1,705 @@
# openpgp-webkey-service
#+startup: showall
#+options: toc:nil
#+macro: RFC [](#RFC$1)
#+macro: https_scheme ~https://~
#+begin_src rfc
+
]>
+ docName="draft-koch-openpgp-webkey-service-04">
OpenPGP Web Key Service
GnuPG Project
wk@gnupg.org
https://gnupg.org
-
+
Security
&pandocAbstract;
&pandocMiddle;
&rfc.2119;
+ &rfc.2782;
&rfc.3156;
&rfc.4880;
&rfc.5785;
&rfc.6189;
&pandocBack;
#+end_src
* Abstract
This specification describes a service to locate OpenPGP keys by mail
-address using a Web service and the HTTPS protocol. It also provides a
+address using a Web service and the HTTPS protocol. It also provides a
method for secure communication between the key owner and the mail
provider to publish and revoke the public key.
* Middle
* Introduction
This memo describes a method to associate OpenPGP keys with a mail
address and how to look them up using a web service with a well-known
-URI. In addition a mail based protocol is given to allow a client to
+URI. In addition a mail based protocol is given to allow a client to
setup such an association and to maintain it.
* Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in {{{RFC(2119)}}}.
* Web Key Directory
-A major use case for OpenPGP is the encryption of mail. A common
+A major use case for OpenPGP is the encryption of mail. A common
difficulty of sending encrypted mails to a new communication partner is
-to find the appropriate public key of the recipient. Unless an
+to find the appropriate public key of the recipient. Unless an
off-channel key exchange has been done, there are no easy ways to
-discover the required key. The common practice is to search the network
+discover the required key. The common practice is to search the network
of public key servers for a key matching the recipient's mail address.
This practise bears the problem that the keyservers are not able to give
a positive confirmation that a key actually belongs to the mail
-addresses given in the key. Further, there are often several keys
+addresses given in the key. Further, there are often several keys
matching a mail address and thus one needs to pick a key on good luck.
-This is clearly not a secure way to setup an end-to-end encryption. Even
+This is clearly not a secure way to setup an end-to-end encryption. Even
if the need for a trusted key for an initial mail message is
relinquished, a non-authenticated key may be a wrong one and the actual
recipient would receive a mail which she can't decrypt, due to the use
of a wrong key.
Methods to overcome this problem are
- sending an initial unencrypted message with the public key attached,
- using the OpenPGP DANE protocol to lookup the recipients key via the
DNS.
The first method has the obvious problems of not even trying to encrypt
the initial mail, an extra mail round-trip, and problems with unattended
key discovery.
The latter method works fine but requires that mail providers need to
-set up a separate DNS resolver to provide the key. The administration of
-a DNS zone is often not in the hands of small mail installations. Thus
+set up a separate DNS resolver to provide the key. The administration of
+a DNS zone is often not in the hands of small mail installations. Thus
an update of the DNS resource records needs to be delegated to the ISP
-running the DNS service. Further, DNS lookups are not encrypted and
-missing all confidentially. Even if the participating MUAs are using
+running the DNS service. Further, DNS lookups are not encrypted and
+missing all confidentially. Even if the participating MUAs are using
STARTTLS to encrypt the mail exchange, a DNS lookup for the key
unnecessarily identifies the local-part of the recipients mail address
to any passive eavesdroppers.
This memo specified a new method for key discovery using an encrypted
https connection.
** Key Discovery
Although URIs are able to encode all kind of characters, straightforward
-implementations of a key directory may want to store the "local-part" of
-a mail address directly in the file system. This forbids the use of
-certain characters in the "local-part". To allow for such an
-implementation method the URI uses an encoded form of the "local-part"
+implementations of a key directory may want to store the local-part of
+a mail address directly in the file system. This forbids the use of
+certain characters in the local-part. To allow for such an
+implementation method the URI uses an encoded form of the local-part
which can be directly mapped to a file name.
OpenPGP defines its User IDs, and thus the mail address, as UTF-8
-strings. To help with the common pattern of using capitalized names
+strings. To help with the common pattern of using capitalized names
(e.g. "Joe.Doe@example.org") for mail addresses, and under the premise
-that almost all MTAs treat the "local-part" case-insensitive and that
-the "domain-part" is required to be compared case-insensitive anyway,
+that almost all MTAs treat the local-part case-insensitive and that
+the domain-part is required to be compared case-insensitive anyway,
all upper-case ASCII characters in a User ID are mapped to lowercase.
Non-ASCII characters are not changed.
-The so mapped "local-part" is hashed using the SHA-1 algorithm. The
+The so mapped local-part is hashed using the SHA-1 algorithm. The
resulting 160 bit digest is encoded using the Z-Base-32 method as
-described in {{{RFC(6189)}}}, section 5.1.6. The resulting string has a
-fixed length of 32 octets. To form the URI, the scheme
-{{{https_scheme}}} is concatenated with the mapped "domain-part", the
-fixed string ~./well-known/openpgpkey/hu/~, and the above constructed
-32 octet string.
+described in {{{RFC(6189)}}}, section 5.1.6. The resulting string has
+a fixed length of 32 octets. To form the URI, the following parts are
+concatenated:
+
+- The scheme {{{https_scheme}}},
+- the domain-part,
+- the string ~/.well-known/openpgpkey/hu/~,
+- and the above constructed 32 octet string.
For example the URI to lookup the key for Joe.Doe@Example.ORG is:
#+BEGIN_EXAMPLE
https://example.org/.well-known/openpgpkey/
hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q
#+END_EXAMPLE
(line has been wrapped for rendering purposes)
-The HTTP GET method MUST return the binary representation of the OpenPGP
-key for the given mail address. The key needs to carry a User ID packet
-({{{RFC(4880)}}}) with that mail address. Note that the key may be
-revoked or expired - it is up to the client to handle such conditions.
-The server MUST also accept a HEAD method so that a client may only
+DNS SRV resource records ({{{RFC(2782)}}}) may be used to query a
+different host or a port other than 443. For example:
+
+#+BEGIN_EXAMPLE
+_openpgpkey._tcp.example.org. IN SRV 0 0 8443 wkd.example.org.
+#+END_EXAMPLE
+
+changes the above to query the host "wkd.example.org" at port
+8443 instead of the host "example.org" at port 443. The target (in the
+example "wkd.example.org") MUST be a sub-domain of the domain-part
+(here "example.org"). If the target is not a sub-domain, the SRV RR
+MUST be be ignored. The recommended name for the sub-domain is "wkd".
+
+The HTTP GET method MUST return the binary representation of the
+OpenPGP key for the given mail address. The key needs to carry a User
+ID packet ({{{RFC(4880)}}}) with that mail address. Note that the key
+may be revoked or expired - it is up to the client to handle such
+conditions. To ease distribution of revoked keys, a server may return
+revoked keys in addition to a new key. The keys are returned by a
+single request as concatenated key blocks.
+
+The server MUST accept the HTTP HEAD method to allow a client to
check for the existence of a key.
-The server SHOULD return "application/octet-string" as the content-type
-for the data but clients MAY also accept any other appropriate
-content-type. The server MUST NOT return an ASCII armored version of the
-key.
+The server SHOULD use "application/octet-string" as the
+Content-Type for the data but clients SHOULD also accept any other
+Content-Type. The server MUST NOT return an ASCII armored version of
+the key.
+
* Web Key Directory Update Protocol
To put keys into the key directory a protocol to automate the task is
-desirable. The protocol defined here is entirely based on mail and the
-assumption that a mail provider can securely deliver mail to the INBOX
-of a user (e.g. an IMAP folder). Note that the same protocol may also be
-used for submitting keys for use with OpenPGP DANE.
+desirable. The protocol defined here is entirely based on mail and
+the assumption that a mail provider can securely deliver mail to the
+INBOX of a user (e.g. an IMAP folder). Note that the same protocol
+may also be used for submitting keys for use with OpenPGP DANE.
We assume that the user already created a key for her mail account
-alice@example.org. To install the key at her provider's Web Key
+alice@example.org. To install the key at her provider's Web Key
Directory, she performs the following steps:
1. She retrieves a file which contains one line with the mail address
- used to submit the key to the mail provider. See below for the syntax
- of that file. For a mail address at the domain "example.org" the URI
- of the file is
+ used to submit the key to the mail provider. The DNS SRV rules
+ described for the Web Key Directory apply here as well. See below
+ for the syntax of that file. For a mail address at the domain
+ "example.org" the URI of the file is
#+begin_example
https://example.org/.well-known/openpgpkey/submission-address
#+end_example
2. She sends her key using SMTP (or any other transport mechanism) to
the provider using the submission address and key format as specified
by PGP/MIME.
3. The provider checks that the received key has a User ID which matches
an account name of the provider.
4. The provider sends an encrypted message containing a nonce and the
- fingerprint of the key to the mail account of the user. Note that a
+ fingerprint of the key to the mail account of the user. Note that a
similar scheme is used by the well known caff(1) tool to help with
key signing parties.
5. A legitimate user will be able to decrypt the message because she
- created the key and is in charge of the private key. This step
+ created the key and is in charge of the private key. This step
verifies that the submitted key has actually been created by the
owner of the account.
-6. The user sends the decrypted nonce back to the submission address as
- a confirmation that the private key is owned by her and that the
- provider may now publish the key. Also technically not required, it
- is suggested that the mail to the provider is encrypted. The public
- key for this is retrieved using the key lookup protocol described
- above.
+6. The user sends the decrypted nonce back to the submission address
+ as a confirmation that the private key is owned by her and that the
+ provider may now publish the key. Although technically not
+ required, it is suggested that the mail to the provider is
+ encrypted. The public key for this is retrieved using the key
+ lookup protocol described above.
7. The provider receives the nonce, matches it with its database of
- pending confirmations and then publishes the key. Finally the
- provider sends a mail back to the user to notify her of the the
+ pending confirmations and then publishes the key. Finally the
+ provider sends a mail back to the user to notify her of the
publication of her key.
The message data structures used for the above protocol are specified in
-detail below. In the following sections the string "WELLKNOWN" denotes
-the first part of an URI specific for a domain. In the examples the
+detail below. In the following sections the string "WELLKNOWN" denotes
+the first part of an URI specific for a domain. In the examples the
domain "example.org" is assumed, thus
#+BEGIN_EXAMPLE
WELLKNOWN := https://example.org/.well-known/openpgpkey
#+END_EXAMPLE
The term "target key" denotes the to be published key, the term
"submission key" the key associated with the submission-address of the
mail provider.
** The Submission Address
The address of the submission file is
#+BEGIN_EXAMPLE
WELLKNOWN/submission-address
#+END_EXAMPLE
The file consists of exactly one line, terminated by a LF, or the
sequence of CR and LF, with the full mail address to be used for
-submission of a key to the mail provider. For example the content of the
+submission of a key to the mail provider. For example the content of the
file may be
#+BEGIN_EXAMPLE
key-submission-example.org@directory.example.org
#+END_EXAMPLE
** The Submission Mail
The mail used to submit a key to the mail provider MUST comply to the
PGP/MIME specification ({{{RFC(3156)}}}, section 7), which states that
the Content-Type must be "application/pgp-keys", there are no required
or optional parameters, and the body part contains the ASCII-armored
transferable Public Key Packets as defined in {{{RFC(4880)}}}, section
11.1.
-If the mail provider has published an encryption key for the
-submission-address in the Web Key Directory, the key to be published
-MUST be submitted using a PGP/MIME encrypted message ({{{RFC(3156)}}},
-section 4). The message MUST NOT be signed (because the authenticity of
-the signing key has not yet been confirmed). After decryption of the
-message at the mail provider a single "application/pgp-keys" part, as
-specified above, is expected.
+The mail provider MUST publish a key capable of signing and encryption
+for the submission-address in the Web Key Directory or via DANE. The
+key to be published MUST be submitted using a PGP/MIME encrypted
+message ({{{RFC(3156)}}}, section 4). The message MUST NOT be signed
+(because the authenticity of the signing key has not yet been
+confirmed). After decryption of the message at the mail provider a
+single "application/pgp-keys" part, as specified above, is expected.
** The Confirmation Request
The mail provider sends a confirmation mail in response to a received
-key publication request. The message SHOULD be sent from the
+key publication request. The message MUST be sent from the
submission-address of the mail provider to the mail address extracted
-from the target key. The message needs to be encrypted to the target key
-and MAY be signed by the submission key. PGP/MIME MUST be used for
-encryption and signing; the Combined method ({{{RFC(3156)}}}, section
-6.2) MUST be used if the message is to be signed.
+from the target key. The message needs to be a PGP/MIME signed
+message using the submission key of the provider for the
+signature. The signed message MUST have two parts:
-The Content-type used for the plaintext part MUST be
-"application/vnd.gnupg.wkd". The body consists of name-value pairs with
-one name-value pair per LF or CR+LF terminated line. Empty lines are
-allowed and will be ignored by the receiver. A colon is used to
-terminate a name.
+The first part MUST have "text" as its Content-Type and can be used to
+explain the purpose of the mail. For example it may point to this RFC
+and explain on how to manually perform the protocol.
-In a confirmation request the following names MUST be send in the
-specified order:
-
-- "type" :: The value must be "confirmation-request".
-
-- "sender" :: This is the mailbox the user is expected to sent the
- confirmation response to. The value must match the
- mailbox part of the "From:" address of this
- request. Exactly one address MUST be given.
+The second part MUST have "application/vnd.gnupg.wks" as its
+Content-Type and carry an OpenPGP encrypted message in ASCII Armor
+format. The message MUST be encrypted to the target key and MUST NOT
+be signed. After decryption a text file in the Web Key data format
+must be yielded.
-- "address" :: The value is the addr-spec part of the target key's
- mail address. The value SHOULD match the addr-spec part
- of the recipient's address. The value MUST be UTF-8
- encoded as required for an OpenPGP User ID.
+That data format consists of name-value pairs with one name-value pair
+per LF or CR+LF terminated line. Empty lines are allowed and will be
+ignored by the receiver. A colon is used to terminate a name.
-- "fingerprint" :: The value is the fingerprint of the target key. The
- fingerprint is given in uppercase hex encoding
- without any interleaving spaces.
-
-- "nonce" :: The value is a string with a minimum length of 16 octets
- and a maximum length of 64 octets. The string must
- entirely be made up of random ASCII letters or
- digits. This nonce will be sent back to the mail provider
- as proof that the recipient is the legitimate owner of
- the target-key.
+In a confirmation request the following names MUST be send in the
+specified order:
-The receiver of the message decrypts the message, checks that the
-"fingerprint" matches the target key, checks that the "address" matches
-a User ID of the target key, and checks the other constrains of the
-request format. If any constraint is not asserted, or the fingerprint or
-User ID do not match the target key, or there is no pending publication
-requests (i.e. a mail recently sent o the submission address), the user
-MAY be notified about this fake confirmation attempt.
+- type :: The value must be "confirmation-request".
+
+- sender :: This is the mailbox the user is expected to sent the
+ confirmation response to. The value must match the
+ mailbox part of the "From:" address of this
+ request. Exactly one address MUST be given.
+
+- address :: The value is the addr-spec part of the target key's
+ mail address. The value SHOULD match the addr-spec part
+ of the recipient's address. The value MUST be UTF-8
+ encoded as required for an OpenPGP User ID.
+
+- fingerprint :: The value is the fingerprint of the target key. The
+ fingerprint is given in uppercase hex encoding
+ without any interleaving spaces.
+
+- nonce :: The value is a string with a minimum length of 16 octets
+ and a maximum length of 64 octets. The string must
+ entirely be made up of random ASCII letters or
+ digits. This nonce will be sent back to the mail provider
+ as proof that the recipient is the legitimate owner of
+ the target-key.
+
+The receiver of that message is expected to verify the outer signature
+and disregard the entire message if it can't be verified or has not
+been signed by the key associated with the submission address.
+
+After the message as been verified the receiver decrypts the second part
+of the message, checks that the "fingerprint" matches the target key,
+checks that the "address" matches a User ID of the target key, and
+checks the other constrains of the request format. If any constraint
+is not asserted, or the fingerprint or User ID do not match the target
+key, or there is no pending publication requests (i.e. a mail recently
+sent o the submission address), the user MAY be notified about this
+fake confirmation attempt.
+
+In other cases the confirmation request is legitimate and the MUA
+shall silently send a response as described in the next section.
+
+The rationale for the outer signature used with this request is to
+allow early detection of spam mails. This can be done prior to the
+decryption step and avoids asking the user to enter a passphrase to
+perform the decryption for a non-legitimate message. The use of a
+simple encrypted attachment, instead of using PGP/MIME encryption, is
+to convey the Content-Type of that attachment in the clear and also to
+prevent automatic decryption of that attachment by PGP/MIME aware
+clients. The MUA may in fact detect this confirmation request and
+present a customized dialog for confirming that request.
-In other cases the confirmation request is legitimate and the MUA shall
-silently send a response as described in the next section.
** The Confirmation Response
A response to a confirmation request MUST only be send in the positive
-case; there is no negative confirmation response. A mail service
+case; there is no negative confirmation response. A mail service
provider is expected to cancel a pending key submission after a suitable
-time without a confirmation. The mail service provider SHOULD NOT retry
+time without a confirmation. The mail service provider SHOULD NOT retry
the sending of a confirmation request after the first request has been
send successfully.
The user MUST send the confirmation response from her target mail
-address to the "from" address of the confirmation request. The message
-MUST be signed and SHOULD be encrypted. The PGP/MIME Combined format
-MUST be used for encryption and signing ({{{RFC(3156)}}}, section 6.2).
-The encryption key can be taken from the Web Key Directory.
-
-The Content-type used for the plaintext message MUST also be
-"application/vnd.gnupg.wkd". The format is the same as described above
-for the Confirmation Request. The body must contain three name-value
+address to the "from" address of the confirmation request. The
+message MUST be signed and encrypted using the PGP/MIME Combined
+format ({{{RFC(3156)}}}, section 6.2). The signing key is the target
+key and the encryption key is the key associated with the provider's
+submission address.
+
+The Content-Type used for the plaintext message MUST also be
+"application/vnd.gnupg.wks". The format is the same as described above
+for the Confirmation Request. The body must contain three name-value
pairs in this order:
-- "type" :: The value must be "confirmation-response".
+- type :: The value must be "confirmation-response".
-- "sender" :: The value must match the mailbox part of the "From:"
- address of this response. Exactly one address MUST be
- given.
+- sender :: The value must match the mailbox part of the "From:"
+ address of this response. Exactly one address MUST be
+ given.
-- "nonce" :: The value is the value of the "nonce" parameter from the
- confirmation request.
+- nonce :: The value is the value of the "nonce" parameter from the
+ confirmation request.
** Policy Flags
For key generation and submission it is sometimes useful to tell the
-client about certain properties of the mail provider in advance. This
+client about certain properties of the mail provider in advance. This
can be done with a file at the URL
#+BEGIN_EXAMPLE
WELLKNOWN/policy
#+END_EXAMPLE
-The file contains keywords, one per line with each line terminated by a
-LF or the sequence of CR and LF. Empty lines and lines starting with a
-'#' character are considered comment lines. A keyword is made up of
-lowercase letters, digits, hyphens, or dots. An underscore is allowed as
-a name space delimiters; see below. The first character must be a
-letter. Clients MUST use case-insensitive matching.
+The file contains keywords and optioanlly values, one per line with
+each line terminated by a LF or the sequence of CR and LF. Empty lines
+and lines starting with a '#' character are considered comment
+lines. A keyword is made up of lowercase letters, digits, hyphens, or
+dots. An underscore is allowed as a name space delimiters; see
+below. The first character must be a letter. Keywords which are
+defined to require a value are directly followed by a colon and then
+after optional white space the value. Clients MUST use
+case-insensitive matching for the keyword.
Currently defined keywords are:
-- "mailbox-only" :: The mail server provider does only accept keys
- with only a mailbox in the User ID. In particular
+- mailbox-only :: The mail server provider does only accept keys
+ with only a mailbox in the User ID. In particular
User IDs with a real name in addition to the
mailbox will be rejected as invalid.
-- "dane-only" :: The mail server provider does not run a Web Key
- Directory but only an OpenPGP DANE service. The Web
+- dane-only :: The mail server provider does not run a Web Key
+ Directory but only an OpenPGP DANE service. The Web
Key Directory Update protocol is used to update the
keys for the DANE service.
-More keywords will be defined in updates to this I-D. There is no
-registry yet except for this document. For experimental use of new
+- auth-submit :: The submission of the mail to the server is done
+ using an authenticated connection. Thus the
+ submitted key will be published immediately without
+ any confirmation request.
+
+- protocol-version :: This keyword can be used to explicitly claim the
+ support of a specific version of the Web Key Service protocol.
+ This is in general not needed but implementations may have
+ workarounds for providers which only support an old protocol
+ version. If these providers update to a newer version they
+ should add this keyword so that the implementation can disable
+ the workaround. The value is an integer corresponding to the
+ respective draft revision number.
+
+# Fixme: Add a protocol-version value for the final RFC.
+
+
+More keywords will be defined in updates to this I-D. There is no
+registry except for this document. For experimental use of new
features or for provider specific settings, keywords MUST be prefixed
with a domain name and an underscore.
* Security Considerations
-The use of SHA-1 for the mapping of the "local-part" to a fixed string
+The use of SHA-1 for the mapping of the local-part to a fixed string
is not a security feature but merely used to map the local-part to a
-fixed-sized string made from a well defined set of characters. It is not
+fixed-sized string made from a well defined set of characters. It is not
intended to conceal information about a mail address.
The domain name part of the mail address is not part of the hash to
-avoid problems with internationalized domain names. Instead a separate
-web service is required for each domain name.
+avoid problems with internationalized domain names. Instead a
+separate URL is required for each domain name.
+
+The use of DNS SRV records reduces the certainty that a mail address
+belongs to a domain. For example an attacker may change the target to
+a host in a sub-domain under their control and thus gain full control
+over all keys. An implementation may want to weight the certainty of
+a mapping different if it has been retrieved via a sub-domain and in
+particular if a non-recommended name is used for the sub-domain.
+
* IANA Considerations
** Well-Known URI
IANA is requested to assign a well-known URI in the "Well-Known URIs"
registry as defined by {{{RFC(5785)}}}:
URI suffix: openpgpkey
Change controller: IETF
Specification document: This
* Acknowledgments
The author would like to acknowledge the help of the individuals who
kindly voiced their opinions on the GnuPG mailing lists, in particular,
the help of Bernhard Reiter and Guilhem Moulin.
* Back
-* Test Vectors
+* Sample Protocol Run
-For help implementing this specification a non-normative example is
-given:
+The following non-normative example can be used by implementors as
+guidance.
-** Sample key
+Note that GnuPG version 2.1.12 supports the key discovery described in
+version -00 of this document (auto-key-locate method "wkd"). Version
+2.1.16 can run the protocol decribed in this document but is also able
+to run the protocol version specified by -01.
-TODO
+** Sample Keys
-** Software Notes
+This is the provider's submission key:
+#+begin_example
+-----BEGIN PGP PRIVATE KEY BLOCK-----
+
+lFgEV/TAohYJKwYBBAHaRw8BAQdAB/k9YQfSTI8qQqqK1KimH/BsvzsowWItSQPT
+FP+fOC4AAP46uJ3Snno3Vy+kORye3rf0VvWvuz82voEQLxG6WpfHhREEtBprZXkt
+c3VibWlzc2lvbkBleGFtcGxlLm5ldIh5BBMWCAAhBQJX9MCiAhsDBQsJCAcCBhUI
+CQoLAgQWAgMBAh4BAheAAAoJEKhtNooW0cqEWMUA/0e9XaeptszWC9ZvPg8INL6a
+BvRqPBYGU7PGmuXsxBovAQDyckOykG0UAfHVyN1w4gSK/biMcnqVr857i8/HuvjW
+C5xdBFf0wKISCisGAQQBl1UBBQEBB0Apvaoe4MtSEJ1fpds/4DFl2kXXBpnVji/s
+Wg9btdthNQMBCAcAAP9FJX99T1LEJzBnvBBnc6bimnT6/1OKM9RdO4R0/uVP6BFL
+iGEEGBYIAAkFAlf0wKICGwwACgkQqG02ihbRyoTlGwD9FBr92osjL7HkhhZZ7Z2D
+My3b9zpoZeMjvPg5YPqpdKMA/jhZoHuZCRMBYf7YRFb8aXtuyetDFZYrkjnum+OG
+HFAD
+=Hnwd
+-----END PGP PRIVATE KEY BLOCK-----
+#+end_example
+
+This is the target key to be published:
+#+begin_example
+-----BEGIN PGP PRIVATE KEY BLOCK-----
+
+lFgEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
+nTEoBRkAAP94nCZMM4WY2IORXfM6phLGSz3RsHvs/vA1Opaus4+R3BKJtBtwYXRy
+aWNlLmx1bXVtYmFAZXhhbXBsZS5uZXSIeQQTFggAIQUCV2o9XQIbAwULCQgHAgYV
+CAkKCwIEFgIDAQIeAQIXgAAKCRATlWNoKgINCpkNAQDFDcwJUzsxu7aJUiPdpYXj
+4uVarrXakxEE8mGFotWhLAD9GH4rqLDYIE3NKEU0s+Okt4tEIwJaV8H1NNPPPMiK
+3g2cXQRXaj2NEgorBgEEAZdVAQUBAQdAFnnmZc99TuKk5iCq9wmYZUVF2RcXN2Cs
+qAl8iGQQUWsDAQgHAAD/VN/VGmlcwGBPcLTya2hfU4t37nMcFCKdNSXjJ5DFA0AP
+PohhBBgWCAAJBQJXaj2NAhsMAAoJEBOVY2gqAg0Ky4UA/0GmVaXzXemLvv1Xw4yx
+Eaz/KfKKGc4RJ+38fyqUzw8NAQCohQ+ki3I5f84EXLZEiUiLsnVtOn1HNxvND/gW
+TiFZBA==
+=GHi7
+-----END PGP PRIVATE KEY BLOCK-----
+#+end_example
-GnuPG supports the key discovery described in version -00 of this
-document since version 2.1.12, 2.1.13 and the gurrent git version will
-be adjusted to the changes specs dfescribed in -01. To use it, the
-new method "wkd" needs to be used with the =--auto-key-locate= option.
+** Sample Messages
-* Changes since -00
+The first message triggeres the publication requests.
+#+begin_example
+From: patrice.lumumba@example.net
+To: key-submission@example.net
+Subject: Key publishing request
+MIME-Version: 1.0
+Content-Type: multipart/encrypted;
+ protocol="application/pgp-encrypted";
+ boundary="=-=01-e8k41e11ob31eefa36wo=-="
+Date: Wed, 05 Oct 2016 10:15:51 +0000
+
+
+--=-=01-e8k41e11ob31eefa36wo=-=
+Content-Type: application/pgp-encrypted
+
+Version: 1
+
+--=-=01-e8k41e11ob31eefa36wo=-=
+Content-Type: application/octet-stream
+
+-----BEGIN PGP MESSAGE-----
+
+hF4DUgLY5tvmW2sSAQdAR1AcqvFpQe/fHRZbf0xcnl9Tb+AtwaX2yZnZXGELGHsw
+1/e3E0JptwM5tpRAVe71ooF8Zq4jl76ZgQKfj/SyjpLJxyoEDy2N5wTQaqW4JtML
+0ukB1vh7dIRDxBJX/LQIJC0wz8o1Q3vjcLJKFFvDb7YrerABpPIzwOAupcgIbQHj
+5m1+2WU5CL8ffyJy2h1jV2X4OnvWF1Sn6J6SVD6DfZpOPRt9TxSemJrN1LJ3lG0N
+ts8AuYmCOeC1H2r5TYyxqkC98JF8+Nvyxd/fwne8IOjK9uixkNMC5H9/ZOH0YWCb
+wBnNB4iXuym4OIPxiLkDymsVF0ww/XrODE9Y259EGmO45VFNrJAX3HFs9/PcMCVk
+n2qMyEkr8LHiXeEPun6Z54RHUPYv2cUkEZ0hhSJ+rtBxkc/5D/cAScCEXRKFSKEF
+jLJAvLK/u/ga5DAzVai+vh6b6Bq+YVPaD9GWMhWj4CgR90p9LULi6S/Hzwhv9Wzf
+8fJoJOaDjyvRDgr09jYLWamxkS9NWxqwy6MXJvxwbNdd5XtqiW4Y4o0Ll1hDJhxR
+ljn/XvotXKwhKN+4QGhIXDVt4Dl4XxS5ptWfVTau8W8DYqDsU2obEcfsirZv53M1
+Q9FCD8CD9+dkBt8VAJekCWVhEltcRHxlrznbk2jxm93xSD2o6gZ5X0VSaSUXyEhm
+J+8F3gyTHGgbq/TgyjFoockWh5EtGgAFuWvmPJCF5PO/UaNeoKwgwSJBu6oTXkHx
+R4nvvMRcj5UgTsKpZ79NiDQukbjG5ScNT5TCUiiZsBXBqBx3fD61EH6cAuh4P3Kr
+iM7PY4fwAHo890Dx+Qlt
+=WIhx
+-----END PGP MESSAGE-----
+
+--=-=01-e8k41e11ob31eefa36wo=-=--
+#+end_example
+
+The server decrypts this message to
+#+begin_example
+Content-Type: application/pgp-keys
+
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+
+mDMEV2o9XRYJKwYBBAHaRw8BAQdAZ8zkuQDL9x7rcvvoo6s3iEF1j88Dknd9nZhL
+nTEoBRm0G3BhdHJpY2UubHVtdW1iYUBleGFtcGxlLm5ldIh5BBMWCAAhBQJXaj1d
+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEBOVY2gqAg0KmQ0BAMUNzAlT
+OzG7tolSI92lhePi5VqutdqTEQTyYYWi1aEsAP0YfiuosNggTc0oRTSz46S3i0Qj
+AlpXwfU00888yIreDbg4BFdqPY0SCisGAQQBl1UBBQEBB0AWeeZlz31O4qTmIKr3
+CZhlRUXZFxc3YKyoCXyIZBBRawMBCAeIYQQYFggACQUCV2o9jQIbDAAKCRATlWNo
+KgINCsuFAP9BplWl813pi779V8OMsRGs/ynyihnOESft/H8qlM8PDQEAqIUPpIty
+OX/OBFy2RIlIi7J1bTp9RzcbzQ/4Fk4hWQQ=
+=qRfF
+-----END PGP PUBLIC KEY BLOCK-----
+#+end_example
+
+and returns this confirmation request
+#+begin_example
+From: key-submission@example.net
+To: patrice.lumumba@example.net
+Subject: Confirm your key publication
+MIME-Version: 1.0
+Content-Type: multipart/encrypted;
+ protocol="application/pgp-encrypted";
+ boundary="=-=01-wrzqued738dfx4x97u7y=-="
+Date: Wed, 05 Oct 2016 10:16:57 +0000
+
+
+--=-=01-wrzqued738dfx4x97u7y=-=
+Content-Type: application/pgp-encrypted
+
+Version: 1
+
+--=-=01-wrzqued738dfx4x97u7y=-=
+Content-Type: application/octet-stream
+
+-----BEGIN PGP MESSAGE-----
+
+hF4DkYWHjk/NdMASAQdAluQeqhECpU2T0zEyBAEbFzhLkpubN160wjkFCrtUc0Mw
+FwYgM2fp9cvTMdJ/xjkvmAcIEOT4AY/hn1yFQ4z0KG0gCkSac+8mkDylnPdxlXYw
+0sBSAXlbqpVA7eUpFuU2Zs10zbIXxlwe6osR5wUIJut/RCOsYQmfvxC55x8mUX5/
+zgTnNzlMzye5ws4pTgAeQm2x0Yv018L8IZgY5KxwJLBzlss0wLZ45ZcS80hR11Fx
+NCow1fKF8lMnOJxagTEOih807nctz8vT5bR1gx0d7N3LM+th8nAg9/6Ghf1XTpLo
+MzwGW0FtOG7Dg1Uxbw2bjaOuRBeh6IIpmNAw1pmIfnNu7PpoRydU5w1K/R8MT06z
+MKdJ7IW5mVGes9EGnG3e4mjuILvNaZhfYy+a73IhDSaPm3oqdl1Qx7tbNg6lGjn6
+KStCYAcPGPp3m7aWkfsPGThOVRhEXqaFFywfwSVEj1pdIRjDFA==
+=Cdjh
+-----END PGP MESSAGE-----
+
+--=-=01-wrzqued738dfx4x97u7y=-=--
+#+end_example
+
+The client decrypts the attachment as
+#+begin_example
+Content-Type: application/vnd.gnupg.wks
+Content-Transfer-Encoding: 8bit
+
+type: confirmation-request
+sender: key-submission@example.net
+address: patrice.lumumba@example.net
+fingerprint: B21DEAB4F875FB3DA42F1D1D139563682A020D0A
+nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
+#+end_example
+
+creates this response
+#+begin_example
+Content-Type: application/vnd.gnupg.wks
+Content-Transfer-Encoding: 8bit
+
+type: confirmation-response
+sender: key-submission@example.net
+address: patrice.lumumba@example.net
+nonce: f5pscz57zj6fk11wekk8gx4cmrb659a7
+#+end_example
+
+and sends it encrypted to the server
+#+begin_example
+From: patrice.lumumba@example.net
+To: key-submission@example.net
+Subject: Key publication confirmation
+MIME-Version: 1.0
+Content-Type: multipart/encrypted;
+ protocol="application/pgp-encrypted";
+ boundary="=-=01-iacqg4og4pqz11a5cg1o=-="
+Date: Wed, 05 Oct 2016 10:18:52 +0000
+
+
+--=-=01-iacqg4og4pqz11a5cg1o=-=
+Content-Type: application/pgp-encrypted
+
+Version: 1
+
+--=-=01-iacqg4og4pqz11a5cg1o=-=
+Content-Type: application/octet-stream
+
+-----BEGIN PGP MESSAGE-----
+
+hF4DUgLY5tvmW2sSAQdAnB1C3PMjS4AsGU0qaCqBdWQO5i6blWEyZrEsY+JZY1Qw
+ooNq7zdVWOHhL9LPGAALAgoL3Qfz+dN2u5QamSQ/LJ2c8M0XipNs3lqlNH63yQN1
+0sAmAc3W8xkwul+rf6OLK/gMi6WzM4fnUhd4D1LJGIJoNUN0l3636C7ecOt2lkMl
+5bVAYg/SyMT3ymyfQnvtiem2T5DSnPsS1g6n6QNXWvkqvX9yGxNsNDJEHTuGJB8k
+OJoRlfWQTEo6pgA89febWl1EdeM1pPLstQ2uZE8NPjXoY1nMxAlu+iPYsR41/4sg
+dqwOv5BPLh/GIat8hh9SPWCA9iKlgSQ/EIv5DpjQogEzpriT55dkgfvSVYIAcOdO
+ShZ91YKkcZffevdY72omqTk10a1SUXehPooIlRFmroDsi3VDaRKrUIo=
+=7uve
+-----END PGP MESSAGE-----
+
+--=-=01-iacqg4og4pqz11a5cg1o=-=--
+#+end_example
-- Dropped the second occurrence of the domain name from the URL.
-- Changed field names in the request and response format.
-- Removed useless checks.
-- Added a new policy flag.
-** TODO
+* Changes Since -03
-- What about authenticated submission?
-- Describe how to handle a key with several User IDs.
+- Fixed Content-Type in the description. The one used in the example
+ was correct.
diff --git a/misc/jenkins/README.org b/misc/jenkins/README.org
new file mode 100644
index 0000000..e484893
--- /dev/null
+++ b/misc/jenkins/README.org
@@ -0,0 +1,216 @@
+* Notes
+** Overview
+|----------------------+--------+---------+-----------+-----+-----------|
+| Configuration Matrix | native | in-tree | sanitizer | w32 | distcheck |
+|----------------------+--------+---------+-----------+-----+-----------|
+| arch | x | | | | |
+| debian | x | | | | |
+| macos | x | | | | |
+| master | | x | x | x | x |
+| openbsd60 | x | | | | |
+|----------------------+--------+---------+-----------+-----+-----------|
+
+There are two dimensions, build host ("label") and build profile
+("XTARGET"). The build hosts are described below. The "debian" label
+is the same configuration as "master".
+
+bin/build.bash is the build script. It creates a suitable build
+environment, builds, tests, and installs all our packages. The
+different build profiles are implemented there.
+*** Build profiles
+**** native
+A straight forward out-of-tree build.
+**** in-tree
+A straight forward in-tree build.
+**** sanitizer
+A build with -fsanitize=undefined -fsanitize=address. This catches
+many memory errors by instrumenting the code and running the test
+suites.
+**** w32
+Cross-compile the package for Windows, run the tests using a virtual
+machine.
+**** distcheck
+Executes 'make distcheck'. Makes sure that we can always create
+releases.
+** Setting up a Jenkins build slave
+ - on soro, create an entry in /etc/hosts
+ - copy root@soro's ssh key to /root/.ssh/authorized_keys
+ - install a jre, make, autoconf, automake, libtool, gcc, git, bison,
+ fig2dev, ghostscript, gnutls, sqlite3, pkg-config, imagemagick,
+ rngd, python2/3, SWIG, Qt5 base, ccache
+ - setup rngd (test suites will consume quite a bit of entropy)
+ - create a user jenkins
+ - clone gnupg-doc
+ $ git clone git://git.gnupg.org/gnupg-doc.git
+ - link ~/bin
+ $ ln -s gnupg-doc/misc/jenkins/bin
+ - download slave.jar
+ $ wget https://jenkins.gnupg.org/jnlpJars/slave.jar -O bin/slave.jar
+ Note:
+ The jar should be updated from time to time, but the documentation
+ says that the protocol changes rarely.
+ - copy and adapt launcher
+ $ cp bin/jenkins-slave.dist bin/jenkins-slave
+ - make sure that jenkins@soro can ssh to the new node
+ - go to https://jenkins.gnupg.org/computer/new and copy an existing
+ configuration, adapting it as needed
+ - setup 'GPGME tests for GnuPG' as described below
+ - for each project, add the new nodes distinct label to the
+ configuration matrix, and force a rebuild. Start with libgpg-error
+ and walk your way up the dependency chain:
+ - libgpg-error, libnpth, libassuan, libksba, libgcrypt, ntbtls,
+ gnupg, gpgme
+** GPGME tests for GnuPG
+There is a reasonably up-to-date (but this is currently a manual
+process) GPGME source at
+
+ $ mkdir $HOME/src
+ $ git clone git://git.gnupg.org/gpgme.git $HOME/src/gpgme-for-gnupgs-tests
+ $ cd $HOME/src/gpgme-for-gnupgs-tests
+ $ ./autogen.sh
+
+and a build tree at
+
+ $ mkdir $HOME/src/gpgme-for-gnupgs-tests/obj
+ $ cd $HOME/src/gpgme-for-gnupgs-tests/obj
+ $ export PATH=$HOME/prefix/native/bin:$PATH
+ $ ../configure --enable-maintainer-mode
+ $ make
+ $ make check
+
+and specialized build trees, e.g. for the sanitizer target at
+
+ $ mkdir $HOME/src/gpgme-for-gnupgs-tests/obj-sanitizer
+ $ cd $HOME/src/gpgme-for-gnupgs-tests/obj-sanitizer
+ $ export PATH=$HOME/prefix/sanitizer/bin:$PATH
+ $ ../configure --enable-maintainer-mode \
+ --enable-languages="cpp qt" \
+ CFLAGS="-fsanitize=undefined -fsanitize=address" \
+ CXXFLAGS="-fsanitize=undefined -fsanitize=address"
+ $ make
+ $ make check
+
+
+and a w32 build tree at
+
+ $HOME/src/gpgme-for-gnupgs-tests/obj.w32
+
+The tests from there are executed in GnuPG's test suite.
+* Build hosts
+** zygalski
+Werner manages this box.
+** Virtual machines
+*** openbsd60
+Packages installed:
+
+ # pkg_add zile zsh git autoconf-2.69p2 automake-1.15p0 gettext-tools \
+ gmake xfig bison readline libusb-compat ImageMagick makeinfo \
+ gcc-4.9.3p9 g++-4.9.3p9 qt5 python swig ccache
+
+Add some compatibility links to PATH:
+
+ $ mkdir -p ~/compat/{bin,lib,include}
+ $ cd ~/compat/bin
+ $ ln -s /usr/local/bin/gmakeinfo makeinfo
+ $ [ add $HOME/compat/bin to ~/.profile ]
+ $ cd ~/compat/lib
+ $ for F in /usr/local/lib/libbz2* /usr/local/lib/libiconv* /usr/local/lib/libintl* ; do ln -s $F ; done
+ $ cd ~/compat/include
+ $ for F in /usr/local/include/*bz*h /usr/local/include/*iconv*h /usr/local/include/*intl*h ; do ln -s $F ; done
+
+Tweak limits:
+
+ # echo 'jenkins:\
+ :maxproc-max=1024:\
+ :maxproc-cur=1024:\
+ :tc=pbuild:
+' >> /etc/login.conf
+ # user mod -L jenkins jenkins
+*** win8.1
+Configuration: One user "gpg", disabled Windows update (cpu hog),
+disable animations ("make computer easier to see again").
+
+Installed applications: https://github.com/PowerShell/Win32-OpenSSH/releases/latest
+**** How tests are executed
+To run the test suite, the machine is reverted to the snapshot
+'tests', and the tests are executed in-place from an ISO image.
+
+See:
+ - bin/run-tests-w32.bash
+ - bin/run-tests.bat
+ - bin/make-windows-cd.sh
+**** Win32-OpenSSH
+The implementation seems a bit brittle at the moment. Often, the ssh
+server will stop responding to requests, I do not know why.
+
+To update the ssh server, follow
+https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH
+first uninstall the old one, then install the new one.
+
+**** Updating & maintenance
+Get a lock on bin/run-tests-w32.bash to avoid it stomping over your
+changes:
+
+ jenkins@soro:~$ flock /var/lib/jenkins/bin/run-tests-w32.bash bash
+
+Start the machine using
+
+ jenkins@soro:~$ virsh -c qemu:///system snapshot-revert --snapshotname tests --force --running win8.1
+
+Connect to the machine from your desktop machine:
+
+ you@home $ virt-viewer -c qemu+ssh://jenkins@soro.g10code.com/system win8.1
+
+Do whatever maintenance work is necessary.
+
+Hints:
+ - Start a powershell:
+ Open the file explorer, enter 'powershell' into the location bar (ctrl-l).
+ - Right mouse button pastes in powershell.
+ - Elevate privileges in powershell:
+ > Start-Process powershell -verb runAs
+
+Shutdown the machine. Create a new snapshot 'test-new':
+
+ jenkins@soro:~$ virsh -c qemu:///system snapshot-create-as win8.1 --name "tests-new" --description "Updated OpenSSH to xxx"
+
+Archive the current snapshot:
+
+ jenkins@soro:~$ virsh -c qemu:///system snapshot-edit win8.1 --snapshotname "tests" --rename
+ [... editor pops open, change "tests "
+ to "tests YYY-MM-DD ", save, exit ...]
+
+Note: The snapshots creation times can be found using:
+
+ jenkins@soro:~$ virsh -c qemu:///system snapshot-list win8.1 | grep tests
+ tests 2017-03-15 14:21:17 +0100 shutoff
+ tests 2017-01-31 2017-01-31 11:05:17 +0100 shutoff
+
+Rename the new snapshot:
+
+ jenkins@soro:~$ virsh -c qemu:///system snapshot-edit win8.1 --snapshotname "tests-new" --rename
+ [... editor pops open, change "tests-new "
+ to "tests ", save, exit ...]
+
+Exit the shell to release the lock:
+
+ jenkins@soro:~$ exit
+ exit
+
+Voila.
+**** Ideas
+ - Build the installer, put it on the ISO image, and test that as well.
+*** openindiana20161030
+So I wanted the most alien UNIX I could get my hands on. I never
+configured the build environment though, so this machine lies dormant.
+**** Packages installed
+pkg install pkg://openindiana.org/runtime/java/openjdk8 top git autoconf automake libtool bison readline
+*** archlinux
+**** Packages installed
+pacman --sync zile bind-tools openssh zsh jre8-openjdk-headless git autoconf automake libtool make wget gcc bison fig2dev ghostscript gnutls sqlite3 pkg-config imagemagick librsvg rng-tools python swig qt5-base
+**** Upgrading packages
+Note: Some breakage can happen when upgrading the system. Arch users
+deal with that by reading the website and following instructions
+there.
+
+pacman -Syu
diff --git a/misc/jenkins/bin/build.bash b/misc/jenkins/bin/build.bash
new file mode 100755
index 0000000..2737c08
--- /dev/null
+++ b/misc/jenkins/bin/build.bash
@@ -0,0 +1,391 @@
+#!/usr/bin/env bash
+# Script used jenkins to run builds for GnuPG and related packages.
+
+# Stop on error and be nice to other processes.
+set -xe
+renice -n 10 -p $$
+
+# Configuration.
+MAKE=make
+NPROCS=2
+
+XTARGET="${XTARGET:-native}"
+
+# Platform-specific configuration.
+case "$(uname)" in
+ OpenBSD)
+ MAKE=gmake
+ ;;
+ Darwin)
+ NPROCS="$(sysctl -n hw.ncpu)"
+ ;;
+esac
+
+if [ "$XTARGET" = w32 ]; then
+ CC=i686-w64-mingw32-gcc
+ CXX=i686-w64-mingw32-g++
+fi
+
+# Setup ccache if installed.
+if ccache --version >/dev/null; then
+ export CCACHE_DIR="$HOME/cache/$JOB_NAME"
+ mkdir -p "$CCACHE_DIR"
+ export CC="ccache ${CC:-gcc}"
+ export CXX="ccache ${CXX:-g++}"
+fi
+
+# Include local bin directory in PATH.
+if [ -e "$HOME/bin" ]; then
+ export PATH="$HOME/bin:$PATH"
+fi
+
+# Setup important envars
+PREFIX=$HOME/prefix/$XTARGET
+ORIGINAL_PREFIX=$HOME/prefix/$XTARGET
+
+# hackhackhack
+#
+# Copy all *-config scripts into a separate directory and put that
+# into PATH. We want configure to pick them up, but we do not
+# necessarily want to use all the other tools from $PREFIX/bin,
+# because then we would have to point LD_LIBRARY_PATH to $PREFIX/lib,
+# which we want to avoid at all costs.
+mkdir -p $PREFIX/bin-config
+cp $PREFIX/bin/*-config $PREFIX/bin-config
+export PATH=$PREFIX/bin-config:$PATH
+# kcahkcahkcah
+
+# Tweak the prefix we're installing this project into. For gnupg-1.4
+# and friends.
+case "$JOB_NAME" in
+ *-1.4*)
+ PREFIX=$PREFIX-1.4
+ ;;
+ *-2.0*)
+ PREFIX=$PREFIX-2.0
+ ;;
+ *-2.2*)
+ PREFIX=$PREFIX-2.2
+ ;;
+esac
+mkdir -p $PREFIX
+
+
+fix_permissions()
+{
+ find $1 -type d -exec chmod +w {} + || true
+}
+
+fix_permissions .
+
+# Clean everything
+git clean -fdx
+
+# Run out autogen - note that --force is not required due to the git clean.
+./autogen.sh
+
+# Parallel jobs.
+MAKEFLAGS="-j$NPROCS"
+
+SCANBUILD=
+if [ "$(uname)" = Linux ] \
+ && [ "$ROOT_BUILD_CAUSE_TIMERTRIGGER" = true ]; then
+ # We only do scan-builds (which are really slow) on nightly
+ # builds.
+ SCANBUILD="scan-build -o ${WORKSPACE}/clangScanBuildReports -v"
+fi
+CONFIGUREFLAGS=
+SANFLAGS=""
+if [ "$(uname)" = Linux ]; then
+ # XXX: We should check if the sanitizers are available.
+ SANFLAGS="-fsanitize=undefined -fsanitize=address"
+fi
+
+if [ "$(uname)" = Darwin ]; then
+ # XXX until we properly set this somewhere else
+ cversion="_DARWIN_C_SOURCE=900000L"
+ CFLAGS="$CFLAGS -D$cversion"
+ CXXFLAGS="$CXXFLAGS -D$cversion"
+fi
+
+# Tweak the build depending on the package.
+case "$JOB_NAME" in
+ *tgpg*)
+ MAKEFLAGS="$MAKEFLAGS GPG=/usr/bin/gpg2"
+ ;;
+ *gpgme*)
+ # using libasan for python broke again, so disable the python
+ # bindings for the sanitizer build
+ if [ "$XTARGET" = sanitizer ]; then
+ CONFIGUREFLAGS_0="--enable-languages=cpp qt"
+ fi
+
+ # Disable Python bindings on macOS. Something is not working
+ # there.
+ if [ "$NODE_NAME" = zygalski ]; then
+ CONFIGUREFLAGS_0="--enable-languages=cpp qt"
+ fi
+ ;;
+ *gnupg*)
+ # Common configure options.
+ CONFIGUREFLAGS="--enable-wks-tools --enable-gpg2-is-gpg"
+
+ # For Windows builds...
+ if [ "$XTARGET" = w32 ]; then
+ # ... we need to tweak it a little and we leave out some
+ # stuff...
+ CONFIGUREFLAGS="$CONFIGUREFLAGS --with-zlib=$ORIGINAL_PREFIX --with-bzip2=$ORIGINAL_PREFIX"
+ else
+ # ... that we enable for all other builds.
+ CONFIGUREFLAGS="$CONFIGUREFLAGS --enable-g13 --enable-symcryptrun"
+ fi
+
+ if [ "$NODE_NAME" = zygalski ]; then
+ CONFIGUREFLAGS="$CONFIGUREFLAGS --with-libiconv-prefix=$HOME/pkg"
+ fi
+ if [ "$NODE_NAME" = openbsd60 ]; then
+ CONFIGUREFLAGS="$CONFIGUREFLAGS --with-libiconv-prefix=$HOME/compat --with-bzip2=$HOME/compat"
+ fi
+
+ # Disable NTBTLS for now until it is actually mature and used.
+ CONFIGUREFLAGS="$CONFIGUREFLAGS --disable-ntbtls"
+
+ # Parallel tests with our test suite.
+ export TESTFLAGS="--parallel=$NPROCS"
+ ;;
+esac
+
+# See if we have a GPGME checkout for the tesets.
+xtest_gpgme_srcdir="$HOME/src/gpgme-for-gnupgs-tests"
+if [ -d "$xtest_gpgme_srcdir/obj-$XTARGET" ]; then
+ # Some targets, like the sanitizer target, require a custom
+ # version of GPGME.
+ export XTEST_GPGME_SRCDIR="$xtest_gpgme_srcdir"
+ export XTEST_GPGME_BUILDDIR="$xtest_gpgme_srcdir/obj-$XTARGET"
+elif [ -d "$xtest_gpgme_srcdir/obj" ]; then
+ export XTEST_GPGME_SRCDIR="$xtest_gpgme_srcdir"
+ export XTEST_GPGME_BUILDDIR="$xtest_gpgme_srcdir/obj"
+fi
+
+# The libraries use RUNPATH when linking the tests, so they locate
+# their dependencies that way. GnuPG, however, does not. Therefore,
+# we set LD_LIBRARY_PATH.
+test_environment="LD_LIBRARY_PATH=$ORIGINAL_PREFIX/lib"
+
+# HACKHACKHACK:
+#
+# Because newer Debian toolchains prefer RUNPATH over RPATH, and
+# RUNPATH has lower precedence than LD_LIBRARY_PATH, we need to
+# explicitly add libtool's .libs directory:
+case "$JOB_NAME" in
+ *gnupg*)
+ if [ "${XTEST_GPGME_BUILDDIR}" ]; then
+ test_environment="LD_LIBRARY_PATH=${XTEST_GPGME_BUILDDIR}/src/.libs:${XTEST_GPGME_BUILDDIR}/lang/cpp/src/.libs:${XTEST_GPGME_BUILDDIR}/lang/qt/src/.libs:$ORIGINAL_PREFIX/lib"
+ fi
+ ;;
+ *gpgme*)
+ test_environment="LD_LIBRARY_PATH=$(pwd)/obj/src/.libs:$(pwd)/obj/lang/cpp/src/.libs:$(pwd)/obj/lang/qt/src/.libs:$ORIGINAL_PREFIX/lib"
+ ;;
+ *)
+ test_environment="LD_LIBRARY_PATH=$(pwd)/obj/src/.libs:$ORIGINAL_PREFIX/lib"
+ ;;
+esac
+#
+# If we don't do this, the version tests fail because the runtime
+# linker will pick up the library from LD_LIBRARY_PATH. Also, testing
+# the installed version is not what we want ofc.
+#
+# KCAHKCAHKCAH
+
+# And add $PREFIX/bin to PATH for the tests.
+test_environment="$test_environment PATH=$ORIGINAL_PREFIX/bin:$PATH"
+
+# We build on the "obj" subdir.
+abs_configure="$(pwd)/configure"
+mkdir -p obj
+cd obj
+
+
+# Print the environment.
+env
+ulimit -a
+set +x
+for f in /etc/gcrypt/hwf.deny /etc/gcrypt/fips_enabled ; do
+ if [ -f "$f" ]; then
+ echo "=== $f ==="
+ cat -n "$f"
+ fi
+done
+set -x
+
+
+# Select the appropriate test target.
+function check_target() {
+ if grep >/dev/null check-all Makefile; then
+ echo check-all
+ else
+ echo check
+ fi
+}
+
+# Switch on the different targets.
+case "$XTARGET" in
+ native)
+ ../configure --prefix=$PREFIX --enable-maintainer-mode \
+ $CONFIGUREFLAGS \
+ "$CONFIGUREFLAGS_0" \
+ CFLAGS="$CFLAGS" \
+ CXXFLAGS="$CXXFLAGS -std=c++11"
+ $MAKE $MAKEFLAGS
+
+ env $test_environment $MAKE -k $(check_target) verbose=2 \
+ || echo "FAIL: make check failed with status $?"
+ # Jenkins looks for "FAIL:" to mark a build unstable,
+ # hence || ... here
+
+ $MAKE install
+ ;;
+ in-tree)
+ cd ..
+ ./configure --prefix=$PREFIX --enable-maintainer-mode \
+ $CONFIGUREFLAGS \
+ "$CONFIGUREFLAGS_0" \
+ CFLAGS="$CFLAGS" \
+ CXXFLAGS="$CXXFLAGS -std=c++11"
+ $MAKE $MAKEFLAGS
+
+ # HACKHACKHACK: Fix the test_environment hack.
+ test_environment="$(echo $test_environment | sed -e 's#obj/##g')"
+ # KCAHKCAHKCAH
+
+ env $test_environment $MAKE -k $(check_target) verbose=2 \
+ || echo "FAIL: make check failed with status $?"
+ # Jenkins looks for "FAIL:" to mark a build unstable,
+ # hence || ... here
+
+ $MAKE install
+ ;;
+ sanitizer)
+ # asan breaks the configure tests, so we disable it here.
+ ASAN_OPTIONS=detect_leaks=0 \
+ $SCANBUILD \
+ ../configure --prefix=$PREFIX --enable-maintainer-mode \
+ $CONFIGUREFLAGS \
+ "$CONFIGUREFLAGS_0" \
+ CFLAGS="$CFLAGS $SANFLAGS -fPIC" \
+ CXXFLAGS="$CXXFLAGS $SANFLAGS -fPIC -std=c++11"
+ $SCANBUILD $MAKE $MAKEFLAGS
+
+ env $test_environment $MAKE -k $(check_target) verbose=2 \
+ || echo "FAIL: make check failed with status $?"
+ # Jenkins looks for "FAIL:" to mark a build unstable,
+ # hence || ... here
+
+ $MAKE install
+ ;;
+ w32)
+ export w32root=$PREFIX
+
+ # autogen.rc adds --with-gpg-error-prefix=@SYSROOT@, so we cannot
+ # install to a prefix that doesn't also contain all the dependencies,
+ # patch that out, so that the gpg-error-config and friends are located
+ # using PATH
+ if [ -f "/home/jenkins/bin/$(dirname $JOB_NAME)-w32.patch" ]; then
+ ( cd .. && patch -p1 <"/home/jenkins/bin/$(dirname $JOB_NAME)-w32.patch" )
+ fi
+ # We need to point it to npth then...
+ case "$JOB_NAME" in
+ gnupg/XTARGET=w32|gnupg-2.2/XTARGET=w32)
+ CONFIGUREFLAGS="${CONFIGUREFLAGS} --with-npth-prefix=$ORIGINAL_PREFIX"
+ ;;
+ gnupg-2.0/XTARGET=w32)
+ CONFIGUREFLAGS="${CONFIGUREFLAGS} --with-pth-prefix=$ORIGINAL_PREFIX --with-adns=$ORIGINAL_PREFIX"
+ ;;
+ esac
+
+ # gpg1's autogen.sh does not add --enable-maintainer-mode, so
+ # version.texi is not generated. we add it here to be sure.
+ # likewise for --prefix
+ ../autogen.sh --build-w32 --enable-maintainer-mode --prefix=$PREFIX \
+ $CONFIGUREFLAGS
+ $MAKE $MAKEFLAGS
+ $MAKE install
+
+ case "$JOB_NAME" in
+ gnupg/*|gnupg-2.2/*)
+ bash /home/jenkins/bin/make-windows-cd.sh
+ # We need to pass the absolute path of the iso.
+ bash $HOME/bin/run-tests-w32.bash "$(readlink -f gnupg-test.iso)" || echo "Warning: error running tests on Windows."
+ ;;
+ esac
+ ;;
+ distcheck)
+ CONFIGUREFLAGS=
+ WORKDIR="$(mktemp -d)"
+ cleanup()
+ {
+ cd /tmp
+ fix_permissions "$WORKDIR"
+ rm -rf -- "$WORKDIR" || true
+ }
+ trap cleanup EXIT
+
+ # We use a different WORKDIR to avoid problems with too long
+ # file names
+ cd "$WORKDIR"
+ $abs_configure --prefix=$PREFIX --enable-maintainer-mode \
+ $CONFIGUREFLAGS
+
+ # Extract the directory / tarname from the package
+ tarname=$(awk &2
+ exit 0
+ fi
+ # And do a final build using the generated tarball
+ cd ${tarname}
+ ./configure --prefix=$PREFIX $CONFIGUREFLAGS
+ $MAKE $MAKEFLAGS
+ $MAKE $MAKEFLAGS install
+
+ ;;
+ *)
+ echo "Bad XTARGET: '$XTARGET'"
+ exit 2
+esac
diff --git a/misc/jenkins/bin/gnupg-2.0-w32.patch b/misc/jenkins/bin/gnupg-2.0-w32.patch
new file mode 100644
index 0000000..0cd6e59
--- /dev/null
+++ b/misc/jenkins/bin/gnupg-2.0-w32.patch
@@ -0,0 +1,21 @@
+diff --git a/autogen.sh b/autogen.sh
+index 605babfa9..1a9654f0d 100755
+--- a/autogen.sh
++++ b/autogen.sh
+@@ -87,15 +87,7 @@ if test "$1" = "--build-w32"; then
+ $tsdir/configure --enable-maintainer-mode --prefix=${w32root} \
+ --host=${host} --build=${build} \
+ --enable-gpgtar \
+- --with-gpg-error-prefix=${w32root} \
+- --with-ksba-prefix=${w32root} \
+- --with-libgcrypt-prefix=${w32root} \
+- --with-libassuan-prefix=${w32root} \
+- --with-zlib=${w32root} \
+- --with-regex=${w32root} \
+- --with-pth-prefix=${w32root} \
+- --with-libiconv-prefix=${w32root} \
+- --with-adns=${w32root} "$@"
++ "$@"
+ rc=$?
+ exit $rc
+ fi
diff --git a/misc/jenkins/bin/gnupg-2.2-w32.patch b/misc/jenkins/bin/gnupg-2.2-w32.patch
new file mode 120000
index 0000000..d829c6e
--- /dev/null
+++ b/misc/jenkins/bin/gnupg-2.2-w32.patch
@@ -0,0 +1 @@
+gnupg-w32.patch
\ No newline at end of file
diff --git a/misc/jenkins/bin/gnupg-w32.patch b/misc/jenkins/bin/gnupg-w32.patch
new file mode 100644
index 0000000..1927ceb
--- /dev/null
+++ b/misc/jenkins/bin/gnupg-w32.patch
@@ -0,0 +1,18 @@
+diff --git a/autogen.rc b/autogen.rc
+index 36948178f..4aa1993d8 100644
+--- a/autogen.rc
++++ b/autogen.rc
+@@ -15,13 +15,6 @@ esac
+ case "$myhost" in
+ w32)
+ configure_opts="
+- --with-gpg-error-prefix=@SYSROOT@
+- --with-ksba-prefix=@SYSROOT@
+- --with-libgcrypt-prefix=@SYSROOT@
+- --with-libassuan-prefix=@SYSROOT@
+- --with-zlib=@SYSROOT@
+- --with-regex=@SYSROOT@
+- --with-npth-prefix=@SYSROOT@
+ --disable-g13
+ "
+ ;;
diff --git a/misc/jenkins/bin/jenkins-slave.dist b/misc/jenkins/bin/jenkins-slave.dist
new file mode 100755
index 0000000..1d9afad
--- /dev/null
+++ b/misc/jenkins/bin/jenkins-slave.dist
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+set -x
+
+[ -f ~/.profile ] && . ~/.profile
+uname -a
+env
+
+exec java -jar ~/bin/slave.jar
diff --git a/misc/jenkins/bin/make-windows-cd.sh b/misc/jenkins/bin/make-windows-cd.sh
new file mode 100644
index 0000000..835f798
--- /dev/null
+++ b/misc/jenkins/bin/make-windows-cd.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+set -ex
+
+if ! [ -f config.log ] || ! grep -q mingw config.log; then
+ echo "must be run from a configured windows build environment"
+fi
+
+[ -z "$w32root" ] && w32root="$HOME/w32root"
+ADDITIONAL_FILES=
+IMAGE=gnupg-test.iso
+XTEST_GPGME_SRCDIR=$HOME/src/gpgme-for-gnupgs-tests
+XTEST_GPGME_BUILDDIR=$HOME/src/gpgme-for-gnupgs-tests/obj.w32
+
+[ -f make-windows-cd.rc ] && . make-windows-cd.rc
+
+# we pick binaries from the prefix, so make sure they are current.
+make install
+
+WORKDIR="$(mktemp --directory)"
+TARGET="${WORKDIR}/gnupg"
+
+mkdir "$TARGET"
+
+[ "$ADDITIONAL_FILES" ] && cp -v $(ls -1 $ADDITIONAL_FILES) $TARGET
+cp -v $w32root/bin/*.exe $w32root/bin/*.dll $TARGET
+cp -v tests/gpgscm/*.exe $TARGET
+# XXX mk-tdata is on the way out
+cp -v tools/mk-tdata.exe $TARGET || true
+cp -v agent/gpg-preset-passphrase.exe $TARGET
+cp -v -a ../tests $TARGET
+if [ -e "$XTEST_GPGME_SRCDIR" ] && [ -e "$XTEST_GPGME_BUILDDIR" ]; then
+ cp -a "$XTEST_GPGME_SRCDIR" $TARGET/gpgme
+ cp -v "$XTEST_GPGME_BUILDDIR"/src/.libs/*.exe $TARGET
+ cp -v "$XTEST_GPGME_BUILDDIR"/src/.libs/*.dll $TARGET
+ # Strip .git.
+ rm -rf -- $TARGET/gpgme/.git
+ # Remove native build if it exists.
+ rm -rf -- $TARGET/gpgme/obj
+fi
+cp -v -a ../tests $TARGET
+cp -v tests/openpgp/fake-pinentry.exe $TARGET
+cp -v /home/jenkins/bin/run-tests.bat $WORKDIR
+[ -f "$IMAGE" ] && rm -f "$IMAGE"
+genisoimage --output "$IMAGE" -J "$WORKDIR"
+[ "${WORKDIR}" ] && rm -rf -- "${WORKDIR}"
diff --git a/misc/jenkins/bin/run-tests-w32.bash b/misc/jenkins/bin/run-tests-w32.bash
new file mode 100755
index 0000000..43a8b38
--- /dev/null
+++ b/misc/jenkins/bin/run-tests-w32.bash
@@ -0,0 +1,70 @@
+#!/bin/bash
+
+# Locking.
+exec 9<"$0"
+echo -n "Aquiring lock on $0... "
+if ! flock --timeout 15 9 ; then
+ echo "failed!"
+ exit 1
+fi
+echo "ok."
+
+set -ex
+
+URI="qemu:///system"
+GUEST="win8.1"
+GUEST_CDROM="sda"
+SSH="gpg@192.168.122.117"
+SSH_COMMAND_TIMEOUT="60m"
+
+function vdo() {
+ virsh -c "$URI" "$@"
+}
+
+function vssh() {
+ # OpenSSH on Windows does not cope well with a closed stdin.
+ timeout /dev/null 2>&1 -oConnectTimeout=1 \
+ "$SSH" "echo pong" ; then
+ return 0
+ else
+ return 1
+ fi
+}
+
+function vwait() {
+ echo >&2 -n "Waiting for the machine to boot... "
+ while ! vping ; do echo >&2 -n . ; sleep 1 ; done
+}
+
+# Revert to current snapshot and start the machine.
+vdo snapshot-revert --snapshotname tests --force --running "$GUEST"
+
+# Insert the CD.
+vdo change-media --update "$GUEST" "$GUEST_CDROM" "$1"
+
+set +x
+vwait
+set -x
+
+#sleep 5 # XXX: Let things settle.
+
+if [ "$2" ]; then
+ scp "$2" "$SSH:"
+ sleep 5 # XXX: openssh on windows is a bit fragile...
+ time vssh "cmd /c $(basename $2)"
+else
+ time vssh "cmd /c d:/run-tests.bat"
+fi
+
+sleep 5 # XXX: openssh on windows is a bit fragile...
+
+# The scp server is a bit fragile as well, and I believe globbing does
+# not work. Simply use gpgtar.
+vssh 'powershell -Command "cd c:\temp\logs ; d:/gnupg/gpgtar.exe --create ."' | tar x --warning=no-timestamp
+
+# Shutdown.
+vdo shutdown "$GUEST"
diff --git a/misc/jenkins/bin/run-tests.bat b/misc/jenkins/bin/run-tests.bat
new file mode 100644
index 0000000..99cfc53
--- /dev/null
+++ b/misc/jenkins/bin/run-tests.bat
@@ -0,0 +1,44 @@
+@echo off
+
+set BIN_PREFIX=d:\gnupg
+set abs_top_srcdir=%BIN_PREFIX%
+set PATH=%BIN_PREFIX%;%PATH%
+set GPGSCM_PATH=%BIN_PREFIX%/tests/gpgscm;%BIN_PREFIX%/tests/openpgp
+set EXEEXT=.exe
+set TMP=c:\temp
+set WD=c:\temp\logs
+mkdir %TMP%
+mkdir %WD%
+
+cd /d %BIN_PREFIX%
+echo Running self tests...
+%BIN_PREFIX%\gpgscm.exe --verbose tests/gpgscm/t-child.scm
+
+rem the gpgtar.scm is acting up (looping), and we don't deal with that
+rem well atm, so we simply omit it
+
+echo Running OpenPGP tests...
+cd /d %WD%
+mkdir openpgp
+cd openpgp
+
+%BIN_PREFIX%\gpgscm.exe %abs_top_srcdir%/tests/openpgp/run-tests.scm --parallel version.scm enarmor.scm mds.scm decrypt.scm decrypt-multifile.scm decrypt-dsa.scm decrypt-session-key.scm sigs.scm sigs-dsa.scm encrypt.scm encrypt-multifile.scm encrypt-dsa.scm compression.scm seat.scm clearsig.scm encryptp.scm detach.scm detachm.scm armsigs.scm armencrypt.scm armencryptp.scm signencrypt.scm signencrypt-dsa.scm armsignencrypt.scm armdetach.scm armdetachm.scm genkey1024.scm conventional.scm conventional-mdc.scm multisig.scm verify.scm verify-multifile.scm gpgv-forged-keyring.scm armor.scm import.scm import-revocation-certificate.scm ecc.scm 4gb-packet.scm tofu.scm use-exact-key.scm default-key.scm export.scm ssh-import.scm ssh-export.scm quick-key-manipulation.scm key-selection.scm delete-keys.scm gpgconf.scm issue2015.scm issue2346.scm issue2417.scm issue2419.scm issue2929.scm
+
+echo Running gpgsm tests...
+cd /d %WD%
+mkdir gpgsm
+cd gpgsm
+
+set GPGSCM_PATH=%BIN_PREFIX%/tests/gpgscm;%BIN_PREFIX%/tests/openpgp;%BIN_PREFIX%/tests/gpgsm
+%BIN_PREFIX%\gpgscm.exe %abs_top_srcdir%/tests/gpgsm/run-tests.scm --parallel import.scm encrypt.scm verify.scm decrypt.scm sign.scm export.scm
+
+echo Running GPGME tests...
+cd /d %WD%
+mkdir gpgme
+cd gpgme
+
+rem set verbose=3
+set GPGSCM_PATH=%BIN_PREFIX%/tests/gpgscm;%BIN_PREFIX%/tests/openpgp;%BIN_PREFIX%/tests/gpgme
+set XTEST_GPGME_SRCDIR=%BIN_PREFIX%/gpgme
+set XTEST_GPGME_BUILDDIR=%BIN_PREFIX%/gpgme/obj.w32
+%BIN_PREFIX%\gpgscm.exe %abs_top_srcdir%/tests/gpgme/run-tests.scm --parallel
diff --git a/misc/jenkins/jobs/gnupg-1.4/config.xml b/misc/jenkins/jobs/gnupg-1.4/config.xml
new file mode 100644
index 0000000..01719bc
--- /dev/null
+++ b/misc/jenkins/jobs/gnupg-1.4/config.xml
@@ -0,0 +1,133 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/gnupg.git
+
+
+
+
+ */STABLE-BRANCH-1-4
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 5 * * 0
+
+
+ true
+
+
+ XTARGET
+
+ native
+ w32
+ distcheck
+
+
+
+
+
+ /bin/bash /var/lib/jenkins/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+
+ 180
+
+
+
+
+
+
+
+
+ false
+ XTARGET == "native"
+
+ SUCCESS
+ 0
+ BLUE
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/gnupg-2.0/config.xml b/misc/jenkins/jobs/gnupg-2.0/config.xml
new file mode 100644
index 0000000..04c2dec
--- /dev/null
+++ b/misc/jenkins/jobs/gnupg-2.0/config.xml
@@ -0,0 +1,133 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/gnupg.git
+
+
+
+
+ */STABLE-BRANCH-2-0
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 5 * * 0
+
+
+ true
+
+
+ XTARGET
+
+ native
+ w32
+ distcheck
+
+
+
+
+
+ /bin/bash /var/lib/jenkins/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+
+ 180
+
+
+
+
+
+
+
+
+ false
+ XTARGET == "native"
+
+ SUCCESS
+ 0
+ BLUE
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/gnupg-2.2/config.xml b/misc/jenkins/jobs/gnupg-2.2/config.xml
new file mode 100644
index 0000000..c700700
--- /dev/null
+++ b/misc/jenkins/jobs/gnupg-2.2/config.xml
@@ -0,0 +1,144 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/gnupg.git
+
+
+
+
+ */STABLE-BRANCH-2-2
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 5 * * 0
+
+
+ true
+
+
+ XTARGET
+
+ native
+ sanitizer
+ w32
+ distcheck
+
+
+
+ label
+
+ debian
+ macos
+ openbsd
+ master
+
+
+
+ (label == "master" && XTARGET != "native") || (label != "master" && XTARGET == "native")
+
+
+ /bin/bash $HOME/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+
+ 180
+
+
+
+
+
+
+
+
+ false
+ label == "debian" && XTARGET == "native"
+
+ SUCCESS
+ 0
+ BLUE
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/gnupg/config.xml b/misc/jenkins/jobs/gnupg/config.xml
new file mode 100644
index 0000000..720f30b
--- /dev/null
+++ b/misc/jenkins/jobs/gnupg/config.xml
@@ -0,0 +1,163 @@
+
+
+
+ This tracks the master branch of GnuPG.
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/gnupg.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 4 * * *
+
+
+ true
+
+
+ XTARGET
+
+ native
+ sanitizer
+ w32
+ distcheck
+
+
+
+ label
+
+ debian
+ macos
+ master
+ openbsd60
+
+
+
+ (label == "master" && XTARGET != "native") || (label != "master" && XTARGET == "native")
+
+
+ /bin/bash $HOME/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+ gnupg-devel@conference.jabber.gnupg.org
+ false
+
+
+ FAILURE_AND_FIXED
+ false
+ false
+ false
+ false
+ false
+
+ ONLY_CONFIGURATIONS
+
+
+
+
+
+ 400
+ 3
+ false
+ 60
+
+
+
+
+
+
+
+
+ false
+ label == "debian" && XTARGET == "native"
+
+ UNSTABLE
+ 1
+ YELLOW
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/gpa/config.xml b/misc/jenkins/jobs/gpa/config.xml
new file mode 100644
index 0000000..bfaa21d
--- /dev/null
+++ b/misc/jenkins/jobs/gpa/config.xml
@@ -0,0 +1,133 @@
+
+
+
+ GNU Privacy Assistant.
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/gpa.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpa.git
+
+
+
+
+ 300
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 6 * * 0
+
+
+ true
+
+
+ XTARGET
+
+ native
+ distcheck
+
+
+
+
+
+ /bin/bash /var/lib/jenkins/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+
+ 180
+
+
+
+
+
+
+
+
+ false
+ XTARGET == "native"
+
+ SUCCESS
+ 0
+ BLUE
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/gpgme/config.xml b/misc/jenkins/jobs/gpgme/config.xml
new file mode 100644
index 0000000..ae03cdb
--- /dev/null
+++ b/misc/jenkins/jobs/gpgme/config.xml
@@ -0,0 +1,163 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/gpgme.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 5 * * *
+
+
+ true
+
+
+ XTARGET
+
+ native
+ sanitizer
+ w32
+ distcheck
+
+
+
+ label
+
+ debian
+ macos
+ master
+ openbsd60
+
+
+
+ (label == "master" && XTARGET != "native") || (label != "master" && XTARGET == "native")
+
+
+ /bin/bash $HOME/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+ gnupg-devel@conference.jabber.gnupg.org
+ false
+
+
+ FAILURE_AND_FIXED
+ false
+ false
+ false
+ false
+ false
+
+ ONLY_CONFIGURATIONS
+
+
+
+
+
+ 400
+ 3
+ false
+ 60
+
+
+
+
+
+
+
+
+ false
+ label == "debian" && XTARGET == "native"
+
+ SUCCESS
+ 0
+ BLUE
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/libassuan/config.xml b/misc/jenkins/jobs/libassuan/config.xml
new file mode 100644
index 0000000..9237dae
--- /dev/null
+++ b/misc/jenkins/jobs/libassuan/config.xml
@@ -0,0 +1,147 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/libassuan.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libassuan
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 1 * * *
+
+
+ true
+
+
+ XTARGET
+
+ native
+ sanitizer
+ w32
+ distcheck
+
+
+
+ label
+
+ debian
+ macos
+ master
+ openbsd60
+
+
+
+ (label == "master" && XTARGET != "native") || (label != "master" && XTARGET == "native")
+
+
+ /bin/bash $HOME/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+
+ 400
+ 3
+ true
+ 30
+
+
+
+
+
+
+
+
+ false
+ label == "debian" && XTARGET == "native"
+
+ SUCCESS
+ 0
+ BLUE
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/libgcrypt/config.xml b/misc/jenkins/jobs/libgcrypt/config.xml
new file mode 100644
index 0000000..40cd374
--- /dev/null
+++ b/misc/jenkins/jobs/libgcrypt/config.xml
@@ -0,0 +1,163 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/libgcrypt.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 2 * * *
+
+
+ true
+
+
+ XTARGET
+
+ native
+ sanitizer
+ w32
+ distcheck
+
+
+
+ label
+
+ debian
+ macos
+ master
+ openbsd60
+
+
+
+ (label == "master" && XTARGET != "native") || (label != "master" && XTARGET == "native")
+
+
+ /bin/bash $HOME/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+ gnupg-devel@conference.jabber.gnupg.org
+ false
+
+
+ FAILURE_AND_FIXED
+ false
+ false
+ false
+ false
+ false
+
+ ONLY_CONFIGURATIONS
+
+
+
+
+
+ 400
+ 3
+ false
+ 60
+
+
+
+
+
+
+
+
+ false
+ label == "debian" && XTARGET == "native"
+
+ UNSTABLE
+ 1
+ YELLOW
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/libgpg-error/config.xml b/misc/jenkins/jobs/libgpg-error/config.xml
new file mode 100644
index 0000000..22c0fbd
--- /dev/null
+++ b/misc/jenkins/jobs/libgpg-error/config.xml
@@ -0,0 +1,164 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/libgpg-error.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 0 * * *
+
+
+
+ true
+
+
+ XTARGET
+
+ native
+ sanitizer
+ w32
+ distcheck
+
+
+
+ label
+
+ debian
+ macos
+ master
+ openbsd60
+
+
+
+ (label == "master" && XTARGET != "native") || (label != "master" && XTARGET == "native")
+
+
+ /bin/bash $HOME/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+ gnupg-devel@conference.jabber.gnupg.org
+ false
+
+
+ FAILURE_AND_FIXED
+ false
+ false
+ false
+ false
+ false
+
+ ONLY_CONFIGURATIONS
+
+
+
+
+
+ 400
+ 3
+ true
+ 30
+
+
+
+
+
+
+
+
+ false
+ label == "debian" && XTARGET == "native"
+
+ SUCCESS
+ 0
+ BLUE
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/libksba/config.xml b/misc/jenkins/jobs/libksba/config.xml
new file mode 100644
index 0000000..532e09d
--- /dev/null
+++ b/misc/jenkins/jobs/libksba/config.xml
@@ -0,0 +1,160 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/libksba.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libksba.git
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 3 * * *
+
+
+ true
+
+
+ XTARGET
+
+ native
+ sanitizer
+ w32
+ distcheck
+
+
+
+ label
+
+ debian
+ macos
+ master
+ openbsd60
+
+
+
+ (label == "master" && XTARGET != "native") || (label != "master" && XTARGET == "native")
+
+
+ /bin/bash $HOME/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+ gnupg-devel@conference.jabber.gnupg.org
+ false
+
+
+ FAILURE_AND_FIXED
+ false
+ false
+ false
+ false
+ false
+
+ ONLY_CONFIGURATIONS
+
+
+
+
+
+ 180
+
+
+
+
+
+
+
+
+ false
+ label == "debian" && XTARGET == "native"
+
+ SUCCESS
+ 0
+ BLUE
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/npth/config.xml b/misc/jenkins/jobs/npth/config.xml
new file mode 100644
index 0000000..bc74ec1
--- /dev/null
+++ b/misc/jenkins/jobs/npth/config.xml
@@ -0,0 +1,147 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/npth.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=npth.git
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 0 * * *
+
+
+ true
+
+
+ XTARGET
+
+ native
+ sanitizer
+ w32
+ distcheck
+
+
+
+ label
+
+ debian
+ macos
+ master
+ openbsd60
+
+
+
+ (label == "master" && XTARGET != "native") || (label != "master" && XTARGET == "native")
+
+
+ /bin/bash $HOME/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+
+ 400
+ 3
+ true
+ 30
+
+
+
+
+
+
+
+
+ false
+ label == "debian" && XTARGET == "native"
+
+ SUCCESS
+ 0
+ BLUE
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/ntbtls/config.xml b/misc/jenkins/jobs/ntbtls/config.xml
new file mode 100644
index 0000000..ba9eefd
--- /dev/null
+++ b/misc/jenkins/jobs/ntbtls/config.xml
@@ -0,0 +1,163 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/ntbtls.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=ntbtls.git
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 2 * * *
+
+
+ true
+
+
+ XTARGET
+
+ native
+ sanitizer
+ w32
+ distcheck
+
+
+
+ label
+
+ debian
+ macos
+ master
+ openbsd60
+
+
+
+ (label == "master" && XTARGET != "native") || (label != "master" && XTARGET == "native")
+
+
+ /bin/bash $HOME/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+ gnupg-devel@conference.jabber.gnupg.org
+ false
+
+
+ FAILURE_AND_FIXED
+ false
+ false
+ false
+ false
+ false
+
+ ONLY_CONFIGURATIONS
+
+
+
+
+
+ 400
+ 3
+ false
+ 60
+
+
+
+
+
+
+
+
+ false
+ label == "debian" && XTARGET == "native"
+
+ UNSTABLE
+ 1
+ YELLOW
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/pinentry/config.xml b/misc/jenkins/jobs/pinentry/config.xml
new file mode 100644
index 0000000..3b74a75
--- /dev/null
+++ b/misc/jenkins/jobs/pinentry/config.xml
@@ -0,0 +1,134 @@
+
+
+
+ This tracks the pinentry suite.
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/pinentry.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git
+
+
+
+
+ 300
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 4 * * *
+
+
+ true
+
+
+ XTARGET
+
+ native
+ w32
+ distcheck
+
+
+
+
+
+ /bin/bash /var/lib/jenkins/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+
+ 180
+
+
+
+
+
+
+
+
+ false
+ XTARGET == "native"
+
+ SUCCESS
+ 0
+ BLUE
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/poldi/config.xml b/misc/jenkins/jobs/poldi/config.xml
new file mode 100644
index 0000000..8906ce7
--- /dev/null
+++ b/misc/jenkins/jobs/poldi/config.xml
@@ -0,0 +1,132 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/poldi.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=poldi.git
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 5 * * 0
+
+
+ true
+
+
+ XTARGET
+
+ native
+ distcheck
+
+
+
+
+
+ /bin/bash /var/lib/jenkins/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+
+ 180
+
+
+
+
+
+
+
+
+ false
+ XTARGET == "native"
+
+ SUCCESS
+ 0
+ BLUE
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/scute/config.xml b/misc/jenkins/jobs/scute/config.xml
new file mode 100644
index 0000000..4cb4d3b
--- /dev/null
+++ b/misc/jenkins/jobs/scute/config.xml
@@ -0,0 +1,125 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/scute.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=scute
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 5 * * 0
+
+
+ true
+
+
+ XTARGET
+
+ native
+ w32
+
+
+
+
+
+ /bin/bash /var/lib/jenkins/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:\s*[0-9]*[1-9][0-9]*
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ false
+ false
+
+
+
+
+
+ 180
+
+
+
+
+
+
+
+
+ false
+
+
\ No newline at end of file
diff --git a/misc/jenkins/jobs/tgpg/config.xml b/misc/jenkins/jobs/tgpg/config.xml
new file mode 100644
index 0000000..7bcce27
--- /dev/null
+++ b/misc/jenkins/jobs/tgpg/config.xml
@@ -0,0 +1,133 @@
+
+
+
+
+ false
+
+
+ 2
+
+
+ git://git.gnupg.org/tgpg.git
+
+
+
+
+ */master
+
+
+ false
+
+ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=tgpg.git
+
+
+
+
+ true
+ false
+ false
+ false
+ 2ebda902c5b3f792c7ae415d159ff8b70b208730b9e55f28d675a4acc1900403
+
+
+ H(0-30) 5 * * 0
+
+
+ true
+
+
+ XTARGET
+
+ native
+ w32
+ distcheck
+
+
+
+
+
+ /bin/bash /var/lib/jenkins/bin/build.bash
+
+
+
+
+
+
+ low
+ [WARNINGS]
+
+ false
+ false
+ false
+ false
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ false
+ true
+ true
+
+
+
+
+
+
+ GNU Make + GNU C Compiler (gcc)
+
+
+
+
+ FAIL:
+ false
+ true
+ true
+
+
+ 0
+
+ clangScanBuildReports
+ false
+
+
+ justus@g10code.com
+ true
+ false
+
+
+
+
+
+ 180
+
+
+
+
+
+
+
+
+ false
+ XTARGET == "native"
+
+ SUCCESS
+ 0
+ BLUE
+ true
+
+
+
\ No newline at end of file
diff --git a/misc/git.gnupg.org/index.html b/misc/lists.gnupg.org/index.html
similarity index 56%
copy from misc/git.gnupg.org/index.html
copy to misc/lists.gnupg.org/index.html
index af532e4..2e4f648 100644
--- a/misc/git.gnupg.org/index.html
+++ b/misc/lists.gnupg.org/index.html
@@ -1,213 +1,201 @@
-
+
-
+
- The GnuPG Repositories
+ GnuPG and GNUTLS Mailing List Archives
· English ·
- The GnuPG Repositories
+ GnuPG and GNUTLS Mailing List Archives
+
-Use our GIT
-Viewer to browse the GIT
-repository. Activity reports
-are also available.
-
-
-Here is a list of shortcuts to often used repositories:
+Please check the GnuPG FAQ before
+you ask on one of the lists.
-
-GnuPG
-
-
- Libgcrypt
-
-
- Gpg4win
-
-
-For actual work you should clone a repository; use
+Please send questions about using, compiling, and installing GnuPG to
+gnupg-users@gnupg.org and ask
+to CC you in case you are not subscribed to this mailing list.
-
- git clone git://git.gnupg.org/foo.git
-
-and replace foo by the name of the project (e.g. gnupg
-or libgcrypt ).
+Please send questions about using, compiling, and installing GNUTLS to
+gnutls-help@lists.gnutls.org
+and ask to CC you in case you are not subscribed to this mailing list.
-
+
General
+
-Notes
-
-Here is a list of projects now hosted on other servers:
-
+Users
+Developers
+
diff --git a/misc/lists.gnupg.org/logo-gnupg-light-purple-bg.png b/misc/lists.gnupg.org/logo-gnupg-light-purple-bg.png
new file mode 100644
index 0000000..41264d9
Binary files /dev/null and b/misc/lists.gnupg.org/logo-gnupg-light-purple-bg.png differ
diff --git a/misc/lists.gnupg.org/logo-sponsor.png b/misc/lists.gnupg.org/logo-sponsor.png
new file mode 100644
index 0000000..e01ada7
Binary files /dev/null and b/misc/lists.gnupg.org/logo-sponsor.png differ
diff --git a/misc/lists.gnupg.org/pace.png b/misc/lists.gnupg.org/pace.png
new file mode 100644
index 0000000..d627c9a
Binary files /dev/null and b/misc/lists.gnupg.org/pace.png differ
diff --git a/misc/lists.gnupg.org/robots.txt b/misc/lists.gnupg.org/robots.txt
new file mode 100644
index 0000000..024ae7d
--- /dev/null
+++ b/misc/lists.gnupg.org/robots.txt
@@ -0,0 +1,4 @@
+#
+# Lists.gnupg.org's Robot Exclusion List
+#
+User-Agent: *
diff --git a/misc/lists.gnupg.org/site.css b/misc/lists.gnupg.org/site.css
new file mode 100644
index 0000000..884dad5
--- /dev/null
+++ b/misc/lists.gnupg.org/site.css
@@ -0,0 +1,209 @@
+A:link {
+ color: #784c6c;
+ font-weight: bold;
+ text-decoration: none;
+}
+A:hover {
+ background-color: #d0dce8;
+ font-weight: bold;
+ text-decoration: none;
+}
+A:visited {
+ color: #5c6064;
+ font-weight: bold;
+ text-decoration: none;
+}
+A.img:hover {
+ background-color: #f0f0fc;
+}
+BLOCKQUOTE {
+ border: 1px solid black;
+ padding: 1em;
+}
+BODY {
+ margin-left: 0px;
+ margin-right: 0px;
+ text-align: left;
+ color: black;
+ background-color: #f0f0fc;
+ font-family: sans-serif;
+ font-weight: normal;
+ text-decoration: none;
+}
+DD {
+ padding-bottom: 1em;
+}
+H1,
+H2 {
+ font-size: large;
+}
+H1:first-letter,
+H2:first-letter {
+ font-size: x-large;
+}
+H3:first-letter {
+ font-size: large;
+}
+H1,
+H2,
+H3 {
+ color: #5c6064;
+ font-weight: bold;
+ font-variant: small-caps;
+ letter-spacing: 0.1em;
+}
+H1:first-letter,
+H2:first-letter,
+H3:first-letter {
+ color: #784c6c;
+}
+IMG {
+ border: none;
+}
+LI.important {
+ color: red;
+}
+P.out-of-date {
+ font-style: italic;
+ font-size: small;
+}
+PRE,
+DIV.samp {
+ background-color: #ebebf4;
+ margin: 1em;
+ border: 1px solid black;
+ padding: 1em;
+ font-size: small;
+}
+SPAN.important {
+ color: red;
+}
+DIV.urgent {
+ width: 85%;
+ text-align: center;
+ border: solid red;
+ font-weight: bold;
+}
+TABLE.layout {
+ background-color: transparent;
+ border-collapse: separate;
+ border: none;
+}
+TD.layout {
+ border: 1px none black;
+ padding: 0px;
+ text-align: right;
+ vertical-align: top;
+}
+TABLE.frame {
+ background-color: transparent;
+ border-collapse: collapse;
+ border: 1px none black;
+}
+TD.frame-right {
+ border-left: 2px solid #784c6c;
+}
+TD.frame-bottom,
+TD.frame-bottom-lang,
+TD.frame-bottom-mirror {
+ color: #5c6064;
+ border-top: 2px solid #5c6064;
+ text-align: left;
+ font-size: small;
+ font-weight: bold;
+}
+TD.frame-bottom-lang,
+TD.frame-bottom-mirror {
+ font-size: x-small;
+}
+TD.frame-bottom-mirror {
+ text-align: right;
+}
+TD.frame-corner {
+ border-top: 2px solid #5c6064;
+ border-left: 2px solid #784c6c;
+}
+TD.frame-spacing {
+ border: none;
+ height: 30px;
+}
+TD.frame-head {
+ padding: 0px 0px 1em 0px;
+ border: none;
+ text-align: center;
+ vertical-align: middle;
+ font-size: large;
+ font-variant: small-caps;
+ font-weight: bold;
+ letter-spacing: 0.3em;
+}
+TD.frame-head-blockquote {
+ padding: 0px 1em 1em 1em;
+ border-bottom: 2px solid #5c6064;
+ vertical-align: middle;
+ font-family: sans-serif;
+ text-align: center;
+ text-decoration: none;
+ font-size: x-small;
+ font-variant: small-caps;
+ letter-spacing: 0.3em;
+}
+SPAN.g {
+ color: #784c6c;
+ font-size: x-large;
+}
+SPAN.nu {
+ color: #784c6c;
+}
+SPAN.pg {
+ color: #5c6064;
+ font-size: x-large;
+}
+A.lang {
+ font-size: x-small;
+}
+A.lang:visited {
+ color: #784c6c;
+}
+TD.frame-navb {
+ padding: 0px 0.3em 0.5em 0.3em;
+ text-align: left;
+ font-size: small;
+}
+UL.frame-navb {
+ margin: 0px;
+ margin-left: 1em;
+ padding-left: 1em;
+}
+UL.frame-navb:first-line {
+ margin: 0px;
+ padding-left: 1em;
+}
+LI.frame-navb {
+}
+TD.frame-cont {
+ padding: 0px 1em 1.5em 1em;
+ text-align: left;
+ vertical-align: top;
+}
+DIV.frame-foot {
+ text-align: center;
+ font-size: x-small;
+ color: #5c6064;
+}
+A.foot:link {
+ color: #5c6064;
+ font-size: x-small;
+ font-weight: normal;
+ text-decoration: underline;
+}
+A.foot:visited {
+ color: #5c6064;
+ font-size: x-small;
+ font-weight: normal;
+ text-decoration: underline;
+}
+A.foot:hover {
+ font-size: x-small;
+ font-weight: normal;
+}
diff --git a/tools/append-to-donors.sh b/tools/append-to-donors.sh
index 6ce4e6b..53697d2 100755
--- a/tools/append-to-donors.sh
+++ b/tools/append-to-donors.sh
@@ -1,188 +1,303 @@
#!/bin/sh
# append-to-donors.sh
# Append new names from the payproc journal to the donors file
# and send a Thank You mail.
+#
+# Note that this script does not yet handle subscriptions. Because we
+# want to verify the mail address anyway, it makes sense to move mai
+# sending to payprocd. The final plan is to use webhooks to create
+# charge records and use them to add a Donor reulary to the list of
+# donors (but may be limited to once a year)
pgm="append-to-donors.sh"
set -e
# We temporary need the next line due to an libgpg-error update
LD_LIBRARY_PATH=/usr/local/lib
export LD_LIBRARY_PATH
PATH=/usr/local/bin:$PATH
SENDMAIL="/usr/sbin/sendmail"
LC_ALL=C
LC_CTYPE=C
RFCDATE="$(date -R)"
SIGDELIM="-- "
-htdocs="/var/www/www/www.gnupg.org/htdocs"
+usage()
+{
+ cat <&2
+ ;;
+ esac
+ shift
+done
+
+
+if [ $testmode = yes ]; then
+ htdocs="/var/www/www/preview.gnupg.org/htdocs"
+ journal_dir="/var/log/payproc-test"
+else
+ htdocs="/var/www/www/www.gnupg.org/htdocs"
+ journal_dir="/var/log/payproc"
+fi
donors="$htdocs/donate/donors.dat"
donations="$htdocs/donate/donations.dat"
-journal_dir="/var/log/payproc"
LOCKFILE="$donors.lock"
if [ ! -f "$donors" ]; then
echo "$pgm: '$donors' not found" >&2;
exit 1
fi
if [ x"$(idn --quiet wk@gnupg.org)" != x"wk@gnupg.org" ]; then
echo "$pgm: idn(1) tool not installed or not working"
exit 1
fi
if [ x"$(mu-tool 2047 -c utf-8 '')" \
!= x"=?utf-8?Q??=" ]; then
echo "$pgm: mu-tool(1) tool not installed or not working"
exit 1
fi
if ! lockfile -l 7200 -r 2 $LOCKFILE; then
echo "$pgm: another instance is still running"
exit 0
fi
trap "rm -f $LOCKFILE $donors.tmp $donors.stamp" 0
# Send a thank you mail
# Uses these variables:
# amount - The amount of the donation
# currency - The currency for the amount
# euro - The amount cinvertet to Euro
# xmail - The mailbox
# name - The name or empty for an anonymous donation
# message - The message to us or empty
+# recur - only when called with an arg > 0
+# service - 1 = Stripe, 2 = Paypal, 3 = SEPA
# Used scratch variables:
# upcurrency
# ineuro
# xamount
+# recur_text
#
# FIXME: Clean message and name and use an appropriate encoding.
# The second mail should actually be encrypted. In fact
# we would better try to encrypt also the first mail. Add a
# pubkey field to the donation page?
#
send_thanks () {
+ recur_text="one-time"
+ xextratext=""
+ if [ $1 -gt 0 ]; then
+ case "$recur" in
+ 12) recur_text="monthly"
+ ;;
+ 6) recur_text="bi-monthly"
+ ;;
+ 4) recur_text="quarterly"
+ ;;
+ 1) recur_text="yearly"
+ ;;
+ esac
+ fi
+ case "$service" in
+ 1) service_text="Stripe"
+ ;;
+ 2) service_text="PayPal"
+ ;;
+ 3) service_text="SEPA"
+ ;;
+ *) service_text="$service"
+ ;;
+ esac
upcurrency=$(echo $currency | tr [a-z] [A-Z])
if [ "$upcurrency" = EUR ]; then
ineuro=
else
ineuro=" (about $(echo $euro| awk '{print int($0 + 0.5)}') EUR)"
fi
xamount="$(echo $amount| awk '{print int($0 + 0.5)}')"
if [ -n "$xmail" ]; then
xidnmail=$(CHARSET=UTF-8 idn --no-tld --quiet "$xmail")
else
xidnmail=""
fi
- xqpmail=$(mu-tool 2047 -c utf-8 "$xmail")
+ if [ x"$xidnmail" = x"$xmail" ]; then
+ xqpmail="$xmail"
+ else
+ xqpmail=$(mu-tool 2047 -c utf-8 "$xmail")
+ fi
+ if [ $testmode = yes ]; then
+ xisatest="[TEST DONATION] "
+ else
+ xisatest=""
+ fi
( cat < "$donors.tmp"
-find $journal_dir -type f -name 'journal-????????.log' -print \
+find $journal_dir/ -type f -name 'journal-????????.log' -print \
| sort | while read fname; do
fname=$(basename "$fname")
jdate=${fname%.log}
jdate=${jdate#journal-}
jyear=$(echo $jdate |sed 's/\(....\).*/\1/')
if [ "$jdate" -ge "$lastdate" ]; then
[ "$jdate" -gt "$lastdate" ] && lastline=0
+ # First for charge records
payproc-jrnl -F_lnr -Fdate -F'[name]' -F'[message]' \
- -Fmail -Famount -Fcurrency -Feuro\
+ -Fmail -Famount -Fcurrency -Feuro -Fservice \
-S "_lnr > $lastline" -Stype=C -Saccount==1 \
--html --print "$journal_dir/journal-$jdate.log" \
| while IFS=: read lnr datestr name message \
- xmail amount currency euro rest; do
+ xmail amount currency euro service rest; do
name=$(echo "$name" | tr \`\$: ...)
message=$(echo "$message" | tr \`\$ ..)
xmail=$(echo "$xmail" | tr \`\$ .. | sed 's/\.$//')
# Note that we removed colons from $name
echo "$jyear:$datestr:$name::$lnr:" >> "$donors.tmp"
touch "$donors".stamp
- send_thanks
+ send_thanks 0
+ done
+ # Second for new subscriptions
+ payproc-jrnl -F_lnr -Fdate -F'[name]' -F'[message]' \
+ -Fmail -Famount -Fcurrency -Feuro -F service -Frecur \
+ -S "_lnr > $lastline" -Stype=S -Saccount==1 \
+ --html --print "$journal_dir/journal-$jdate.log" \
+ | while IFS=: read lnr datestr name message \
+ xmail amount currency euro service recur rest; do
+ name=$(echo "$name" | tr \`\$: ...)
+ message=$(echo "$message" | tr \`\$ ..)
+ xmail=$(echo "$xmail" | tr \`\$ .. | sed 's/\.$//')
+ # Note that we removed colons from $name
+ echo "$jyear:$datestr:$name:S:$lnr:" >> "$donors.tmp"
+ touch "$donors".stamp
+ send_thanks 1
done
fi
done
# If we have any new records update the files.
-if [ -f "$donors".stamp ]; then
+if [ -f "$donors".stamp -o $force = yes ]; then
if ! mv "$donors.tmp" "$donors"; then
echo "$pgm: error updating $donors" >&2
exit 1
fi
if [ -f "$donations" ]; then
payproc-stat -u "$donations" -- > "$donations".tmp \
- $(find /var/log/payproc -type f -name 'journal-????????.log' -print|sort)
+ $(find $journal_dir/ -type f -name 'journal-????????.log' -print|sort)
if ! mv "$donations".tmp "$donations"; then
echo "$pgm: error updating $donations" >&2
exit 1
fi
else
payproc-stat -u "$donations" -- > "$donations" \
- $(find /var/log/payproc -type f -name 'journal-????????.log' -print|sort)
+ $(find $journal_dir/ -type f -name 'journal-????????.log' -print|sort)
fi
fi
diff --git a/tools/build-website.sh b/tools/build-website.sh
new file mode 100755
index 0000000..2f8ceb9
--- /dev/null
+++ b/tools/build-website.sh
@@ -0,0 +1,334 @@
+#!/bin/sh
+# Build the gnupg.org website from a git working directory.
+#
+# This script requires two users
+#
+# webbuilder - the user to run this script
+# webbuild-x - the user used by this script to run emacs
+# webbuild-y - the user used by this script to run emacs (for preview)
+#
+# A certain directory layout is required with permissions setup
+# so that the webbuild-x has only write access to the stage area
+# and to its own home directory. The script checks the permissions.
+#
+# The trigger-website-build scripts is expected to be installed
+# as git post-merge hook.
+#
+# These cronjobs are required for user webbuilder:
+# --8<---------------cut here---------------start------------->8---
+# # Pull the master branch of the web pages
+# */20 * * * * cd /home/webbuilder/gnupg-doc && git pull -q origin master
+# */18 * * * * cd /home/webbuilder/gnupg-doc-preview && git pull -q origin preview
+#
+# # In case of race conditions we try to build every few ours again.
+# 35 */7 * * * /home/webbuilder/bin/build-website.sh --cron
+# --8<---------------cut here---------------end--------------->8---
+#
+# /etc/sudoers needs this:
+# --8<---------------cut here---------------start------------->8---
+# # Let webbuilder run any command as user webbuild-x
+# webbuilder ALL = (webbuild-x,webbuild-y) NOPASSWD: ALL
+# --8<---------------cut here---------------end--------------->8---
+#
+
+set -e
+
+pgm=build-website.sh
+mainuser=webbuilder
+workuser=webbuild-x
+workuser_pv=webbuild-y
+
+# We use a fixed HOME so that this script can be run here from other
+# accounts.
+HOME=$(awk &2;
+ exit 1
+fi
+
+reponame=gnupg-doc
+htdocs_web="/var/www/www/www.gnupg.org/htdocs"
+htdocs_preview="/var/www/www/preview.gnupg.org/htdocs"
+htdocs_blog="/var/www/www/www.gnupg.org/misc/blog"
+
+workuser_dir=$HOME/${workuser}
+workuser_pv_dir=$HOME/${workuser_pv}
+log_dir="$HOME/log"
+root_dir="$HOME/${reponame}"
+root_dir_pv="$HOME/${reponame}-preview"
+stage_dir="$HOME/${reponame}-stage"
+stage_dir_pv="$HOME/${reponame}-preview-stage"
+LOCKFILE="${log_dir}/${reponame}.lock"
+
+if [ x"$1" = x"--git" ]; then
+ shift
+ exec >>${log_dir}/"$reponame".log 2>&1
+ echo "$(date -u -Iseconds) gpgweb site build was git triggered"
+elif [ x"$1" = x"--cron" ]; then
+ shift
+ exec >>${log_dir}/"$reponame".log 2>&1
+ echo "$(date -u -Iseconds) gpgweb site build was cron triggered"
+fi
+
+if ! id $workuser >/dev/null 2>&1 ; then
+ echo "$pgm: sudo user '${workuser}' not available" >&2;
+ exit 1
+fi
+
+if ! id $workuser_pv >/dev/null 2>&1 ; then
+ echo "$pgm: sudo user '${workuser_pv}' not available" >&2;
+ exit 1
+fi
+
+# Check directories
+for f in "${workuser_dir}" "${root_dir}" "${stage_dir}" \
+ "${workuser_pv_dir}" "${root_dir_pv}" "${stage_dir_pv}"; do
+ if [ ! -d "$f" ]; then
+ echo "$pgm: directory '$f' missing" >&2;
+ exit 1
+ fi
+done
+want="2775:${workuser}:${mainuser}"
+for f in "${workuser_dir}" "${stage_dir}"; do
+ x=$(stat -c '%a:%U:%G' "$f")
+ if [ x"$x" != x"$want" ]; then
+ echo "$pgm: directory '$f' has wrong permissions" >&2
+ echo "$pgm: want: $want" >&2
+ echo "$pgm: have: $x" >&2
+ exit 1
+ fi
+done
+want="2775:${workuser_pv}:${mainuser}"
+for f in "${workuser_pv_dir}" "${stage_dir_pv}"; do
+ x=$(stat -c '%a:%U:%G' "$f")
+ if [ x"$x" != x"$want" ]; then
+ echo "$pgm: directory '$f' has wrong permissions" >&2
+ echo "$pgm: want: $want" >&2
+ echo "$pgm: have: $x" >&2
+ exit 1
+ fi
+done
+
+cd "${root_dir}"
+
+#
+# Take a lock so that only one instance of this script runs.
+#
+if ! lockfile -l 7200 -r 2 $LOCKFILE; then
+ echo "$pgm: another instance is still running" >&2
+ exit 0
+fi
+trap "rm -f $LOCKFILE" 0
+
+
+# These flags are set to the stage directory if a sync is required
+sync_web=
+sync_blog=
+sync_preview=
+
+
+#
+# Build main part
+#
+subdir=web
+
+revlastfile="${log_dir}/${reponame}.$(echo $subdir | tr / _).revlast"
+buildlog="${log_dir}/${reponame}.$(echo $subdir | tr / _).log"
+rev="$(git rev-parse --verify HEAD:$subdir)"
+if [ -z "$rev" ]; then
+ echo "$pgm: No git revision found" >&2;
+ exit 1
+fi
+revlast="$(head -1 ${revlastfile} 2>/dev/null || true)"
+if [ x"$rev" = x"$revlast" ]; then
+ echo "$pgm: No need to build $subdir" >&2;
+else
+
+ echo "$(date -u -Iseconds) build started for $subdir" | tee ${buildlog}
+
+ if [ ! -d ${stage_dir}/${subdir} ]; then
+ sudo -u webbuild-x mkdir ${stage_dir}/${subdir}
+ fi
+
+ sudo 2>>${buildlog} -u webbuild-x emacs24 -q --batch \
+ --eval "(require 'assoc)" \
+ --eval "(require 'org)" \
+ --eval "(setq make-backup-files nil)" \
+ --eval "(setq gpgweb-root-dir \"${root_dir}/${subdir}/\")" \
+ --eval "(setq gpgweb-stage-dir \"${stage_dir}/${subdir}/\")" \
+ --eval "(require 'gpgweb (concat gpgweb-root-dir \"share/gpgweb.el\"))" \
+ --eval "(setq org-publish-use-timestamps-flag nil)" \
+ --eval "(setq org-export-html-toplevel-hlevel 1)" \
+ --eval "(setq org-export-html-coding-system 'utf-8)" \
+ --eval "(gpgweb-setup-project)" \
+ --eval "(org-publish-initialize-cache \"gpgweb\")" \
+ --eval "(message \"root=(%s)\" gpgweb-root-dir)" \
+ --eval "(org-publish \"gpgweb\" t nil)"
+
+ echo "$rev" > ${revlastfile}
+ sync_web=${stage_dir}/${subdir}
+ echo "$(date -u -Iseconds) build finished for $subdir" | tee -a ${buildlog}
+fi
+
+
+#
+# Build blogs
+#
+subdir=misc/blog.gnupg.org
+
+revlastfile="${log_dir}/${reponame}.$(echo $subdir | tr / _).revlast"
+buildlog="${log_dir}/${reponame}.$(echo $subdir | tr / _).log"
+rev="$(git rev-parse --verify HEAD:$subdir)"
+if [ -z "$rev" ]; then
+ echo "$pgm: No git revision found" >&2;
+ exit 1
+fi
+revlast="$(head -1 ${revlastfile} 2>/dev/null || true)"
+if [ x"$rev" = x"$revlast" ]; then
+ echo "$pgm: No need to build $subdir" >&2;
+else
+
+ echo "$(date -u -Iseconds) build started for $subdir" | tee ${buildlog}
+
+ if [ ! -d ${stage_dir}/${subdir} ]; then
+ sudo -u webbuild-x mkdir -p ${stage_dir}/${subdir}
+ fi
+ cd ${stage_dir}/${subdir}
+
+ # We need to initialize that org cache to use our own publish function
+ # despite that we do not use any org-publish feature
+ echo "$pgm: Rendering blogs" >&2
+ sudo 2>>${buildlog} -u webbuild-x emacs24 -q --batch \
+ --eval "(require 'assoc)" \
+ --eval "(require 'org)" \
+ --eval "(setq gpgweb-root-dir \"${root_dir}/web/\")" \
+ --eval "(setq gpgweb-blog-dir \"${root_dir}/${subdir}/\")" \
+ --eval "(setq gpgweb-stage-dir \"${stage_dir}/${subdir}/\")" \
+ --eval "(require 'gpgweb (concat gpgweb-root-dir \"share/gpgweb.el\"))" \
+ --eval "(setq org-publish-use-timestamps-flag nil)" \
+ --eval "(setq org-export-html-toplevel-hlevel 1)" \
+ --eval "(setq org-export-html-coding-system 'utf-8)" \
+ --eval "(gpgweb-setup-project)" \
+ --eval "(org-publish-initialize-cache \"gpgweb\")" \
+ --eval "(message \"root=(%s)\" gpgweb-root-dir)" \
+ --eval "(gpgweb-publish-blogs)"
+
+ echo "$pgm: Updating blog index" >&2
+ indexcreator="${root_dir}/${subdir}/update-index.sh"
+ if [ ! -f $indexcreator ]; then
+ echo "$pgm: $indexcreator not found" >&2
+ exit 1
+ fi
+ sudo -u webbuild-x ${indexcreator}
+
+ echo "$rev" > ${revlastfile}
+ sync_blog=${stage_dir}/${subdir}
+ echo "$(date -u -Iseconds) build finished for $subdir" | tee -a ${buildlog}
+
+fi
+
+
+#
+# Build the preview site (w/o blogs)
+#
+branch=preview
+subdir=web
+
+cd "${root_dir_pv}"
+
+revlastfile="${log_dir}/${reponame}.$branch.$(echo $subdir | tr / _).revlast"
+buildlog="${log_dir}/${reponame}.$branch.$(echo $subdir | tr / _).log"
+rev="$(git rev-parse --verify $branch:$subdir)"
+if [ -z "$rev" ]; then
+ echo "$pgm: No git revision found" >&2;
+ exit 1
+fi
+revlast="$(head -1 ${revlastfile} 2>/dev/null || true)"
+if [ x"$rev" = x"$revlast" ]; then
+ echo "$pgm: No need to build $branch:$subdir" >&2;
+else
+
+ echo "$(date -u -Iseconds) build started for $branch:$subdir" | tee ${buildlog}
+
+ if [ ! -d ${stage_dir_pv}/${subdir} ]; then
+ sudo -u webbuild-y mkdir ${stage_dir_pv}/${subdir}
+ fi
+
+ sudo 2>>${buildlog} -u webbuild-y emacs24 -q --batch \
+ --eval "(require 'assoc)" \
+ --eval "(require 'org)" \
+ --eval "(setq make-backup-files nil)" \
+ --eval "(setq gpgweb-root-dir \"${root_dir_pv}/${subdir}/\")" \
+ --eval "(setq gpgweb-stage-dir \"${stage_dir_pv}/${subdir}/\")" \
+ --eval "(require 'gpgweb (concat gpgweb-root-dir \"share/gpgweb.el\"))" \
+ --eval "(setq org-publish-use-timestamps-flag nil)" \
+ --eval "(setq org-export-html-toplevel-hlevel 1)" \
+ --eval "(setq org-export-html-coding-system 'utf-8)" \
+ --eval "(gpgweb-setup-project)" \
+ --eval "(org-publish-initialize-cache \"gpgweb\")" \
+ --eval "(message \"root=(%s)\" gpgweb-root-dir)" \
+ --eval "(org-publish \"gpgweb\" t nil)"
+
+ echo "$rev" > ${revlastfile}
+ sync_preview=${stage_dir_pv}/${subdir}
+ echo "$(date -u -Iseconds) build finished for $branch:$subdir" | tee -a ${buildlog}
+fi
+cd "${root_dir}"
+
+
+#
+# Sync to the webspace
+#
+cd "${root_dir}"
+any_sync=
+
+if [ -n "$sync_web" ]; then
+ cd "$sync_web"
+ rsync -rlt --exclude '*~' --exclude '*.tmp' \
+ . ${htdocs_web}/
+ touch ${htdocs_web}/donate/donors.dat
+ cd ${htdocs_web}
+ ln -sf ../../howtos.gnupg.org/htdocs howtos
+ ln -sf software related_software
+ ln -sf software/index.html features.html
+ cd "$sync_web"
+ any_sync=yes
+fi
+
+if [ -n "$sync_blog" ]; then
+ cd "$sync_blog"
+ rsync -rt --links --exclude '*~' --exclude '*.sh' \
+ --exclude '*tmp' --exclude '*.org' . ${htdocs_blog}/
+ cd "$root_dir/misc/blog.gnupg.org"
+ rsync -rt --links --exclude '*~' --exclude '*.sh' \
+ --exclude '*tmp' --exclude '*.org' img data ${htdocs_blog}/
+ any_sync=yes
+fi
+
+if [ -n "$sync_preview" ]; then
+ cd "$sync_preview"
+ rsync -rlt --exclude '*~' --exclude '*.tmp' \
+ . ${htdocs_preview}/
+ $HOME/bin/mkkudos.sh --verbose --force --test
+fi
+
+
+cd "${root_dir}"
+
+if [ "$any_sync" = yes ]; then
+ $HOME/bin/mkkudos.sh --verbose --force
+fi
+
+
+#
+# Print warnings when the scripts are out of date
+# (For security reasons the scripts need to be installed manually.)
+#
+for f in trigger-website-build build-website.sh mkkudos.sh \
+ append-to-donors.sh ; do
+ if ! cmp -s ${HOME}/bin/$f tools/$f ; then
+ echo "$pgm: Warning: A newer version of $f is available" >&2;
+ fi
+done
+
+exit 0
diff --git a/tools/mkkudos.sh b/tools/mkkudos.sh
index 032958f..f88b48b 100755
--- a/tools/mkkudos.sh
+++ b/tools/mkkudos.sh
@@ -1,264 +1,370 @@
#!/bin/sh
# Update the list of donors and a few other things.
#
# ====================================================================
# This org-mode snippet is used to insert the progress bar into a HTML
# file:
#
# #+BEGIN_HTML
#
#
# #+END_HTML
#
+# For the 2017 campaign new variables which work slightly different
+# are introduced:
+#
+# #+BEGIN_HTML
+#
+#
+# a month
+#
+#
+#
+# a month of
+#
+# needed
+#
+#
+
+# in one-time donations
+#
+#
+# Supporters
+#
+# #+END_HTML
+#
# To use it the code at "Campaign data" below needs to be adjusted as
# well.
# ===================================================================
set -e
+LD_LIBRARY_PATH=/usr/local/lib
+export LD_LIBRARY_PATH
+
+
usage()
{
cat <
&2
;;
esac
shift
done
-htdocs="/var/www/www/www.gnupg.org/htdocs"
-donors="$htdocs/donate/donors.dat"
-donations="$htdocs/donate/donations.dat"
-blogheadlinefile="/var/www/www/blog.gnupg.org/htdocs/headlines.txt"
if [ $testmode = yes ]; then
- htdocs="/home/wk/s/gnupg-doc/stage"
- donors="$htdocs/../scratch/donors.dat"
- donations="$htdocs/../scratch/donations.dat"
- blogheadlinefile="$htdocs/../misc/blog.gnupg.org/headlines.txt"
+ htdocs="/var/www/www/preview.gnupg.org/htdocs"
+else
+ htdocs="/var/www/www/www.gnupg.org/htdocs"
fi
+donors="$htdocs/donate/donors.dat"
+donations="$htdocs/donate/donations.dat"
+blogheadlinefile="/var/www/www/blog.gnupg.org/htdocs/headlines.txt"
if [ ! -f "$donors" ]; then
echo "mkkudos.sh: '$donors' not found" >&2;
exit 1
fi
if [ ! -f "$donations" ]; then
echo "mkkudos.sh: '$donations' not found" >&2;
exit 1
fi
if [ ! -f "$blogheadlinefile" ]; then
echo "mkkudos.sh: '$blogheadlinefile' not found" >&2;
blogheadline=""
else
blogheadline=$(awk -F\| '
NR<=3 {printf "%s ", $1, $2}
' "$blogheadlinefile")
fi
tmp=$(head -1 "$donations")
monyear=$(echo "$tmp" | awk -F: 'BEGIN { m[1] = "January";
m[2] = "February"; m[3] = "March"; m[4] = "April"; m[5] = "May";
m[6] = "June"; m[7] = "July"; m[8] = "August"; m[9] = "September";
m[10] = "October"; m[11] = "November"; m[12] = "December"; }
{printf "%s %d", m[int($2)] , $1}')
thisyear=$(echo "$tmp" | awk -F: '{print $1}')
-euroyr=$(echo "$tmp" | awk -F: '{printf "%d €", int($10 + 0.5)}')
nyr=$(echo "$tmp" | awk -F: '{printf "%d", $9}')
-
+euroyr=$(echo "$tmp" | awk -F: '{printf "%d", int($10 + 0.5)}')
+recur_nyr=$(echo "$tmp" | awk -F: '{printf "%d", $13}')
+recur_euroyr=$(echo "$tmp" | awk -F: '{printf "%d", int($14 + 0.5)/12}')
dontable=$(awk -F: <"$donations" -v thisyear="$thisyear" '
BEGIN { m[1] = "January";
m[2] = "February"; m[3] = "March"; m[4] = "April"; m[5] = "May";
m[6] = "June"; m[7] = "July"; m[8] = "August"; m[9] = "September";
m[10] = "October"; m[11] = "November"; m[12] = "December" ;
printf "\n";
printf "\n";
printf " \n";
printf " \n";
printf " \n";
printf " \n";
printf "\n";
printf "\n";
printf "Month \n";
printf "# \n";
printf "€ \n";
printf " \n";
printf " \n";
printf "\n";
}
NR==1 { nyear = $9; totalyear = int($10 + 0.5);
}
$1 != thisyear {
printf " \n";
printf "\n";
printf "%d \n", thisyear;
printf " %d \n", nyear;
printf " %d \n", totalyear;
printf " \n";
printf "
\n";
exit 0
}
{ printf "%s \n", m[int($2)];
printf " %d \n", $7;
printf " %d \n",
int($8 + 0.5);
}
')
# Campaign data
+# Watchout for the 9074 below which are the donations received before the
+# campaign start.
goal="120000"
+recur_goal="15000"
percent=$(echo "$euroyr:$goal" | awk -F: '{ p = (int($1)*100)/int($2);
if(p > 100) { p = 100 };
printf "%d", p}')
+recur_percent=$(echo "$recur_euroyr:$recur_goal" \
+ | awk -F: '{ p = (int($1)*100)/int($2);
+ if(p > 100) { p = 100 };
+ printf "%d", p}')
for file in "$htdocs/donate/"kudos-????.html "$htdocs/donate/"kudos.html \
- "$htdocs/donate/"index.html \
+ "$htdocs/donate/"index.html "$htdocs/donate/"index.??.html \
"$htdocs/"index.html
do
+ [ -f "$file" ] || continue
if [ $force = no ]; then
[ "$file" -ot "$donors" ] || continue
fi
if [ "$file" = "$htdocs/donate/"kudos.html ]; then
year=$(date +%Y)
else
year=${file#$htdocs/donate/kudos-}
year=${year%.html}
fi
[ $verbose = yes ] && echo "processing $file" >&2
[ -f "$file.tmp" ] && rm "$file.tmp"
- awk -F: -v year="$year" -v donors="$donors" -v dontable="$dontable" \
+ # We need gawk to use "%'d" in inprint
+ gawk -F: -v year=$year -v donors="$donors" -v dontable="$dontable" \
-v monyear="$monyear" -v thisyear="$thisyear" \
-v euro="$euro" -v euroyr="$euroyr" \
-v nyr="$nyr" -v goal="$goal" -v percent="$percent" \
+ -v recur_nyr="$recur_nyr" -v recur_euroyr="$recur_euroyr" \
+ -v recur_goal="$recur_goal" -v recur_percent="$recur_percent" \
-v blogheadline="$blogheadline" \
<"$file" >"$file.tmp" '
// {indon=1; print; insert("") }
// {indon=0}
// {indon=1; print; insertsome("") }
// {indon=0}
// {indon=1; print; insert("goteo13") }
// {indon=0}
// {indon=1; print; print dontable }
// {indon=0}
// {
printf " %s\n", monyear;
next
}
// {
printf " %d\n", thisyear;
next
}
// {
- printf " %s\n", euroyr;
+ printf " %s €\n", euroyr;
next
}
// {
printf " %s\n", nyr;
next
}
// {
printf "%s €\n",
euro;
next
}
// {
printf "goal: %s €\n", goal;
next
}
// {
printf "style=\"width: %d%%\"\n",
percent;
next
}
// {
printf " %s\n", blogheadline;
next
}
+ /A-CMPGN-RECUR-EURO=""/ {
+ n = index($0,"\"");
+ printf "%s%s\" A-CMPGN-RECUR-EURO=\"\"\n",
+ substr($0,1,n), recur_euroyr;
+ next
+ }
+ /A-CMPGN-RECUR-EURO-GOAL=""/ {
+ n = index($0,"\"");
+ printf "%s%s\" A-CMPGN-RECUR-EURO-GOAL=\"\"\n",
+ substr($0,1,n), recur_goal;
+ next
+ }
+ /A-CMPGN-RECUR-PERCENT=""/ {
+ n = index($0,":");
+ printf "%s %s%\" A-CMPGN-RECUR-PERCENT=\"\"\n",
+ substr($0,1,n), recur_percent;
+ next
+ }
+ // {
+ n = index($0,"%s €\n",
+ substr($0,1,n), format_number(recur_euroyr);
+ next
+ }
+ // {
+ n = index($0,"%s €\n",
+ substr($0,1,n), format_number(recur_goal);
+ next
+ }
+ // {
+ n = index($0,"%s €\n",
+ substr($0,1,n), format_number( int(euroyr) - 9074 );
+ next
+ }
+ // {
+ n = index($0,"%s\n",
+ substr($0,1,n), format_number(recur_nyr);
+ next
+ }
+ // {
+ n = index($0,"%s USD\n",
+ substr($0,1,n), format_number( xflm );
+ next
+ }
!indon { print }
+ function format_number (n) {
+ buf = sprintf("%'"'"'d", int(n));
+ gsub(/,/, "\\ ", buf);
+ return buf;
+ }
+
function insert (tag) {
while (getline < donors) {
if ( $0 ~ /^(#.*)?$/ )
continue;
if ( $3 == "" )
continue;
if ($1==year && $4==tag) {
printf "%s \n", $3
}
+ else if ($1==year && $4=="S") {
+ printf "%s* \n", $3
+ }
}
close (donors)
}
function insertsome (tag) {
i = 0
while (getline < donors) {
if ( $0 ~ /^(#.*)?$/ )
continue;
if ( $3 == "" )
continue;
if ($4==tag) {
data[i++] = $3
}
+ else if ($4=="S") {
+ data[i++] = $3 "*"
+ }
}
close (donors)
j = i > 16 ? ( i - 16 ) : 0
while (j < i) {
printf "%s \n", data[j++]
}
}
'
mv "$file.tmp" "$file" || echo "mkkudos.sh: error updating $file" >&2
done
diff --git a/tools/news-file-to-org.awk b/tools/news-file-to-org.awk
new file mode 100644
index 0000000..4384ce5
--- /dev/null
+++ b/tools/news-file-to-org.awk
@@ -0,0 +1,179 @@
+# news-file-to-org.awk - Build a history org file from the NEWS file
+# Copyright (C) 2006, 2017 g10 Code GmbH
+#
+# This file is free software; as a special exception the author gives
+# unlimited permission to copy and/or distribute it, with or without
+# modifications, as long as this notice is preserved.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
+# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+
+# Empty lines as well as lines starting with a hash mark are entirly
+# ignored. Paragraphs are indicated by a "*" marker. A new revision
+# history starts with the "Noteworthy .." line; the release date is
+# expected in parentheses on that line. If it is not given the
+# section won't be rendered.
+#
+# This script is based on build-history.sh from gpg4win but stripped
+# down and changed from M4 output to org-mode output. As of now it
+# works only with GnuPG.
+
+
+BEGIN {
+ if ( lang == "" )
+ lang = "en";
+ in_section = 0;
+ in_para = 0;
+ in_vers = 0;
+ any_para = 0;
+ version = "";
+ reldate = "";
+ lines = "";
+ header = ""
+ seealso = ""
+
+ ml_base_url = "https://lists.gnupg.org/pipermail/"
+
+ header_text["en"] = "" \
+ "* GnuPG\n" ;
+
+ header_text["de"] = "" \
+ "* GnuPG\n" ;
+
+ release_text["en"] = "released ";
+ release_text["de"] = "veröffentlicht ";
+ noreldate_text["en"] = "[ in progress; not yet released ]";
+ noreldate_text["de"] = "[ in Arbeit; bisher noch nicht veröffentlicht ]";
+ explicit_dl_text["en"] = "Explicit download of this version:";
+ explicit_dl_text["de"] = "Expliziter Download dieser Version:";
+ readme_text["en"] = "Details in the README of this version:";
+ readme_text["de"] = "Details im README dieser Version:";
+
+ print header_text[lang];
+}
+
+function flush() {
+ if (in_section) {
+ printf "** GnuPG "
+ if (seealso)
+ printf "[[%s%s][%s]]", ml_base_url, seealso, hdr_version
+ else
+ printf "%s", hdr_version
+ printf " %s (%s)\n", release_text[lang], hdr_reldate;
+ printf "" \
+ " :PROPERTIES:\n" \
+ " :CUSTOM_ID: gnupg-%s\n" \
+ " :END:\n\n",
+ hdr_version;
+ print lines;
+ }
+ lines = ""
+ seealso = ""
+ in_section = 0;
+ in_para = 0;
+ in_vers = 0;
+ any_para = 0;
+}
+
+
+/^#/ { next }
+/^---/ { next }
+
+in_section && $0 ~ /^(Noteworthy|Version| Copyright)/ {
+ if (in_vers)
+ lines = lines "#end_example";
+ flush()
+}
+
+
+# Handle single Version lines used to announce a release date,
+!in_section && $0 ~ /^Version/ {
+ version = $2;
+ reldate = "";
+ if (index ($0, "(")) {
+ sub (/^.*\(/, "");
+ sub (/\).*$/, "");
+ reldate = $0;
+ print "** GnuPG " version " " release_text[lang] " (" reldate ")";
+ printf " :PROPERTIES:\n :CUSTOM_ID: gnupg-%s\n", version;
+ print " :END:\n"
+}
+ next;
+}
+
+!in_section {
+ if ($0 !~ /^Noteworthy/)
+ next;
+ if ( ! index ($0, "("))
+ next;
+ version = $5;
+ reldate = "";
+ sub (/^.*\(/, "");
+ sub (/\).*$/, "");
+ reldate = $0;
+ if (reldate ~ "unreleased")
+ next;
+ hdr_version = version
+ hdr_reldate = reldate
+ in_section = 1;
+ lines = "";
+ in_para = 0;
+ in_vers = 0;
+ any_para = 0;
+
+ next;
+}
+
+in_section && $0 ~ /^[ ]+[*] / {
+ in_para = 1;
+ any_para = 1;
+ indent_para = index($0, "*") + 2;
+ lines = lines sprintf(" - %s\n", substr ($0, indent_para));
+ next;
+}
+
+
+# Handle beta version announcement inside a section
+in_section && $0 ~ /^[ ]+\[Noteworthy changes in version / {
+ any_para = 1;
+ lines = lines sprintf(" %s\n", substr ($0, index($0, "[")));
+ next;
+}
+
+
+# Handle See-also lines inside a section
+in_section && $0 ~ /^[ ]+\See-also: [a-z]+/ {
+ seealso = $2;
+ next;
+}
+
+
+# We don't use the next in GnuPG's NEWS, but lets support it anyway.
+in_section && !in_vers && /^~~~/ {
+ if ( in_para ) {
+ in_para = 0;
+ }
+ in_para = 0;
+ in_vers = 1;
+ lines = lines "#begin_example"
+ next;
+}
+
+in_para {
+ lines = lines sprintf(" %s\n", substr ($0, indent_para));
+}
+
+in_vers && /^~~~/ {
+ in_vers = 0;
+ lines = lines "#end_example"
+}
+
+in_vers {
+ lines = lines $0;
+}
+
+
+END {
+ flush()
+}
diff --git a/tools/trigger-website-build b/tools/trigger-website-build
new file mode 100644
index 0000000..b0c5ae2
--- /dev/null
+++ b/tools/trigger-website-build
@@ -0,0 +1,12 @@
+#!/bin/sh
+# This is a post-merge hook to trigger building
+# gnupg.org
+
+reponame=$(git rev-parse --show-toplevel | sed s,.*/,,)
+
+unset $(git rev-parse --local-env-vars)
+
+if [ x"$reponame" = x"gnupg-doc" ]; then
+ exec $HOME/bin/build-website.sh --git &
+fi
+exit 0
diff --git a/web/Makefile b/web/Makefile
index d65dc10..e53d091 100644
--- a/web/Makefile
+++ b/web/Makefile
@@ -1,8 +1,18 @@
all: swdb.lst.sig
swdb.lst: swdb.mac
- awk '/^#\+macro:/ {print $$2, $$3}' swdb.mac >swdb.lst
+ awk ' \
+ ! /^#\+macro:/ {next} \
+ $$2 ~ /ftp_.*/ {next} \
+ {print $$2, $$3} \
+ ' swdb.mac >swdb.lst
swdb.lst.sig: swdb.lst
gpg -sbu 0x249B39D24F25E3B6 swdb.lst
+
+upload: swdb.lst.sig
+ scp swdb.lst.sig swdb.lst playfair.gnupg.org:/var/www/git/versions.gnupg.org/htdocs/
+ scp swdb.lst.sig swdb.lst webbuilder@trithemius.gnupg.org:/var/www/www/www.gnupg.org/htdocs/
+
+.PHONY: upload all
diff --git a/web/aegypten/development.org b/web/aegypten/development.org
index b924772..5e0865a 100644
--- a/web/aegypten/development.org
+++ b/web/aegypten/development.org
@@ -1,853 +1,853 @@
#+TITLE: GnuPG - Project Ägypten - Development
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
* Project Ägypten: Development
[[file:index.org][Home]] | [[file:tech.org][Technology]] | [[file:who.org][Who]] | [[file:time.org][Schedule]] | Development |
[[file:pr.org][Public Relations]] | [[file:glossary.org][Glossary]]
** Infrastructure
- CVS:
See below for detailed instructions.
- Bug-Tracking:
[[http://intevation.de/roundup/aegypten/][Ägypten Issue Tracker]]
(previously we used an
[[http://intevation.de/rt/webrt?q_queue=aegypten][RT-based issues
tracker for Ägypten]]. Please report new bugs only into the new
Roundup-based one.)
[[http://bugs.kde.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&product=kmail&component=encryption&component=general&component=IMAP&component=kmailcvt&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&newqueryname=&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=][KMail:
Open Bugs]] (report KMail related bugs here)
- Ägypten Mailing Lists:
Technical coordination is discussed at:
- [[http://lists.gnupg.org/mailman/listinfo/gpa-dev][gpa-dev]]
+ [[https://lists.gnupg.org/mailman/listinfo/gpa-dev][gpa-dev]]
This is also the list for the project Gnu Privacy Assistance (GPA)
and the tool Gnu Privacy Assistant (gpa).
Commits to Ägypten CVS:
- [[http://lists.gnupg.org/mailman/listinfo/aegypten-commits][aegypten-commits]]
+ [[https://lists.gnupg.org/mailman/listinfo/aegypten-commits][aegypten-commits]]
- Other Mailing Lists:
KMail development:
[[http://mail.kde.org/mailman/listinfo/kmail][kmail]]
There you won't find a link to the archive, it is here:
[[http://lists.kde.org/?l=kmail][kmail mailing list archive]]
GnuPG development:
- [[http://lists.gnupg.org/mailman/listinfo/gnupg-devel][gnupg-devel]]
+ [[https://lists.gnupg.org/mailman/listinfo/gnupg-devel][gnupg-devel]]
** How to test an Ägypten-enabled KMail or Mutt?
Please also note that the development is in flux and CVS instructions
might not be entirely up-to-date. Please report any problem to our
mailing list.
If you apply tar-balls or CVS, take care to use consistent prefixes for
your system. Use "make ; su -c 'make install'" instead of "make install"
if the prefixes points to a place you have no write-access for.
If you only interested in KMail and OpenPGP you might want to read the
KMail Howto: [[http://kmail.kde.org/kmail-pgpmime-howto.html][Using OpenPGP and PGP/MIME with KMail]].
*You should create and use a test user first* if you apply any version
that are not marked as stable releases in order to keep your private
mail and configuration safe.
*** Prerequisits for installing
These tools are required for the Ägypten features. They should already
be installed on your system or be readily available as binary package
for simple installation. Install them before you start any building of
other Ägypten packages.
- [[https://www.gnupg.org][GnuPG]] >= 1.2.2
*** Building Ägypten for KDE 3.1 and Mutt 1.5
You need at least KDE 3.1.0 plus corresponding devel-packages installed.
The packages described below are in fact the official KDE 3.1 tar-balls.
You need the following tar-balls (this combination is confirmed to
compile, but watch out for newer versions):
*Note:* The KDE 3.1 series requires GpgME 0.3 generation. GpgME >= 0.4.0
will not form a working Ägypten in conjunction with KDE 3.1. However,
KDE 3.2 will require the GpgME 0.4 generation.
*Security issue:* It is very important to apply the patch for kdenetwork
as listed below. This patch has been rejected by the KDE team as not
security relevant, but in fact not applying it, you have to stay with
the old crypto-backend which is unmaintained reguarding security fixes.
Also, if you upgrade from KDE 3.1.x to KDE 3.1.5 you should apply the
patch. If you don't you should not update the crypto-backend since the
updated one will not work without the patch applied.
The patch is in CVS KDE\_3\_1\_BRANCH already, so once there is a KDE
3.1.6 all is OK again.
For KMail:
[[ftp://ftp.trolltech.com/qt/source/qt-x11-free-3.1.2.tar.bz2][qt-x11-free-3.1.2.tar.bz2]]
(14MB)
[[ftp://ftp.kde.org/pub/kde/stable/3.1.5/src/arts-1.1.5.tar.bz2][arts-1.1.5.tar.bz2]]
(1MB)
[[ftp://ftp.kde.org/pub/kde/stable/3.1.5/src/kdelibs-3.1.5.tar.bz2][kdelibs-3.1.5.tar.bz2]]
(11MB)
[[ftp://ftp.kde.org/pub/kde/stable/3.1.5/src/kdebase-3.1.5.tar.bz2][kdebase-3.1.5.tar.bz2]]
(16MB)
[[ftp://ftp.kde.org/pub/kde/stable/3.1.5/src/kdenetwork-3.1.5.tar.bz2][kdenetwork-3.1.5.tar.bz2]]
(5MB)
[[ftp://ftp.kde.org/pub/kde/stable/3.1.5/src/kdepim-3.1.5.tar.bz2][kdepim-3.1.5.tar.bz2]]
(3.3MB)
For Mutt:
[[ftp://ftp.gnupg.org/gcrypt/alpha/aegypten/mutts-1.5.0-gpgme-030408.tar.gz][mutts-1.5.0-gpgme-030408.tar.gz]]
(1.4MB)
For any Ägypten-enabled mail user agent:
[[ftp://ftp.gnupg.org/gcrypt/alpha/libgpg-error/libgpg-error-0.6.tar.gz][libgpg-error-0.6.tar.gz]]
(400KB)
[[ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.1.91.tar.gz][libgcrypt-1.1.91.tar.gz]]
(900KB)
[[ftp://ftp.gnupg.org/gcrypt/alpha/libksba/libksba-0.9.1.tar.gz][libksba-0.9.1.tar.gz]]
(500KB)
[[ftp://ftp.gnupg.org/gcrypt/alpha/aegypten/opensc-0.7.0wk1.tar.gz][opensc-0.7.0wk1.tar.gz]]
(700KB, optional for smartcard support)
[[ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.6.2.tar.gz][libassuan-0.6.2.tar.gz]]
(300KB)
[[ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.3.tar.gz][gnupg-1.9.3.tar.gz]]
(1.2MB)
[[ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-0.3.16.tar.gz][gpgme-0.3.16.tar.gz]]
(700KB)
[[ftp://ftp.gnupg.org/gcrypt/alpha/cryptplug/cryptplug-0.3.16.tar.gz][cryptplug-0.3.16.tar.gz]]
(250KB)
[[ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-0.5.1.tar.gz][dirmngr-0.5.1.tar.gz]]
(200KB)
[[ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-0.7.0.tar.gz][pinentry-0.7.0.tar.gz]]
(300KB)
The build process looks like this:
1. *[KMail]*
cd /local-vol1/aegypten/compile
tar xvjf ../source/qt-x11-free-3.1.2.tar.bz2
cd qt-x11-free-3.1.2
export QTDIR=$PWD
./configure -prefix /usr/local/aegypten -thread
make install
2. *[KMail]*
export QTDIR=/usr/local/aegypten
export KDEDIR=/usr/local/aegypten
export LD\_LIBRARY\_PATH=$KDEDIR/lib:$QTDIR/lib
export PATH=$KDEDIR/bin:$PATH
(be sure to execute this later always before running parts of the
aegypten installation)
3. *[KMail]*
untar, configure with e.g. --prefix=/usr/local/aegypten, make and
install:
arts-1.1.5
kdelibs-3.1.5
kdebase-3.1.5
kdenetwork-3.1.5 (before compiling, apply
[[https://intevation.de/roundup/aegypten/file5/bug_18_fix.patch][this
patch]] in directory kdenetwork: patch -p0 < bug\_18\_fix.patch)
kdepim-3.1.5
4. *[Any MUA]*
untar, configure with e.g. --prefix=/usr/local/aegypten, make and
install:
libgpg-error-0.6
libassuan-0.6.2
libgcrypt-1.1.91
libksba-0.9.1
opensc-0.7.0wk1 (optional for smartcard support)
gnupg-1.9.3 (does not interfere with any gnupg < 1.9.0)
gpgme-0.3.16
cryptplug-0.3.16
dirmngr-0.5.1
pinentry-0.7.0
5. *[Mutt]*
export PATH=/usr/local/aegypten/bin:$PATH
(be sure to execute this later always before running parts of the
aegypten installation)
untar, configure with e.g. --prefix=/usr/local/aegypten, make and
install:
mutts-1.5.0-gpgme-030408 (you might have to change some file
ownership manually for installing)
*** Building Ägypten for KDE 3.2
It should be possible to use Ägypten1 with KDE 3.2 by just following the
rules as for KDE 3.1 and simple exchanging the KDE pachages accordingly.
Reports on success/failure/hints are welcome.
Please see the [[../aegypten2/index.html][Ägypten2 project page]] on how
to gain the new and extended features of the Ägypten2 project which
bases its work on KDE 3.2.
*** Prerequisits for using OpenPGP or S/MIME
1. Specify pinentry program (use pinentry-gtk, pinentry-qt or
pinentry-curses):
In file ~/.gnupg/gpg-agent.conf add:
no-grab
pinentry-program /some/where/bin/pinentry-qt
default-cache-ttl 600
2. Make sure gpg-agent is started before KMail and GnuPG:
This can be done manually in the same shell as you start KMail from:
eval "$(gpg-agent --daemon)"
The usual way to run the agent is from the `~/.xsession' file:
eval `gpg-agent --daemon`
If you don't use an X server, you can also put this into your regular
startup file `~/.profile' or `.bash\_profile'.
However, you should take that you don't have multiple instances of
gpg-agent running.
3. Configure KMail:
In the Cryptography section, add the Plug-In
/some/where/lib/cryptplug/gpgme-smime.so for S/MIME and/or
/some/where/lib/cryptplug/gpgme-openpgp.so for OpenPGP. Activate your
preferred one.
*** Using S/MIME
Follow these steps (you may skip the key generation if you just want to
verify signed messages or send encrypted ones) to perform the first
S/MIME activities (please note again that development is in flux and
things may change; this list is also incomplete: let us know where you
need more hints):
1. Configure GpgSM:
In file ~/.gnupg/gpgsm.conf add:
agent-program /some/where/bin/gpg-agent # not needed if in search
path
dirmngr-program /some/where/bin/dirmngr # not needed if in search
path
#disable-crl-checks # uncomment if you think it is appropriate
#disable-policy-checks # uncomment if you think it is appropriate
2. Create a smime certificate request (don't use this one for any real
security purpose!)
Note: [[#howto_import_external_certs][Below]] is a HowTo on
importing other external created certificates.
cat <<\EOF > ~/tmp/script.assuan
INPUT FD=4
OUTPUT FD=5 --armor
GENKEY
BYE
EOF
cat <<\EOF > ~/tmp/parms.txt
key-type: rsa
key-length: 1024
key-usage: sign, encrypt
name-dn: C=de,O=MyOrg,OU=Testlab,CN=Joe Tester
name-email: joe@nowher.org
EOF
gpgsm --server <~/tmp/script.assuan 4<~/tmp/parms.txt
5>~/tmp/out.pem
3. You can now sign this key by a certificate authority (CA).
Either you send the certificate request to an official CA or you can
set up your own CA with OpenSSL for this (the following is an excerpt
of the [[http://www.post1.com/home/ngps/m2/howto.ca.html][HOWTO:
Creating your own CA with OpenSSL by Pheng Siong Ng]] ):
#[install OpenSSL]
mkdir ~/CA
cd ~/CA
locate CA.pl # copy the file to .
locate openssl.cnf # copy the file to .
./CA.pl -newca # answer the questions
Now you have a working CA and can sign certificate requests. Since
OpenSSL can't handle email in the correct way, you have to add the
line
subjectAltName=email:copy,email:joe@nowher.org
to the file ~/CA/openssl.cnf. Then execute
export SSLEAY\_CONFIG="-config $HOME/CA/openssl.cnf"
Finally execute the certification process:
cp ~/tmp/out.pem newreq.pem
./CA.pl -sign # enter password of CA and confirm certification
4. Import the signed certificate:
gpgsm --import ~/CA/demoCA/cacert.pem # to have the cert of the CA
gpgsm --import ~/CA/newcert.pem
Now send yourself a s/mime signed email. If it does not work, contact us
on gpa-dev.
*** Using OpenPGP
1. Create your OpenPGP key-pair
Please make yourself familiar with GnuPG if you don't know how to do
this. Probably gpg is already installed on your system.
2. Configure KMail: Specify your OpenPGP identity.
3. Add to your ~/.gnupg/gpg.conf:
use-agent
Now you should be able to perform signature verification, decryption,
encryption, signing based on OpenPGP.
*** Using Smartcards
The Ägypten project uses
- TeleSec NetKey Card
- Towitoko ChipDrive micro USB (preferred) and V24
These devices are confirmed to work. Others may as well (please report).
**** Configuring OpenSC
You must install an opensc.conf file in {prefix}/etc; an example is
included in opensc-0.6.1-wk-20020415/etc/. We are using the pcsc
framework.
**** Configuring Smartcard reader
What's to be done is very dependent on your system.
USB: read [[http://www.linux-usb.org/][http://www.linux-usb.org/]] on
how to get your USB drive connected.
This example shows what was done on a Debian GNU/Linux Woody, Kernel
2.4.18 - the above link should be your prime source on learning how to
enable your USB device!):
#+BEGIN_EXAMPLE
mknod ttyUSB0 c 188 0 # if device does not already exist
mount -t usbdevfs none /proc/bus/usb # if this does not already exist
apt-get install libtowitoko2
modprobe usb-uhci # to switch on usb, if not already done
modprobe pl2303 # for the Towitoko Chipcard reader
apt-get install usbview # use this tool to check for devices
/etc/init.d/pcscd restart # might be necessary after connecting the device
#+END_EXAMPLE
V24: Just install libtowitoko2 and configure the proper serial port.
**** Preparing a pkcs15 card
*Note:* It may happen that you make the card unusable - it is also
likely that this happens due to bugs or instrallation problems. We have
been lucky so far in that we have only one file on one card which is not
deletable anymore.
1. Create a new test certificate and a key using OpenSSL (see above).
2. Insert the Netkey card and fire up opensc-explorer. Do this at the
opensc-explorer command line (we assume that it is a fresh card with
a 6 byte NullPIN):
#+BEGIN_EXAMPLE
change CHV0 00:00:00:00:00:00 "admin0"
get 2F00 saved-2F00
del 2F00
quit
#+END_EXAMPLE
We need to delete the GDO file because the record length used is too
short for our application. Note the new SO (Security Officer)
password ("admin0") somewhere.
3. Initialize the card:
pkcs15-init -C
You are asked for 2 PINs and PUKs; use at least 6 characaters. The
PUKs are not yet used, the SO password serves for this.
4. Write a certificate to the card:
pkcs15-init -X /somewhere/my\_cert.pem
5. Write a secret key to the card
pkcs15-init -S /somewhere/my\_private\_key.pem
You are asked for the PEM password which is used to protect the ket
in the PEM file and for CHV2, where you enter the password/PIN set in
step 2.
Note, you will see an error message - don't care about this.
6. Check that everything is fine:
$ pkcs15-tool --list-pins
After some garbage you should get:
#+BEGIN_EXAMPLE
Card has 2 PIN code(s).
PIN [Authentication PIN]
Com. Flags: 0x13
Auth ID : 01
Flags : [0x03], case-sensitive, local
Length : 6..16
Pad char : 0x00
Reference : 128
Type : 2
Path : 3F005015
PIN [Non-repudiation PIN]
Com. Flags: 0x13
Auth ID : 02
Flags : [0x03], case-sensitive, local
Length : 6..16
Pad char : 0x00
Reference : 129
Type : 2
Path : 3F005015
#+END_EXAMPLE
pkcs15-tool -c
#+BEGIN_EXAMPLE
Card has 1 certificate(s).
X.509 Certificate [Authentication Certificate]
Flags : 0
Authority: no
Path : 3F0050159001
ID : 45
#+END_EXAMPLE
pkcs15-tool -k
#+BEGIN_EXAMPLE
Card has 1 private key(s).
Private RSA Key [Authentication Key]
Com. Flags : 0
Usage : [0x4], sign
Access Flags: [0x1D], sensitive, alwaysSensitive, neverExtract,local
ModLength : 1024
Key ref : 0
Native : no
Path : 3F0050155001
Auth ID : 01
ID : 45
#+END_EXAMPLE
You may want to erase the PKCS15 structure in case of (very likely)
problems; you can use this script:
#+BEGIN_EXAMPLE
opensc-explorer <plain.sig
(if you did not had a secret key before, the card's user id is now
the default)
The PIN entry dialog should pop up and ask you for the Smartcard
Authentication PIN. (It is what you entered as CHV0 if you created
the pkcs15 bar-bones yourself).
There will also be a popup window to ask you to insert the card if
you did remove it from the reader or you are using a different one.
*** HowTo import externally generated keys and certificates into GpgSM
(written by Matthias Welwarsky)
Let's assume you have an S/MIME certificate, probably a personal
freemail certificate from Thawte or some other Certification Authority.
Thawte offers X509 S/MIME certificates via a web interface, you cannot
have gpgsm generate the Certificate Request and thus the private key,
your browser will do that. So the problem is, after the certificate got
issued, you have in inside you browser while you need it in GPGSM.
"Where's the problem?" you might say. "I can always export my
certificate as a PKCS#12 certificate bundle and import it into GPGSM."
That's true, but it's a bit more difficult. While GPGSM has an import
feature for PKCS#12 encoded secret keys, it is limited:
1. GPGSM cannot import the complete PKCS#12 bundle, ONLY the secret key
2. The Key must not be encrypted.
You need to import the secret key, the certificate, and the issuers
certificate. Unfortunately, there seems to be no GPGSM-Only solution,
but you can get along with a little help from OpenSSL :-)
Here's a step-by-step HOWTO that I used to get my Thawte certificate
into GPGSM:
1. Export the Certificate from your browser.
You probably have Mozilla, konqueror currently lacks support for
generating certificate requests. The browser will ask you to specifiy an
Export Password, be sure to remember it for the rest of the procedure,
and store the certificate into a file "certbundle.p12".
2. Use OpenSSL to extract the key from the bundle.
GPGSM currently seems to be unable to handle the complete bundle in one
go. You need to extract the pieces yourself. This can be done with the
following OpenSSL calls:
First, you must convert the bundle from PKCS#12 into PEM format:
bash$ openssl pkcs12 -in certbundle.p12 -out certbundle.pem -nodes
OpenSSL will ask you for the Export Password, that's the password you
used in your Browser to export the password.
Then, extract the key from the bundle and export it, again in PKCS#12
format
bash$ openssl pkcs12 -in certbundle.pem -export -out certkey.p12
-nocerts \ -nodes
Again, OpenSSL will ask you for an Export Password, just use the same as
in the previous step. Now you have your secret key ready for import into
GPGSM:
bash$ gpgsm --call-protect-tool --p12-import --store certkey.p12
3. Import the Issuers certificate and your own certificate
Now that you have imported your secret key successfully, you need to
import the issuers certificate, too. To obtain this certificate, you may
have to browse to the issuers website and download it, but Thawte for
example stores their certificate in the bundle you get when you request
the certificate. You can then extract it from the file certbundle.pem
you generated in the first step, simply with a text viewer. My preferred
way is to display the file in vi, then mark the issuer certificate with
the mouse and copy it into a shell, where before I typed in:
bash$ gpgsm --import
This will import the issuers certificate. Once you have successfully
completed this step, do the same with your own certificate.
If GPGSM did not spit out any error messages, you have now successfully
imported your freemail certificate and use your favourite,
Aegypten-enabled mailer to send and receive S/MIME messages with your
own certificates.
You can check with "gpgsm --list-secret-keys". If your freemail
certificate shows up, you're ready to go.
** Discussion
The following links intend to collect discussions around technological
decisions and plannings the Ägypten project is or will be involved in
one way or another.
*** KMail integration
The integeration of gpg-based S/MIME and OpenPGP support as part of the
Ägypten project involves a tough time line as well as a framework to
support other (non-KDE) MUAs.
It is intended to bring these two aspects in line with the KDE
development plans as good as possible. Essentially this means to reduce
those parts that will live only a short time to suffice the Ägypten
needs and that will be abandoned/substituted later on once the KDE
framework is further developed.
Some KDE activities in the same or related fields as Ägypten:
- [[http://lists.kde.org/?l=kmail&m=100456988004152&w=2][Ideas for
KMime design]] (in the kmail list archive)
- work is also going on on a
[[http://lists.kde.org/?l=kmail&m=100454574428861&w=2][kssl based
S/MIME "plugin"]] (in the kmail list archive)
*** Mutt integration
A special tar-ball of an Ägypten-enabled Mutt is available from the
ftp.gnupg.org site (see description above).
Apart from Ägypten, there is another
[[http://elmy.myip.org/mutt/smime.html][Mutt patch for S/MIME]]
available. This one is based on OpenSSL.
*** LDAP enabled KAddressbook
The LDAP functionality will allow the user to search for information by
typing (part of) a name in a textfield, the application will then query
the LDAP server and show the user a list of matches. The user can then
choose to add individual addresses to her local addressbook.
The addressbook application "KAddressbook" has been chosen to be
enhanced with LDAP functionality because it uses the most modern and
actively developed addressbook backend in KDE -- libkabc. The
development of the alternative libkab has officially been discontinued.
*** How to deal with certificates and LDAP
**** Background
An LDAP server can in principle have an smime-certificate attached to an
entry for a person. This entry usually also has the email address as
attribute. Important is that we can have several matching email
addresses for one person string or email address. To identify one
certificate we can use the fingerprint.
In principle the certificate should have the information that make it
possible to find the distribution point for the CRLs of the CA. Thus in
theory one would not have to speficy the DNS and port number of the ldap
server for the CLRs. So one would be fine once having a valid cert and
the trust path certs. In practice we might try ldap servers we have
tried for the certs too if in search for the CLR of a specific cert.
**** Kaddressbook's relation to Kmail
One design idea is that kaddressbook should not directly deal with
certificates, because it would then depend on gpgme for most of its
actions. Thus KAddressbook is only interested in the persons and their
email address attribute when quering an ldap server.
It just gives the email address and optional additional hints to KMail.
KMail then has to decide if it wants to use crypto and what crypto. If
KMail goes for s/mime encryption it has to care to find a certificate
for this email address. Now KMail (maybe in cooperation with the
certmanager) will call the crypto backend to search for a suitable
certificate. The cryptobackend will search external ldap-servers when
told so by KMail.
**** Why we need the fingerprint to be saved as hint in KAddressbook
From the background section it is clear that KMail might be presented
with a number of certificates for a single email address. This selection
would have to be done each time by the user, if we do not remember the
fingerprint of the prefered certificate. The right place to save this
hint is the KAddressbook as far as I can see it.
**** Drawback: Two lists of ldap Servers to query
There is a drawback that KAddressbook and dirmngr (which is the part of
the crypt backend actually asking the ldap servers) both have their list
of ldap servers to ask. Currently we think this is unavoidable if we
don't want to make things even more complicated. Theoretically we could
sync the KDE and crypto-backend preferences somehow, but this would
indeed make things more complicated.
All in all it seems that we need an GUI interface to the dirmngr list
separated from the KDE/KAddressbook ldap server configuration GUI.
**** Conclusion for implementation
We need a way for KMail or the certmanager to give hint data to
KAddressbook that KAddressbook can give back. Especially this hint data
should include "use smime" and "use the cert with this fingerprint:
xxx".
KMail or the certmanager has to the right search functions of gpgme if
it does not find a suitable certificate.
We need a configuration GUI to modify the dirmngr configuration for the
ldap servers to be searched for the certs.
*** Smartcards
**** Brief Intro
ICC or Smartcards are tiny (in todays terms) regular computers with an
OS using an EEPROM instead of a harddisk, with just one serial I/O, a
simple standardized command set and ACL protected files. Filenames are
16 bit values, you have diretories (called DFs) of up to 4 levels and
regular files (EFs) which may come in a transparent form, record
structured or circular structured. There are select read and write file
commands, commands to verify PINs, where the PIN is stored in a file on
the CARD with an ACL set to NO-READ. The cards required for Ägypten need
also have cryptograpic operations like encrypt, generate MAC, sign and
verify.
The chip is usually based on the 8051 but enhanced with a crypto
accelarator. If you detach the chip from the plastic card, you will
notice that the actual chip is on the backside of the golden contacts,
The contacts are used to supply the card with the power volatge, the
clock and the serial data.
**** SCdaemon
Reasons why SCdaemon:
- It is a module which can be used by independent applications, e.g.
programs that only like to see whether smart card is inserted or just
need to access the non-secret information.
- Bugs in this one don't progagate to gpg-agent. Strong encapsulation
due to the process barrier.
- There is no need to link X.509 code into gpg-agent. Only needed in
the SCdaemon -> less dependencies. This is the only module which
needs to be aware of the SC backend OpenSC. More stability of the
system; a crash here does not affect gpg-agent and gpg-agent can
restart the scdaemon.
- Easier maintenance and development.
**** User Interface for Smartcards
Some thoughts on the UI requirements for cards:
Preparation of cards (intitalization of the card's filesystem) should be
done by an external utility because we might need to display a lot of
error messages etc. A command line tool is more suitable for this.
Note that average users don't need this because they can purchase
suitable initialized cards. If there will be a need for a more user
friendly interface, someone else might setup such a project.
For storing the key on a card, a bootable OS is the desired solution.
But we should be able to do it within our environment after displaying
suitable warnings. To do this we need a checkbox (defaults to false) in
the key generation dialog. Everyting else is done by utilizing the
pinentry.
The most common interaction with SC happens after a user plugs in a
card. The SCdaemon might detect this but therefore it must have been
started already. So the better way is to tell gpgsm to look for a card -
KDE may provide a notifications service to start this program whenever
the state of a card readwer changes, but this not within the scope of
the Ägypten project.
In most cases gpg-agent/SCdaemon will notice that the card has already
been used and therefore the access to the card is transparent. However,
for new and unknown cards we need to ask the user what to do. To
separate this from the UI, we like to also use the pinentry. After a
user plugs in a card she won't be too surprised to see a pop up window,
asking some questions about the card ("Hey, this is a new card - what do
you want me to do with it?"). The user might answer, he does not know in
which case the dialog disapears but will pop up every time the card is
plugged in again. The other possible answer is "yes, I want to use a
secret key from this card" after which gpg-agent asks for the PIN to
verify that she is a legitimate user and registers the card in her
secret-key database on the disk.
If the use of a secret key is any time later needed, gpg-agent will look
through its secret key DB and use the key stored on the disk or (if
there is a flag that the key is on a SC) ask the user to insert the
appropriate card.
So the changes to the UI are really minimal by only requiring one
checkbox.
There is still the question open on howto un-regsiter a key from the DB
after it has expired or is not anymore accessible.
**** Smartcard access modules
The Ägypten project will use [[http://www.opensc.org/][OpenSC]] to
incorporate Smartcards. [[http://www.linuxnet.com/middle.html][PCSC Lite
of the MUSCLE project]] will be used to establish principle
functionality. Afterwards, PCSC lite will be replaced by a new
implementation. The primary reason is that the current license of PCSC
is not compliant with the Ägypten project goals for licenses (GPL). A
further advantage of OpenSC is the working pkcs-15 code and the clear
origin of the code.
An alternative for OpenSC was
[[http://www.franken.de/crypt/scez.html][SCEZ]], but here also the
license (old BSD with advertisement clause in current tar-balls) made us
prefer the LGPL licensed OpenSC. However, SCEZ the current development
version is now dual licensed under the new BSD and LGPL .
Links:
[[http://www.ioc.ee/atsc/faq.html][A Frequently Asked Questions list
(FAQ) for alt.technology.smartcards]] (outdated but still useful)
[[http://www.opensc.org/][OpenSC - SmartCard library with support for
PKCS#15 compatible cards]] (License: LGPL)
[[http://www.franken.de/crypt/scez.html][SCEZ - Smart Card Library]]
(License: old BSD)
[[http://www.linuxnet.com/middle.html][MUSCLE: Latest Stable PC/SC]]
[[http://smartsign.sourceforge.net/][Smartsign]] (GPL)
[[http://www.libchipcard.de/][Libchipcard]] (LGPL)
[[http://www.accu.org/bookreviews/public/reviews/s/s000027.htm][Smart
Card Handbook by W Rankl & W Effing (Book Review)]] This book s also
available in German by Hanser
([[http://www.hanser.de/weitere_infos/1999/3-446-21115-2.htm][Handbuch
der Chipkarten, 3. Auflage, ISBN 3-44621115-2]]).
** Other related projects and interesting stuff
[[http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt][X.509 Style
Guide]] by Peter Gutmann
[[http://www.getronicsgov.com/hot/sfl_home.htm][S/MIME Freeware Library
(SFL)]] (Free Software status not clear, partly GPL)
[[http://www.post1.com/home/ngps/m2/howto.smime.html][HOWTO: Programming
S/MIME in Python with M2Crypto]]
[[http://csrc.nist.gov/pki/testing/x509paths.html][X.509 Path Validation
Test Suite]] Conformance tests for relying parties that validate X.509
certification paths at the National Institute of Standards and
Technology.
[[%20http://www.direct-to-linux.com/TUTORIALS/LinuxTutorialLDAP.html][Linux
LDAP Tutorial: Deploying OpenLDAP - Directory Installation and
configuration (V1.2 / 2.0)]]
[[http://www.web2ldap.de/][WWW gateway to LDAP server]]
[[http://www.openssl.org][OpenSSL]] Contains a Free Software CA
implementation.
[[http://www.pyca.de/][pyCA - X.509 CA]] Software for running a
X.509/PKIX certificate authority (uses OpenSSL)
[[http://gpkcs11.sourceforge.net/][gpkcs11]] cryptographic token access
for Unix
[[http://cryp.to/librfc822/][RFC822 Address Parser Library]]
#+HTML:
diff --git a/web/aegypten/index.org b/web/aegypten/index.org
index f1d2d3e..a1a1fd8 100644
--- a/web/aegypten/index.org
+++ b/web/aegypten/index.org
@@ -1,140 +1,140 @@
#+TITLE: GnuPG - Project Ägypten - Clients
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
* Project Ägypten (Free Software Sphinx-Clients)
*Please note the successor: [[../aegypten2/index.html][Project Ägypten2]]:* Improving Free Software
Sphinx Clients
Home | [[file:tech.org][Technology]] | [[file:who.org][Who]] | [[file:time.org][Schedule]] | [[file:development.org][Development]] |
[[file:pr.org][Public Relations]] | [[file:glossary.org][Glossary]]
#+BEGIN_QUOTE
The Sphinx project launched by German authorities aims to improve
secure email exchange. The projects technological base is the protocol
'TeleTrust e.V. MailTrusT Version 2'. This includes the standards
S/MIME, X.509v3 and others.
Proprietary products are already on the way, but with the project
*Ägypten* there is now also a Free Software solution going to be
realized for popular mail user agents (sphinx-enabling *KMail* and
*Mutt* are essential goals).
The Free Software companies Intevation, g10 Code and Klarälvdalens
Datakonsult AB are contracted by the German 'Bundesamt für Sicherheit
in der Informationstechnik (BSI)' to incorporate the Sphinx protocols
into Free Software MUAs. Background is to ensure availability of
alternatives to proprietary desktops.
#+END_QUOTE
** Aims and Results
Within this project it is an explicit goal to produce sustainable
improvements for the free software desktop and no quickly assembled
code. The outcome of Ägypten consists of modular contributions to
existing projects (there will be no single Ägypten package). These work
together as an integrated solution for the users.
Rough list of aims and results:
- Plug-In for KMail and Mutt (established)
- LDAP support for Certificate Revocation Lists, CRLs (established)
- incorporation of sphinx protocols in gpg framework (established)
- X.509, PKCS10, PKCS11, PKCS12 and PKCS15 support (established)
- parallel support of OpenPGP for KMail (established)
- LDAP support for KMail address book (established)
- All finished by summer 2002, alpha-version for CeBIT 2002, Hannover
(official completion was on 27-November-2002)
Detailed list of results:
- All improvements and new modules are integrated into the
corresponding main developments (CVS HEAD) if not noted otherwise.
- *KMail*: All modifications to KMail (adding PGP/MIME and S/MIME
support) are officially available since KDE 3.1 release.
- *Mutt*: A modified version based on 1.5.0 is available as a special
package. Changes for a more flexible approach for different
crypto-backends has been integrated into Mutt CVS HEAD. Eventually,
the Ägypten patch may go into the CVS HEAD as well.
- *KAddressbook*: LDAP support is added and available since KDE 3.1.
- *KGpgCertmanager*: A new KDE application to manage the certificates
through a GUI. Available since KDE 3.1.
- *NewPG*: A new module that covers GpgSM (S/MIME encryption and
key-management) and SCDaemon (for Smartcard access). This module will
eventually be merged with GnuPG.
- *Pinentry*: A new module that contains various interfaces (qt, gtk,
curses, terminal) to enter a PIN/passphrase.
- *DirMngr*: A new module that handles the Certificate Revocation Lists
(CRLs).
- *GpgME*: Extended to handle GnuPG (OpenPGP) and GpgSM (S/MIME)
concurrently. Also a comprehensive documentation was written to
support sphinx-enabling further MUAs.
- *GnuPG*: Extended with GpgAgent that stores passphrases like
ssh-agent does (available since GnuPG 1.2.0 release).
- *cryptplug*: This new module is an optional interface layer between
GpgME and a MUA. It is used for KMail, Mutt is directly coupled with
GpgME.
** Links
- *[[../aegypten2/index.org][Ägypten2 Project]]*
- [[http://kmail.kde.org/][KMail]]
- [[http://www.mutt.org/][Mutt]]
- [[https://www.gnupg.org/][GnuPG]]
- [[http://www.bsi.de/aufgaben/projekte/sphinx/index.htm][Sphinx]]
- [[http://www.intevation.net][Intevation]]
- [[http://www.g10code.de][g10 Code]]
- [[http://www.klaralvdalens-datakonsult.se/][Klarälvdalens Datakonsult]]
- [[http://www.bsi.de][Bundesamt für Sicherheit in der Informationstechnik]]
** News
- 27-Aug-2013: Removed French and German pages as part of the
migration of www.gnupg.org to a new system.
- 31-Mar-2004: Linked Ägypten2 Project
- 29-Jan-2003: Finally KDE 3.1 is out. Ägypten features are
intergrated. Debian woody packages available.
- 23-Feb-2004: Updated developer infos, including KDE 3.2.
- 22-Aug-2002: Updated set of tarballs.
- 07-Oct-2002: Again new tarballs.
- 01-Aug-2002: Milestone 5 (external test) finished.
- 04-Jun-2002: French web pages updated.
- 15-May-2002: Updated set of tarballs including Sphinx-enabled
Mutt.
- 02-Apr-2002: Updated set of tarballs.
- 21-Mar-2002: Technology description updated.
- 13-20-Mar-2002: Ägypten in action at CeBIT Hall 11, Pav.D, Booth
10-12.
- 26-Feb-2002: First set of tarballs prepared.
- 31-Jan-2002: French web-pages contributed.
- 04-Jan-2002: Right before christmas: first Sphinx en- and
decryption via KMail works
- 27-Nov-2001: First functionalities implemented, see development
page
- 15-Nov-2001: New web-page: Glossary
- 26-Oct-2001: Web-pages: new: Public Relations, updated:
Technology
- 24-Oct-2001: Development: cvs and issue-tracker
- 11-Oct-2001: new web pages on technology, who is involved,
project schedule
- 1-Oct-2001: project start, initial webpage
** Contact
You can reach the project team on several mailing lists:
- - [[http://lists.gnupg.org/mailman/listinfo/gpa-dev][gpa-dev]] (technical coordination)
+ - [[https://lists.gnupg.org/mailman/listinfo/gpa-dev][gpa-dev]] (technical coordination)
- [[http://mail.kde.org/mailman/listinfo/kmail][kmail]] (KMail)
- - [[http://lists.gnupg.org/mailman/listinfo/gnupg-devel/][gnupg-devel]] (GnuPG development)
+ - [[https://lists.gnupg.org/mailman/listinfo/gnupg-devel/][gnupg-devel]] (GnuPG development)
Project coordination:
- [[mailto:bernhard@intevation.de][==]]
- [[mailto:jan@intevation.de][==]]
(C) Intevation, Verbatim copying and distribution of this entire page
is permitted in any medium, provided this notice is preserved.
#+HTML:
diff --git a/web/aegypten/tech.org b/web/aegypten/tech.org
index d3e2b7b..f5ef4d0 100644
--- a/web/aegypten/tech.org
+++ b/web/aegypten/tech.org
@@ -1,191 +1,191 @@
#+TITLE: GnuPG - Project Ägypten - Technology
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
* Project Ägypten: Technology
[[file:index.org][Home]] | Technology | [[file:who.org][Who]] | [[file:time.org][Schedule]] | [[file:development.org][Development]] |
[[file:pr.org][Public Relations]] | [[file:glossary.org][Glossary]]
-This page provides an overview. The CVS repository contains [[http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/aegypten-specs/?cvsroot=Project+Aegypten][technical
+This page provides an overview. The CVS repository contains [[https://cvs.gnupg.org/cgi-bin/viewcvs.cgi/aegypten-specs/?cvsroot%3DProject%2BAegypten][technical
details]]. Note that some of parts of this page have not been
translated from German.
[[file:images/module-overview.png]]
[[file:images/module-legend-1.png]] Strong connection: with two-way
communication accomplished by direct linking or KDE plug-in methods
[[file:images/module-legend-2.png]] Client/Server communication: Client (A)
requests a service from Service provider (B). This is either
accomplished by using Unix Domain sockets, shared memory or hardware
connection.
[[file:images/module-legend-kde.png]] KDE-dependent module
|
** Plug-In Container/Plug-Ins :de:
Die Plug-Ins für S/MIME und OpenPGP umfassen jeweils eine vereinfachte
API zur Durchführung der gewünschten Krypto-Funktionen. Für die Aufrufe
der Basis-API (mit GpgME bereitgestellt) werden die in den Plug-Ins
gehaltenen Konfigurationseinstellungen berücksichtigt (z.B. sende
komplette Zertifikatskette: ja/nein). Das jeweilige Mail-Programm stellt
alle Benutzerdialoge für diese Einstellungen zur Verfügung und
läd/speichert sie aus den für das jeweilige Mail-Programm spezifischen
Konfigurationsdateien.
Der Plug-In Container stellt die API der Plug-Ins innerhalb des
Mail-Programms zur Verfügung. Er ist spezifische für jedes Programm und
umfasst die Benutzerdialoge für Konfiguration.
** GpgSM
This module is responsible for encryption and key-management. It has
been designed and implemented according to GnuPG and offers among other
features a database for certificates. The format of this database can
also be used by GnuPG, so all public keys can be saved in a single file.
Private keys are not handled by GpgSM; it delegates the operations of
signing and decryption to the GpgAgent. When decrypting, this delegation
only concerns the decryption of the Session-Key; the symmetric
decryption however is done here. The module is capable of encrypting
data streams of arbitrary length. It offers a command line interface
widely corresponding to the interface of GnuPG.
GpgSM is also responsible for the generation of keys and related
messages. The key generation itself will be delegated as usual to the
GpgAgent, enabling it to save the private key directly in it's PSE.
Apart from the mandatory algorithms, AES will be also implemented.
Because it is not yet mentioned in the specification, it's use will be
made available by a certain option in the configuration.
** GpgAgent
This module takes over multiple tasks:
- It takes over all cryptographic operations requiering a private key.
- It manages both the Soft-PSEs and the Token PSE.
- It saves the fingerprint of the root certificate.
- It delegates operations to a krypto token, using the standards
PKCS11, PKCS12 and PKCS15.
- Optionally, it is capable of assuring the integrity of the system
(i.e. it's modules and certain keys). To assure this, it uses a MAC,
whose key is derived from a PIN.
- It offers functionality for both import and export of the private
keys.
- It generates new key-pairs.
For querying the PIN, the GpgAgent uses the PIN Entry-module. Special
measures to protect the sensitive information are implemented here (e.g.
to protect information from being swapped to the harddrive).
The design of this modules interface enables the module to be completely
implemented on a seperate hardware module.
** DirMngr
This module controls all directory accesses and performs search
operations. To accomplish this, it also uses OpenLDAP directly.
Certificate Revocation Lists (CRLs) are kept in a local cache by this
module and their validity is directly checked here. It is linked against
the hereby required libraries.
** PIN Entry
This is a very simple module, it only opens a modal dialog and asks for
the PIN. Using a special protocol, it cooperates directly with the
GpgAgent. This functionality is not built into the GpgAgent directly to
avoid linking against the complex GUI code. Furthermore, the module can
be adopted to existing graphical user interfaces easily.
Within the project the PIN Entry will be implemented as a qt-, gtk- and
text-version. Possibly an even simpler version using the basic grapical
user interface (X11) will be added in the future This would simplify
code-validation.
** Funktionsweise und Datenfluß :de:
*** Schlüsselerzeugung
Neue Schlüssel werden über das Konfigurationsmodul von KMail erzeugt,
welches hierzu GpgSM mit der Schlüsselerzeugung beauftragt. GpgSM gibt
dies an GpgAgent weiter, der die sicherheitskritischen Operationen
durchführt und den privaten Schlüssel in der PSE abstellt. Über einen
weiteren Dialog kann eine Zertifizierungsanfrage erstellt sowie weitere
Schlüsselverwaltungsfunktionen durchgeführt werden.
*** Signieren
Die zu signierende Nachricht (bzw. das MIME-Objekt) wird zusammen mit
der Identifikation des zur aktuellen Rolle gehörenden Zertifikats an
GpgSM gegeben, welches die Signatur berechnet. Da zur Erzeugung der
Signatur der private Schlüssel notwendig ist, wird die grundlegende
Signaturoperation nicht direkt von GpgSM durchgeführt sondern an
GpgAgent delegiert. Hierbei werden allerdings lediglich die absolut
notwendigen Parameter sowie der Hash der Nachricht weitergegeben
(optional kann auch der Hash von GpgAgent berechnet werden und die
Nachricht durch einen speziellen Viewer angezeigt werden; dies ist aber
nicht sinnvoll, solange GpgAgent nicht auf externer Hardware ausgeführt
wird).
GpgAgent wird in seiner PSE nach dem privaten Key suchen, eine PIN von
dem PIN-Entry Modul erfragen und dann die Signatur erzeugen. Der PKCS-1
Wert wird dann an GpgSM weitergegeben der dann die signierte Nachricht
aufbaut.
Nach Rückgabe an das MUA-Plug-in wird dieses entscheiden, ob die
Nachricht verschlüsselt werde soll und dies entsprechend dem oben
geschilderten Verfahren durchführen. Soll es nicht verschlüsselt werden,
so wird die signierte Nachricht direkt versendet, wobei je nach
Konfiguration Zertifikate mitgesendet werden.
*** Signaturprüfung
Der MUA-Plug-in zerteilt die Nachricht in ihre Bestandteile und gibt den
Plaintext sowie die Signatur zur Überprüfung an GpgSM weiter. Enthält
die Nachricht auch ein Zertifikat, so wird dieses vorher an GpgSM
gegeben, so daß es über das Zertifikat verfügen kann; ist kein
Zertifikat vorhanden, so wird GpgSM den DirMngr beauftragen die
entsprechenden Zertifikate zu besorgen. Hierzu wird der DirMngr auf das
LDAP-Service-Modul zurückgreifen. Nach erfolgreicher Signaturprüfung
wird GpgSM sich wiederum an den DirMngr wenden, um festzustellen, ob
eines der verwendeten Zertifikate in einer CRL vorkommt; sollte dies der
Fall sein, so wird dieser Status direkt im zu GpgSM gehörenden
Zertifikatspeicher vermerkt, um so weitere Signatur-Verifikationen
direkt scheitern zu lassen.
Der Signatur-Status sowie alle verfügbaren Metainformationen werden an
das MUA-Plug-in zurückgegeben, welches den Status der Signatur
entsprechend anzeigt.
*** Verschlüsselung
Das MUA Plug-in stellt anhand der Adressaten eine Liste von Zertifikaten
zusammen. Hierbei bedient es sich sowohl der internen Datenbank von
GpgSM als auch des DirMngr. Jedes ermittelte Zertifikat wird durch das
PKI Modul gegen die CRLs getestet und nur die gültigen Zertifikate
werden angezeigt. Dies erspart eine spätere Prüfung in GpgSM und eine
damit verbundene Rückweisung.
Es wird dafür gesorgt, dass alle notwendigen Zertifikate in der durch
GpgSM gepflegten Datenbank vorhanden sind. Die zu verschlüsselnde
Nachricht (bzw. das Attachment) wird zusammen mit den internen
Identifikationsnummern (fingerprints) der Zertifikate an GpgSM
weitergegeben, welches dann die Verschlüsselung vornimmt und das
verschlüsselte Objekt zurückgibt. Das neue Objekt wird nun wieder in
einen MIME Kontext eingebunden und versendet.
*** Entschlüsselung
Ist eine empfangene Nachricht verschlüsselt, so wird diese an GpgSM
weitergeleitet, die dann GpgAgent beauftragt den Session-Key zu
entschlüsseln. GpgAgent bedient sich hierzu entweder den eigenen
Funktionen und der Soft-PSE oder delegiert die Aufgabe an eine
Smartcard.
(C) Intevation, Verbatim copying and distribution of this entire page
is permitted in any medium, provided this notice is preserved.
#+HTML:
diff --git a/web/aegypten2/index.org b/web/aegypten2/index.org
index 57bbfbf..bba9c2e 100644
--- a/web/aegypten2/index.org
+++ b/web/aegypten2/index.org
@@ -1,212 +1,212 @@
#+TITLE: GnuPG - Project Ägypten2
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
* Project Ägypten2: Improving Free Software Sphinx-Clients
Ägypten2 is a successor project of Ägypten1, but with its own technical
aims, primarily addressing a better GUI and some more functionality such
as OCSP. The Ägypten2 project has the same structural and organisational
frame as Ägypten1, started December 1st 2003 and finished in
November 2004.
Please read the [[../aegypten/index.org][Ägypten1 Web-Pages]] to learn about the project that
initially estabslished the Sphinx (S/MIME) awareness of the MUAs
KMail and Mutt.
** Aims
The rough list of aims and their status (as of 13-January-2005) of
the Ägypten2 project are:
- Certificate Manager/Dirmngr
- GUI for PSE management (done)
- GUI for importating centrally created keys (done)
- Manual installation of CRLs (done)
- Check validity of all certifiactes (done)
- Visual distinction of certificate validity and usage (done)
- OCSP support (done)
- serial signatures based on the MIME structures (done)
- GUI for configuring LDAP servers (done)
- KMail
- Better support for handling keys with different key usages (done)
- GUI for specifying set and sequence of DN elements to show in
KMail (done)
- Detection of encrypted messages even if not correctly suffixed
".p7m" (done)
- Consistent and correct handling of drafts (done)
- Support of DINSIG Smartcards (DIN V66291-1:2000-04) (done)
- Extend Mutt to support S/MIME based on Ägypten crypto-backend
(done)
- Interoperability with other Sphinx-Applications (established)
- KDE GUI for watching GnuPG log (done)
- Complete German translation (almost done)
- Merge Ägypten developments into main development branches,
especially the KDE parts (done)
- Incorporate full functionality into Debian (in progress, only
GpgSM missing)
- Finish work in summer 2004 (well November was not too bad,
considering that the official Sphinx Interoperability Test
performed by Atos Origin took place in the last week of October).
** Module Overview
#+caption: [module diagram]
[[file:module-overview.png]]
** Users
Basically Ägypten2 is ready for use. The technology passed
interoperability tests with a number of leading other Sphinx
products (in fact most of them being proprietary Outlook
plugins). Of course, there could still be some remaining bugs.
If your are interested in the OpenPGP part, there is a HOWTO
provided by kde.org: [[http://kmail.kde.org/kmail-pgpmime-howto.html][Using OpenPGP and PGP/MIME with KMail >= 1.7]]
Most of the described stuff is also required for S/MIME.
Since the release of KDE 3.3 (and therewith KMail 1.7), all KDE
elements of Ägypten2 are available with the standard KDE 3.3 (or
newer) packages.
However, the various packages of Ägypten2 did not yet made it into
the usual GNU/Linux distributions.
Please report us if you find a distibution where Ägypten2
(especially the S/MIME part) works on your distribution out of the
box or at least most parts are available as packages.
*** Debian Sarge
Ägypten-2 funtionality is fully integrated in Debian 'Sarge' 3.1.
#+begin_example
apt-get install gnupg libgpg-error0 libgcrypt11 libgpgme11
apt-get install dirmngr
apt-get install pinentry-curses pinentry-gtk pinentry-qt
apt-get install gnupg2
#+end_example
In case you want to compiler newer versions than the Sarge ones
you might need some developer packages of which some are available
as packages:
apt-get install libgpg-error-dev libgcrypt11-dev libassuan-dev
libgpgme11-dev
KDE >= 3.3 is also available in Sarge:
apt-get install kmail kleopatra # the minimum you should install
apt-get install kaddressbook # to use contact specific crypto
preferences apt-get install kontact # to have various PIM
components integrated
** Developers
*** Subversion
First make sure you installed
- [[https://www.gnupg.org][GnuPG]] >= 1.2.5
- - [[https://www.gnupg.org/related_software/libgpg-error/][libgpg-error]]
+ - [[https://www.gnupg.org/software/libgpg-error/][libgpg-error]]
>= 1.0.0
- - [[http://directory.fsf.org/security/libgcrypt.html][libgcrypt]] >=
+ - [[https://directory.fsf.org/security/libgcrypt.html][libgcrypt]] >=
1.2.0
- - [[https://www.gnupg.org/related_software/gpgme/index.html][GpgME]]
+ - [[https://www.gnupg.org/software/gpgme/index.html][GpgME]]
>= 1.0.0
- [[http://www.kde.org][KDE]] >= 3.3.0
The full procedure is (you may apply short-cuts for some modules
e.g. via tar-balls. Note also that after installing libraries you
may have to issue ldconfig to have the newly installed libraries
be found by subsequent configure routines. Note finally that you
should read README.SVN if you find one):
1. Build libassuan
#+BEGIN_EXAMPLE
svn co svn://cvs.gnupg.org/libassuan/trunk libassuan
cd libassuan
./autogen.sh
./configure --prefix=/some/where --enable-maintainer-mode
make install
#+END_EXAMPLE
Alternatively you may use the latest tarball from
[[ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/][ftp.gnupg.org/gcrypt/alpha/libassuan/]] and do the usual
=./configure && make install=.
2. Build libksba
#+BEGIN_EXAMPLE
svn co svn://cvs.gnupg.org/libksba/trunk libksba
cd libksba
./autogen.sh
./configure --prefix=/some/where --enable-maintainer-mode
make install
#+END_EXAMPLE
Alternatively you may use the latest tarball from
[[ftp://ftp.gnupg.org/gcrypt/alpha/libksba/][ftp.gnupg.org/gcrypt/alpha/libksba/]]
and do the usual =./configure && make install=.
3. Build GnuPG 1.9 (make sure you build with thread support, or else
some operations may hang)
#+BEGIN_EXAMPLE
svn co svn://cvs.gnupg.org/gnupg/trunk gnupg
cd gnupg
./autogen.sh
./configure --prefix=/some/where --enable-maintainer-mode
make install
#+END_EXAMPLE
Alternatively you may use the latest tarball from
[[ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/][ftp.gnupg.org/gcrypt/alpha/gnupg/]]
(take the latest =gnupg-1.9.x=) and do the usual
=./configure && make install=.
4. Build DirMngr
#+BEGIN_EXAMPLE
svn co svn://cvs.gnupg.org/dirmngr/trunk dirmngr
cd dirmngr
./autogen.sh
./configure --prefix=/some/where --enable-maintainer-mode
make install
#+END_EXAMPLE
Alternatively you may use the latest tarball from
[[ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/][ftp.gnupg.org/gcrypt/alpha/dirmngr/]]
and do the usual =./configure && make install=.
5. Build pinentry module
#+BEGIN_EXAMPLE
svn co svn://cvs.gnupg.org/pinentry/trunk pinentry
cd pinentry
./autogen.sh
./configure --prefix=/some/where --enable-maintainer-mode
make install
#+END_EXAMPLE
Alternatively you may use the latest tarball from
[[ftp://ftp.gnupg.org/gcrypt/pinentry/][ftp.gnupg.org/gcrypt/pinentry/]]
and do the usual =./configure && make install=.
Page last modified: $Date: 2006-08-01 15:45:27 $
(C) Intevation, Verbatim copying and distribution of this entire page
is permitted in any medium, provided this notice is preserved.
#+HTML:
diff --git a/web/copying.org b/web/copying.org
index 3e83d1a..cb556c1 100644
--- a/web/copying.org
+++ b/web/copying.org
@@ -1,54 +1,54 @@
#+TITLE: GnuPG - Copying
#+STARTUP: showall
#+SETUPFILE: "share/setup.inc"
* Copying
#+index: Copying
Except when noted otherwise, these web pages are copyrighted by /The
GnuPG Project/. Given that such a legal entity does not exist, that
name should be considered a placeholder for the list of the actual
authors:
#+begin_verse
\copy 1998--2013 Werner Koch
\copy 2000--2002 Nils Ellmenreich
\copy 2001--2002 Mike Ashley
\copy 2002--2005 Lorenzo Cappelletti
\copy 2006--2006 David Shaw
#+end_verse
# The Aegypten pages are under a different license - there authors are
# \copy 2001--2004 Bernhard Reiter
# \copy 2001--2005 Jan-Oliver Wagner
You can redistribute these pages and/or modify them under the terms
of the
[[http://creativecommons.org/licenses/by-sa/3.0/][Creative Commons Attribution-ShareAlike 3.0 Unported License]]
or alternatively under the terms of the
[[http://www.gnu.org/licenses/][GNU General Public License]] as published by the Free Software
Foundation; either version 3 of the License, or (at your option)
any later version.
- If you wish to allow the use of your version of theses pages only
+ If you wish to allow the use of your version of these pages only
under the terms of one of these licenses, indicate your decision by
deleting the respective above paragraph.
** Remarks
For many years we maintained translation of these pages to French,
German, Italian, and Spanish. A big thank you to the translators:
Jean-Francois Paris, Walter Koch, Cristian Rigamonti, and Noel
David Torres Taño. Because we didn’t always managed to keep those
translation up to date, we decided in 2013 to abandon them. In
case translations are again demanded by users and sufficient
resources are available, the tentative plan is to setup individual
sites per language with language or country specific information.
Former version of these web pages have been marked as copyrighted
by the /Free Software Foundation/. However, a formal act to
transfer the copyright to them has never been conducted. Thus in
2013 these notices have been replaced by a reference to the list of
individual copyright holders.
diff --git a/web/devel/creating-a-release.org b/web/devel/creating-a-release.org
new file mode 100644
index 0000000..a974fdd
--- /dev/null
+++ b/web/devel/creating-a-release.org
@@ -0,0 +1,249 @@
+#+TITLE: GnuPG Hacking - Creating a Release
+#+STARTUP: showall indent
+#+SETUPFILE: "share/setup.inc"
+
+* Creating a Release
+
+This is a description of the steps necessary to build a software
+release of GnuPG and related software.
+
+
+** Overview of the Build System
+
+FIXME
+
+** Stuff required
+
+A Unix system, preferable Debian because that is what we use for our
+development.
+
+
+** Release Planning
+
+If you are planning a new release and strings have changed you should
+send a notification to all translators, so that they have time to
+update their translations. The script ~build-aux/mail-to-translators~
+in the gnupg-repo might be useful for this. You need to edit it to
+actually send out something.
+
+** Step by Step
+
+*** Make sure that all new PO files are checked in.
+
+*** Decide whether you want to update the automake standard files
+
+These are mainly the files ~config.guess~ and ~config.sub~. In
+general these files should be the same for all package. Do not update
+them for each release because having consistent files in all packages
+can avoid bug reports due to different cpu-vendor-os strings
+
+Commit these changes.
+
+*** Update the translation files
+
+Run:
+
+: make -C po update-po
+
+This merges the latest changes into the po files and disable entries
+which do not anymore match. The latter is important for example to
+avoid mismatches in printf format strings.
+
+You should then commit the changes using a subject of "po: Auto
+update".
+
+*** Update the LT version
+
+This affects only library packages. The libtool version (LT version)
+is updated only right before a release. The configure.ac file has
+comments on how to update them. Note that libraries which come with
+language bindings may have several independent LT version.
+
+FIXME: Describe why and how they are to be updated.
+
+*** Write NEWS entries
+
+Remember to set the release date in the NEWS file. For libraries it
+is suggested to note the LT version as well. Use the format
+"Cz/Ay/Rz" to give the Current/Age/Release numbers.
+
+*** Check README and doc files
+
+You may for example want to update the version information and make
+sure that they still have correct information. Files you should look
+at are for example:
+
+- README
+- AUTHORS
+- src/versioninfo.rc.in (Windows)
+
+*** Commit all changes with a subject of "Release m.n.o."
+
+This is the final commit which has all changes for the version.
+
+Do not push this commit.
+
+*** Create a signed tag with the name "foo-m.n.o".
+
+The git tag needs to be signed. We use hardware tokens to hold the
+signing key. The command to do this is
+
+: git tag -u KEYID foo-m.n.o
+
+You will be asked for a message. Put a funny message or better the
+main feature of this release into the commit log message.
+
+Do not push this tag.
+
+In case you need to restart the release process, you should first
+remove the tag (=git tag -d foo-m.n.o=) and then also revert the last
+commit.
+
+*** Recreate the configure script
+
+: ./autogen.sh --force
+
+The option =--force= is required for the git magic in configure.ac to
+work properly.
+
+This calls autoconf and automake and does some M4 magic to encode the
+the version number and information from Git into the new configure
+script. Note that the created =configure= script may not be tracked
+by Git.
+
+*** Build a release tarball
+
+This is easy:
+
+ : ./configure --enable-maintainer-mode
+
+ : make distcheck
+
+it is suggested to run the latter inside Emacs so that the compile log
+can be viewed for errors.
+
+FIXME: Explain why and how to use a VPATH build.
+
+*** Build and test the release
+
+This is best done on a different machine. Make sure to also build the
+Windows version so that you won't run into a surprise when building a
+Windows versions later.
+
+Keep a test build available for later.
+
+
+
+*** Sign the tarball
+
+Also store the created .swdb file away.
+
+*** Copy the tarball to a staging area
+
+*** Update the webpages
+
+At least the file swdb.mac needs an update. This is done using the
+saved swdb.
+
+*** Prepare for the next release
+
+ - Add a new headline to NEWS.
+
+ - Bump the version number in configure.ac up (Do not bump the LT
+ version, though)
+
+ - Commit with a subject "Post release updates" or similar.
+
+*** Push all changes
+
+Do not forget to push also the tags.
+
+In case you run into a conflict you need to start from scratch. That
+is removing the last two commits from your local copy, removing the
+tag, merge the changes, and to to the first step. Make sure that the
+version and LT version numbers are correct for the second try. To
+avoid this problem it is often better to work on a release branch and
+later merge the changes back to master.
+
+*** Copy the files from the staging area to the FTP server
+
+*** Update the online docs
+
+Using the final test build run a "make -C doc online".
+
+*** Write an announcement.
+
+
+** Notes on some packages
+
+Here are some gotchas for certain packages
+
+*** GnuPG
+
+- Check that https://savannah.gnu.org/projects/gnupg is up to date.
+ This is a simple page which merely points to gnupg.org, though.
+
+
+*** GnuPG Windows Installer
+
+To build a GnuPG >= 2.1 installer you need to change to a working
+directory, for example:
+
+: cd ~/b-w32/speedo
+
+then cleanup and unpack the GnuPG source:
+
+: rm -r PLAY PLAY-release
+: tar xjf /foo/bar/gnupg-m.n.o.tar.gz
+
+run a script which does about everything:
+
+: make -f gnupg-m.n.o/build-aux/speedo.mk w32-release
+
+finally you should sign the created installer using:
+
+: make -f gnupg-m.n.o/build-aux/speedo.mk w32-sign-installer
+
+and also sign them using your release key:
+
+: gpg -sbvu MYKEY gnupg-w32-m.n.o_YYYYMMDD.tar.xz
+: gpg -sbvu MYKEY gnupg-w32-m.n.o_YYYYMMDD.exe
+
+You will end up with these files:
+
+ - gnupg-w32-m.n.o_YYYYMMDD.tar.xz
+ - gnupg-w32-m.n.o_YYYYMMDD.tar.xz.sig
+ - gnupg-w32-m.n.o_YYYYMMDD.exe
+ - gnupg-w32-m.n.o_YYYYMMDD.exe.sig
+ - gnupg-w32-m.n.o_YYYYMMDD.exe.swdb
+
+Use the swdb file to update the swdb.mac and distribute tye other
+files (after testing).
+
+
+*** Libgcrypt
+
+*** GPGME
+
+- As of version 1.9 build problems in "make distcheck" for the Python
+ bindings may turn up. The workaround is to use a fresh build
+ directory.
+
+
+
+
+** Pitfalls
+
+Sometimes you may run into problems without seeing the actual
+problem. Here is a list of such things
+
+*** Permission problem moving "xx.new.po" to "xx.po"
+
+If during "make distcheck" you get an error about a permission problem
+moving foo.new.po to foo.po; this is caused by a check whether the po
+files can be re-created. Now if the first tarball has been created in
+a different top directory and if there exists a no distributed file
+with the string "GNU gnupg" (e.g. a log file from running make) you
+end up with different comments in the po files. Check out
+/usr/lib/gettext/project-id for that silliness. As a hack we added
+this string into configure.ac.
diff --git a/web/devel/index.org b/web/devel/index.org
new file mode 100644
index 0000000..d5c5121
--- /dev/null
+++ b/web/devel/index.org
@@ -0,0 +1,8 @@
+#+TITLE: GnuPG Hacking Resources
+#+STARTUP: showall indent
+#+SETUPFILE: "share/setup.inc"
+
+* Resources for Developers
+
+- [[https://www.gnupg.org/faq/HACKING.html][Coding guidelines]].
+- [[file:creating-a-release.org][How to create a release]].
diff --git a/web/documentation/bts.org b/web/documentation/bts.org
index 1db13dd..04d322d 100644
--- a/web/documentation/bts.org
+++ b/web/documentation/bts.org
@@ -1,21 +1,104 @@
#+TITLE: GnuPG - BTS
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
* Bug Tracking System
- Our bug tracking system can be found at [[https://bugs.gnupg.org/gnupg/index][bugs.gnupg.org]]. Please,
- query the database before you create a new bug report. You need to
- create an account to file a bug or edit existing bugs. See the
- [[https://bugs.gnupg.org/index.html#intro][Introduction to the BTS]]. Bug reports need to be written in English
+ Our bug tracking system can be found at [[https://dev.gnupg.org][dev.gnupg.org]]. Please,
+ query the database before you create a new bug report (aka /Task/).
+ See below for some more information. Bug reports need to be written
+ in English.
If you can fix one of these bugs/limitations, we will certainly be
- glad to receive a patch via the gnupg-devel mailing list. If the
- patch is non-trivial please read the file [[https://www.gnupg.org/faq/HACKING.html][doc/HACKING]] first.
+ glad to receive a patch via the above platform or the gnupg-devel
+ mailing list. If the patch is non-trivial please read our
+ [[https://www.gnupg.org/faq/HACKING.html][coding guidelines]] first.
+ Our bug tracker can also be used to report problems related to this
+ GnuPG.org site. Simply, follow the instructions for a regular bug
+ and add the tag /gpgweb/.
-** GnuPG.org
- The *Bug Tracking System* can also be used to report problems
- related to GnuPG.org site. Simply, follow the instructions given
- above and set the "category" field to *gpgweb*.
+** Hints on how to add a new bug
+
+ Please note that this bug tracker is a public resource and
+ everything you enter there will be available for the whole
+ networked world. It is similar to a public mailing list and there
+ is no easy way to retract any information.
+
+ You should follow these steps to enter a new bug (issue):
+
+ - Review the documentation and the mailing list archives to see
+ whether your problem has already been addressed. Often bugs are
+ mere configuration problems.
+
+ - Check that the bug has not yet been entered and that there is no
+ similar bug in the tracker. Use the search option for this. It
+ is best to also look through already closed (resolved )
+ issues.
+
+ - If you consider the bug a severe security problem and you do not
+ want to publish it, please write to security 'at' gnupg.org to
+ ask for advice and our encryption keys. See also the AUTHORS
+ file in each package.
+
+ - In the left sidebar select /Tasks/ and then click on /+ Create
+ Task/ which you find in the upper right corner. On our
+ development platform a /Task/ is a synonym for a /bug/.
+
+ - Come up with a meaningful short description of the bug and enter
+ this into the /Title/ field.
+
+ - If you want to want to ask for a new feature or have another
+ wish, please indicate the in the /Priority/ field. Bug should in
+ general be left at the default priority of /Needs Triage/ and you
+ should not assign the bug to anyone if you want to get it fixed
+ soon.
+
+ - Now for the most important field: The Description of the problem.
+ You enter this information into the, surprise, /Description/ field.
+ Please take care to use hard line breaks and format the report as
+ you would do by mail.\\
+ \nbsp{}\\
+ Make sure that you describe the bug as good as possible and try
+ to come up with a minimal recipe on how to replicate the bug. We
+ need to know the version of the software and if you are using a
+ non-released version the Git commit id. Use the separate field
+ /Version/ at the bottom of the page for this. The type and
+ version of your operating system is usually important, so please
+ tell us. In particular tell us if your problem occurs on a
+ non-Unix system, i.e. MS Windows.
+
+ - If you want to provide more information, you may upload any kind
+ of file using the menu at the top of the /Description/ field.
+ However, please do this only if you are sure that these
+ information are important and that they do not contain
+ confidential data. Uploaded files will be public and it might
+ not be possible to retract them anymore. Avoid screen shots
+ unless you are asked for them. The problem with screen shots or,
+ worse, screen casts is that we would need to transcript them to
+ text for evaluating the problem. That takes away time we better
+ spend solving the problem; it is easy to help us by providing a
+ transcription.
+
+ - You may optionally assign one or more /Tags/ to a report. The
+ package name is a good guess ("gnupg", "libgcrypt", etc.). If
+ you know that the bug is Microsoft Windows specific, please enter
+ add the tag "w32". You do not need to do it if you already
+ specified Windows specific package (like "gpgol"). For macOS
+ specific bugs, use "MacOS".
+
+ - Please be kind and do _not_ assign a /Due Date/. We will later
+ evaluate the importance of bugs in the light of other open bugs.
+
+ - If you want to refer to an external bug description (for example
+ a similar entry in Debian's bug tracker), enter the URL into the
+ /External Link/ field.
+
+ - The /Version/ field should be filled as described above. If you
+ don't know the version leave it blank and describe what you know
+ about the software in the /Description/ field.
+
+ - If everything is as you want it, click the /Create New Task/
+ button. This entry as well as all future changes will also be
+ mailed to you.
diff --git a/web/documentation/faqs.org b/web/documentation/faqs.org
index fd7aa15..a4ed6ee 100644
--- a/web/documentation/faqs.org
+++ b/web/documentation/faqs.org
@@ -1,15 +1,15 @@
#+TITLE: GnuPG - FAQ
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
* GnuPG Frequently Asked Questions
The GnuPG FAQ is available in 2 formats:
- [[https://www.gnupg.org/faq/gnupg-faq.html][HTML]]
- [[https://www.gnupg.org/faq/gnupg-faq.txt][Plain text]]
- The FAQ is generated using this [[http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=blob_plain;f=web/faq/gnupg-faq.org][source code]]. If you are looking for
- the old and outdated FAQ, please go to [[ftp://ftp.gnupg.org/gcrypt/gnupg/GnuPG-FAQ.old.txt][here]].
+ The FAQ is generated using this [[https://git.gnupg.org/cgi-bin/gitweb.cgi?p%3Dgnupg-doc.git%3Ba%3Dblob_plain%3Bf%3Dweb/faq/gnupg-faq.org][source code]]. If you are looking for
+ the old and outdated FAQ, please go to [[https://www.gnupg.org/ftp/gcrypt/gnupg/GnuPG-FAQ.old.txt][here]].
# eof
diff --git a/web/documentation/guides.org b/web/documentation/guides.org
index 9f59d04..2a08842 100644
--- a/web/documentation/guides.org
+++ b/web/documentation/guides.org
@@ -1,91 +1,91 @@
#+TITLE: GnuPG - User guides
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
* User guides
This page collects documents available as user guides for GnuPG.
** The GNU Privacy Handbook
# <>
Thanks to the DocBook system, [[mailto:jashley@acm.org][John Michael Ashley]]’s /The GNU
Privacy Handbook/ (GPH for short) is available in several formats:
- as on-line browsable [[../../gph/en/manual.html][HTML]] file (
[[../../gph/de/manual/index.html][de]] ·
[[../../gph/en/manual.html][en]] ·
[[../../gph/es/manual.html][es]] ·
[[../../gph/fr/manual.html][fr]] ·
[[../../gph/it/index.html][it]] ·
[[http://www.inar.ru/~zwon/gph/index.xhtml][ru]] )
- as [[../../gph/en/manual.pdf][PDF]] (
[[../../gph/de/manual.pdf][de]] ·
[[../../gph/en/manual.pdf][en]] ·
[[../../gph/es/manual.pdf][es]] ·
[[../../gph/fr/manual.pdf][fr]] ·
[[../../gph/it/manual.pdf][it]] )
- in postscript format ( [[../../gph/de/manual.ps.gz][de]] )
- as [[../../gph/en/gph.tar.gz][SGML]] gzipped tarball (
[[../../gph/en/gph.tar.gz][en]] ·
[[../../gph/es/gph.tar.gz][es]] ·
[[../../gph/es/gph.tar.gz][fr]] ·
[[../../gph/it/gph.tar.gz][it]] ·
[[http://www.inar.ru/~zwon/gph.tar.gz][ru]] )
- GPH is also available in the [[../download/cvs_access.org][source repository]].
+ GPH is also available in the [[../download/git.org][source repository]].
** Replacing PGP 2.x with GnuPG
This document demonstrates some of GnuPG's features by showing how
GnuPG can be used to communicate with PGP 2.x users.
Because it has been written in DocBook, the document is available
in the following formats:
- as on-line browsable [[../../gph/en/pgp2x.html][HTML]] file (
[[../../gph/en/pgp2x.html][en]] ·
[[../../gph/es/pgp2x.html][es]] )
- as [[../../gph/en/pgp2x.pdf][PDF]] (
[[../../gph/en/pgp2x.pdf][en]] ·
[[../../gph/es/pgp2x.pdf][es]] )
- as [[../../gph/en/pgp2x.sgml][SGML]] (
[[../../gph/en/pgp2x.sgml][en]] ·
[[../../gph/es/pgp2x.sgml][es]] )
** A Practical Introduction to GPG in Windows
This guide, written by Brendan Kidwell, shows you how to use the
free public key cryptography system GnuPG from a Windows user
perspective. It started life as an outline for a talk Brendan was
going to give in his Cryptology class, but it quickly grew into a
document that stands on its own.
The document is available in several formats which can be read
on-line or downloaded from [[http://www.glump.net/content/gpg_intro/][Brendan’s page]].
Let us hope that this guide will help out Windows users who are
dying to effectively install and use GnuPG on their systems. So
that, nobody will never ever say that "/after reading the whole of
www.gnupg.org I still couldn't get the thing to work/" ;-)
** Man page
The online [[file:manpage.org][man page]], available in English, is likely a little bit
outdated.
** Other documents
The [[https://emailselfdefense.fsf.org/][Email Self-Defense]] site is an introduction with infographic.
Documentation in the [[http://gnupg.hclippr.com/][Japanese]] language.
Julien Francoz, alias CoCoZ, wrote a guide for French users
entitled [[http://francoz.net/doc/gpg/gpg.html][Utilisation de GnuPG]] , which covers the basic usage of
GnuPG. The document is also available in [[http://francoz.net/doc/gpg/gpg-latest.sgml][SGML format]] .
Mario Pascucci wrote an guide for Italian users entitled
[[http://www.ismprofessional.net/pascucci/index.php/2007/04/crittografia-riservatezza-e-sicurezza/][GnuPG: Crittografia, Privacy e Open Source]]. It covers the use of
GnuPG on the GNU/Linux command line as well as its use on Windows
along with WinPT.
diff --git a/web/documentation/howtos.org b/web/documentation/howtos.org
index d3e98b3..5be52f8 100644
--- a/web/documentation/howtos.org
+++ b/web/documentation/howtos.org
@@ -1,105 +1,105 @@
#+TITLE: GnuPG - HOWTOs
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
* HOWTOs
There are several HOWTOs available.
** GnuPG MiniHOWTO
You may get the best overview about the GnuPG system by reading the
mini HOWTO available in several formats:
- as on-line browsable HTML files (
[[../howtos/ca/GPGMiniHowto.html][ca]] ·
[[../howtos/de/index.html][de]] ·
[[http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto.html][en]] ·
[[http://www.dewinter.com/gnupg_howto/spanish/index.html][es]] ·
[[../howtos/fr/index.html][fr]] ·
[[../howtos/it/GPGMiniHowto.html][it]] ·
[[../howtos/tr/GPGMinikNasil.html][tr]] ·
- [[../howtos/vn/index.html][vn]] .
+ [[../howtos/vn/index.htm][vn]] ·
[[../howtos/zh/index.html][zh]] )
- as one big HTML file (
[[../howtos/ca/GPGMiniHowto_big.html][ca]] ·
[[../howtos/it/GPGMiniHowto_big.html][it]] )
- as PDF (
[[../howtos/ca/GPGMiniHowto.pdf][ca]] ·
[[../howtos/de/GPGMiniHowto.pdf][de]] ·
[[../howtos/it/GPGMiniHowto.pdf][it]] ·
[[../howtos/vn/GPGMiniHowto.pdf][vn]] )
- in postscript format (
[[../howtos/ca/GPGMiniHowto.ps][ca]] ·
[[http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto.ps][en]] ·
[[../howtos/de/GPGMiniHowto.ps][de]] )
- as DVI file ( [[../howtos/ca/GPGMiniHowto.dvi][ca]] )
- in RTF format ( [[../howtos/ca/GPGMiniHowto.rtf][ca]] )
- as plain text (
[[../howtos/ca/GPGMiniHowto.txt][ca]] ·
[[http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto.txt][en]] ·
[[../howtos/it/GPGMiniHowto.txt][it]] )
- as SGML (
[[../howtos/ca/GPGMiniHowto.sgml][ca]] ·
[[../howtos/de/GPGMiniHowto.sgml][de]] ·
[[http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto.sgml][en]] ·
[[../howtos/it/GPGMiniHowto.sgml][it]] ·
[[../howtos/tr/GPGMinikNasil.sgml.gz][tr]] )
- as gzipped tarball of them all ( [[../howtos/ca/GPGMiniHowto.tar.gz][ca]] )
** GnuPG SmartcardHOWTO
GnuPG supports the use of smartcards. This HOWTO explains how to
install and work with these cards.
- as on-line browsable HTML files ( [[../howtos/card-howto/en/smartcard-howto.html][en]] )
- as one big HTML file ( [[../howtos/card-howto/en/smartcard-howto-single.html][en]] )
- as plain text ( [[../howtos/card-howto/en/smartcard-howto.txt][en]] )
- This smartcard howto is also available in the [[../download/cvs_access.org][source repository]].
+ This smartcard howto is also available in the [[../download/git.org][source repository]].
** GnuPG Keysigning Party HOWTO
Once you get familiar with GnuPG's mechanisms, you surely wouldn't
miss one of its funnest (and useful) aspects: to meet your Internet
buddies and get your key signed by as many of them as possible.
But having to check tens or even hundreds of keys at a meeting may
become quite frustrating. Here it is where this HOWTO by V. Alex
Brennen comes in handy. It is a guide to understanding and
organizing a PGP keysigning party. Keysigning parties help build
and strengthen the web of trust which serves to make the use of
GnuPG more secure.
This HOWTO is available:
- as an on-line browsable set of HTML files (
[[http://www.cryptnet.net/fdp/crypto/gpg-party/gpg-party.de.html][de]] ·
[[http://www.cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html][en]] ·
[[../howtos/es/gpg-party.html][es]] ·
[[../howtos/it/keysigning_party.html][it]] ·
[[http://www.cypherpunks.ru/KSP.html][ru]] ·
[[http://www.cryptnet.net/fdp/crypto/gpg-party/gpg-party.si.html][si]] ·
[[http://www.cryptnet.net/fdp/crypto/gpg-party/gpg-party.zh-TW.html.big5][zh-TW.big5]] ·
[[http://www.cryptnet.net/fdp/crypto/gpg-party/gpg-party.zh-TW.html.euc-tw][zh-TW.euc-tw]] )
** Mutt-GnuPG HOWTO
Firstly, because everyone should be using encryption and signatures
in their email. Secondly, because there are absolutely no reason
for you not to be using PGP-compatible software. Thirdly, because
documentation is mostly geared toward someone who is already
familiar with PGP. Fourtly, because we like to promote both GnuPG
and Mutt as free software project, for use in everyday
communications. Lastly, because Justin R. Miller likes writing
tutorials.
For all these reasons, you can find below a link to Justin's HOWTO
on how to send and receive cryptographically signed and/or
encrypted email with GnuPG and the [[http://www.mutt.org/][Mutt mail reader]].
This HOWTO is available:
- as plain text ( [[http://codesorcery.net/old/mutt/][en]] )
diff --git a/web/documentation/index.org b/web/documentation/index.org
index 66ff139..07a5f9f 100644
--- a/web/documentation/index.org
+++ b/web/documentation/index.org
@@ -1,30 +1,40 @@
-#+TITLE: GnuPG - Documentation
+#+TITLE: GnuPG - Support
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
-* Documentation Sources
+* Documentation
- [[file:howtos.org][HOWTOs]] :: Includes links to some HOWTOs available in several
languages to get out the best from GnuPG.
- [[file:manuals.org][Manuals]] :: A list of online available manuals which are also
provided with the software.
- [[file:guides.org][User Guides]] :: Draft versions of the user manual are available,
and there is also documentation covering
- interoperation with PGP 2.x. In addition we have a
- [[file:manpage.org][man page online]] and John Michael Ashley's /The GNU
+ interoperation with PGP 2.x. In addition, the software comes with man
+ pages, and we have John Michael Ashley's /The GNU
Privacy Handbook/ (GPH).
- [[file:faqs.org][FAQs]] :: Online version of the FAQs is now available. Please
consult these FAQs before you ask on one of the mailing
lists or report a bug.
+
+ - [[file:security.org][Security]] :: How to report security problems.
+
+ You may also notice that OpenPGP is a proposed Internet standard,
+ described by [[https://www.rfc-editor.org/rfc/rfc4880.txt][RFC-4880]].
+
+* Community support
+
- [[file:mailing-lists.org][Mailing lists]] :: Describes the purposes of each mailing list
hosted on this server and gives instruction on
how to subscribe. Links to other GnuPG-related
discussion groups are also available.
- [[https://wiki.gnupg.org][Wiki]] :: The official GnuPG Wiki contains community-maintained
documentation for GnuPG and related software.
- [[file:bts.org][BTS]] :: Before you report a bug, please consult the list of bugs.
- - [[http://twitter.com/gnupg][@gnupg]] :: We sometimes post short messages to Twitter.
+* Other types of support
- You may also notice that OpenPGP is a proposed Internet standard,
- described by RFC4880 (found at [[http://www.rfc-editor.org/][RFC Editor]]).
+ - [[../service.org][Commercial support]] :: Listing of companies offering commercial
+ support for GnuPG
+
+ - [[http://twitter.com/gnupg][@gnupg]] :: We sometimes post short messages to Twitter.
diff --git a/web/documentation/mailing-lists.org b/web/documentation/mailing-lists.org
index 04e529c..b91079e 100644
--- a/web/documentation/mailing-lists.org
+++ b/web/documentation/mailing-lists.org
@@ -1,79 +1,81 @@
#+TITLE: GnuPG - Mailing lists
#+STARTUP: showall indent
#+SETUPFILE: "../share/setup.inc"
#+OPTIONS: ^:{}
* Mailing lists
The contents of all messages sent to these mailing lists are assumed
to be in the public domain. Archives of these mailing lists are also
available; please click on the mailing list name below.
Please check the [[file:faqs.org][FAQ]] before you ask on one of the lists. If you want
to search these mailing lists (as well as other archives) please use
-the service provided at [[http://marc.info/]].
+the service provided at [[http://marc.info/]]. If you do not want to
+write to a public mailing list, check out the [[../service.org][commercial support]]
+options.
| Name | Purpose | Lang |
|----------------+---------------------------------------------+------|
| | | |
-| [[http://lists.gnupg.org/pipermail/gnupg-announce/][gnupg-announce]] | Release announcements (low-traffic) | en |
+| [[https://lists.gnupg.org/pipermail/gnupg-announce/][gnupg-announce]] | Release announcements (low-traffic) | en |
| | | |
-| [[http://lists.gnupg.org/pipermail/gnupg-users/][gnupg-users]] | General discussion and help | en |
-| [[http://lists.gnupg.org/pipermail/gnupg-br/][gnupg-br]] | Help among Portuguese/Brazil speaking users | br |
-| [[http://lists.gnupg.org/pipermail/gnupg-de/][gnupg-de]] | Help among German speaking users | de |
-| [[http://lists.gnupg.org/pipermail/gnupg-pt/][gnupg-pt]] | Help among Portuguese speaking users | pt |
-| [[http://lists.gnupg.org/pipermail/gnupg-es/][gnupg-es]] | Help among Spanish speaking users | es |
-| [[http://lists.gnupg.org/pipermail/gnupg-ru/][gnupg-ru]] | Help among Russian speaking users | ru |
+| [[https://lists.gnupg.org/pipermail/gnupg-users/][gnupg-users]] | General discussion and help | en |
+| [[https://lists.gnupg.org/pipermail/gnupg-br/][gnupg-br]] | Help among Portuguese/Brazil speaking users | br |
+| [[https://lists.gnupg.org/pipermail/gnupg-de/][gnupg-de]] | Help among German speaking users | de |
+| [[https://lists.gnupg.org/pipermail/gnupg-pt/][gnupg-pt]] | Help among Portuguese speaking users | pt |
+| [[https://lists.gnupg.org/pipermail/gnupg-es/][gnupg-es]] | Help among Spanish speaking users | es |
+| [[https://lists.gnupg.org/pipermail/gnupg-ru/][gnupg-ru]] | Help among Russian speaking users | ru |
| | | |
-| [[http://lists.gnupg.org/pipermail/gnupg-devel/][gnupg-devel]] | Development discussion and bug tracking | en |
-| [[http://lists.gnupg.org/pipermail/gcrypt-devel/][gcrypt-devel]] | Development of Libgcrypt | en |
-| [[http://lists.gnupg.org/pipermail/gnupg-doc/][gnupg-doc]] | Development of documentation | en |
-| [[http://lists.gnupg.org/pipermail/gnupg-commits/][gnupg-commits]] | Commit messages (read-only) | en |
+| [[https://lists.gnupg.org/pipermail/gnupg-devel/][gnupg-devel]] | Development discussion and bug tracking | en |
+| [[https://lists.gnupg.org/pipermail/gcrypt-devel/][gcrypt-devel]] | Development of Libgcrypt | en |
+| [[https://lists.gnupg.org/pipermail/gnupg-doc/][gnupg-doc]] | Development of documentation | en |
+| [[https://lists.gnupg.org/pipermail/gnupg-commits/][gnupg-commits]] | Commit messages (read-only) | en |
| | | |
|----------------+---------------------------------------------+------|
A complete list of all mailing lists can also be found at our
-[[http://lists.gnupg.org/mailman/listinfo/][mailing list manager]].
+[[https://lists.gnupg.org/mailman/listinfo/][mailing list manager]].
-You may subscribe to these lists [[http://lists.gnupg.org/][via web]] or by sending an e-mail:
+You may subscribe to these lists [[https://lists.gnupg.org/][via web]] or by sending an e-mail:
#+begin_example
To: -request@gnupg.org
Subject: subscribe
#+end_example
where // is the name of the mailing list as described
above.
Posting to these mailing lists is only allowed for subscribers;
postings from non-subscribers are held for approval but there is no
guarantee that the moderator can approve them in time; they may even
be dropped.
Some kinds of postings will not be accepted: e.g. large ones, mails
without the list name in the =To:= or =CC:= header and HTML mails.
All mail clients have an option to send plain text only messages; try
this if you don’t get a response.
Please write to the mailing lists in English unless it is language
specific list.
** Other discussion groups
There are also several other country-specific mailing-lists to
subscribe to. It is important to note that these mailing-lists are
not hosted on the GnuPG servers, but are of great help for all of
those who feel more confortable when speaking their own native
language.
- [[http://www.egroups.co.jp/group/gnupgnewsjapan/][GnuPG News Japan]] :: Discussion group for Japanese users.
- [[http://itlists.org/mailman/listinfo/gnupg-it/][gnupg-it]] :: Mailing list dedicated to GnuPG users who speak Italian.
* IRC and Jabber
The channel =#gnupg= on =irc.freenode.org= is a place to talk about
all gnupg related topics.
The core GnuPG developers use the MUC =gnupg-devel= at conference dot
jabber dot gnupg.org for their day to day work. Visitors are welcome.
diff --git a/web/documentation/manpage.org b/web/documentation/manpage.org
index f50db6b..de5dcab 100644
--- a/web/documentation/manpage.org
+++ b/web/documentation/manpage.org
@@ -1,789 +1,795 @@
#+TITLE: GnuPG - gpg man page
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
#+OPTIONS: -:nil
+* Old Man Page
+
+This is a very old version of the gpg man page. Please see the latest
+release or software package for your operating system to find an up to
+date version ("man gpg2").
+
* gpg
** Name
gpg -- encryption and signing tool
** Synopsis
#+BEGIN_EXAMPLE
gpg
[--homedir name]
[--options file]
[options]
command
[args]
#+END_EXAMPLE
** DESCRIPTION
*gpg* is the main program for the GnuPG system.
This man page does only list the commands and options available. For a
more verbose documentation get the GNU Privacy Handbook (GPH), which is
available at https://www.gnupg.org/gph/ . You will find a list of HOWTO
documents at https://www.gnupg.org/docs.html .
** COMMANDS
*gpg* recognizes these commands:
- -s, --sign :: Make a signature. This command may be combined with
--encrypt.
- --clearsign :: Make a clear text signature.
- -b, --detach-sign :: Make a detached signature.
- -e, --encrypt :: Encrypt data. This option may be combined with
--sign.
- -c, --symmetric :: Encrypt with symmetric cipher only This command
asks for a passphrase.
- --store :: Store only (make a simple RFC1991 packet).
- --decrypt [ =file= ] :: Decrypt =file= (or stdin if no file is
specified) and write it to stdout (or the file specified with
--output). If the decrypted file is signed, the signature is also
verified. This command differs from the default operation, as it
never writes to the filename which is included in the file and it
rejects files which don't begin with an encrypted message.
- --verify [[ =sigfile= ] [ =signed-files= ]] :: Assume that =sigfile= is a
signature and verify it without generating any output. With no
arguments, the signature packet is read from stdin (it may be a
detached signature when not used in batch mode). If only a sigfile is
given, it may be a complete signature or a detached signature, in
which case the signed stuff is expected in a file without the ".sig"
or ".asc" extension (if such a file does not exist it is expected at
stdin; use a single dash ("-") as filename to force a read from
stdin). With more than 1 argument, the first should be a detached
signature and the remaining files are the signed stuff.
- --verify-files [ =files= ] :: This is a special version of the --verify
command which does not work with detached signatures. The command
expects the files to bee verified either on the commandline or reads
the filenames from stdin; each anem muts be on separate line. The
command is intended for quick checking of many files.
- --list-keys [ =names= ], --list-public-keys [ =names= ] :: List all keys
from the public keyrings, or just the ones given on the command line.
- --list-secret-keys [ =names= ] :: List all keys from the secret
keyrings, or just the ones given on the command line.
- --list-sigs [ =names= ] :: Same as --list-keys, but the signatures are
listed too.
- --check-sigs [ =names= ] :: Same as --list-sigs, but the signatures are
verified.
- --fingerprint [ =names= ] :: List all keys with their fingerprints.
This is the same output as --list-keys but with the additional output
of a line with the fingerprint. May also be combined with --list-sigs
or --check-sigs. If this command is given twice, the fingerprints of
all secondary keys are listed too.
- --list-packets :: List only the sequence of packets. This is mainly
useful for debugging.
- --gen-key :: Generate a new key pair. This command is normally only
used interactive.
There is an experimental feature which allows to create keys in batch
mode. See the file =doc/DETAILS= in the source distribution on how to
use this.
- --edit-key =name= :: Present a menu which enables you to do all key
related tasks:
- sign :: Make a signature on key of user =name= If the key is not
yet signed by the default user (or the users given with -u), the
program displays the information of the key again, together with
its fingerprint and asks whether it should be signed. This
question is repeated for all users specified with -u.
- lsign :: Same as --sign but the signature is marked as
non-exportable and will therefore never be used by others. This
may be used to make keys valid only in the local environment.
- revsig :: Revoke a signature. GnuPG asks for every signature which
has been done by one of the secret keys, whether a revocation
certificate should be generated.
- trust :: Change the owner trust value. This updates the trust-db
immediately and no save is required.
- disable, enable :: Disable or enable an entire key. A disabled key
can normally not be used for encryption.
- adduid :: Create an alternate user id.
- deluid :: Delete an user id.
- addkey :: Add a subkey to this key.
- delkey :: Remove a subkey.
- revkey :: Revoke a subkey.
- expire :: Change the key expiration time. If a key is selected,
the time of this key will be changed. With no selection the key
expiration of the primary key is changed.
- passwd :: Change the passphrase of the secret key.
- uid =n= :: Toggle selection of user id with index =n=. Use 0 to
deselect all.
- key =n= :: Toggle selection of subkey with index =n=. Use 0 to
deselect all.
- check :: Check all selected user ids.
- pref :: List preferences.
- toggle :: Toggle between public and secret key listing.
- save :: Save all changes to the key rings and quit.
- quit :: Quit the program without updating the key rings.
The listing shows you the key with its secondary keys and all user
ids. Selected keys or user ids are indicated by an asterisk. The
trust value is displayed with the primary key: the first is the
assigned owner trust and the second is the calculated trust value.
Letters are used for the values:
- - :: No ownertrust assigned / not yet calculated.
- e :: Trust calculation has failed.
- q :: Not enough information for calculation.
- n :: Never trust this key.
- m :: Marginally trusted.
- f :: Fully trusted.
- u :: Ultimately trusted.
- --sign-key =name= :: Sign a public key with you secret key. This is a
shortcut version of the subcommand "sign" from --edit.
- --lsign-key =name= :: Sign a public key with you secret key but mark
it as non-exportable. This is a shortcut version of the subcommand
"lsign" from --edit.
- --trusted-key =long key ID= :: Assume that the specified key (which
must be given as a full 8 byte key ID) is as trustworthy as one of
your own secret keys. This option is useful if you don't want to keep
your secret keys (or one of them) online but still be able to check
the validity of a given recipient's or signator's key.
- --delete-key =name= :: Remove key from the public keyring
- --delete-secret-key =name= :: Remove key from the secret and public
keyring
- --gen-revoke :: Generate a revocation certificate for the complete
key. To revoke a subkey or a signature, use the --edit command.
- --export [ =names= ] :: Either export all keys from all keyrings
(default keyrings and those registered via option --keyring), or if
at least one name is given, those of the given name. The new keyring
is written to stdout or to the file given with option "output". Use
together with --armor to mail those keys.
- --send-keys [ =names= ] :: Same as --export but sends the keys to a
keyserver. Option --keyserver must be used to give the name of this
keyserver. Don't send your complete keyring to a keyserver - select
only those keys which are new or changed by you.
- --export-all [ =names= ] :: Same as --export, but does also export keys
which are not compatible to OpenPGP.
- --export-secret-keys [ =names= ], --export-secret-subkeys
[ =names= ] :: Same as --export, but does export the secret keys. This
is normally not very useful and a security risk. the second form of
the command has the special property to render the secret part of the
primary key useless; this is a GNU extension to OpenPGP and other
implementations can not be expected to successful import such a key.
- --import [ =files= ], --fast-import [ =files= ] :: Import/merge keys.
This adds the given keys to the keyring. The fast version does not
build the trustdb; this can be done at any time with the command
--update-trustdb.
There are a few other options which control how this command works.
Most notable here is the --merge-only options which does not insert
new keys but does only the merging of new signatures, user-IDs and
subkeys.
- --recv-keys =key IDs= :: Import the keys with the given key IDs from
a HKP keyserver. Option --keyserver must be used to give the name of
this keyserver.
- --export-ownertrust :: List the assigned ownertrust values in ASCII
format for backup purposes
- --import-ownertrust [ =files= ] :: Update the trustdb with the
ownertrust values stored in =files= (or stdin if not given); existing
values will be overwritten.
- --print-md =algo= [ =files= ] :: Print message digest of algorithm ALGO
for all given files of stdin. If "*" is used for the algorithm,
digests for all available algorithms are printed.
- --gen-random =0|1|2= [ =count= ] :: Emit COUNT random bytes of the
given quality level. If count is not given or zero, an endless
sequence of random bytes will be emitted. PLEASE, don't use this
command unless you know what you are doing, it may remove precious
entropy from the system!
- --gen-prime =mode= =bits= [ =qbits= ] :: Use the source, Luke :-). The
output format is still subject to change.
- --version :: Print version information along with a list of supported
algorithms.
- --warranty :: Print warranty information.
- -h, --help :: Print usage information. This is a really long list
even it does list not all options.
** OPTIONS
Long options can be put in an options file (default "~/.gnupg/options").
Do not write the 2 dashes, but simply the name of the option and any
required arguments. Lines with a hash as the first non-white-space
character are ignored. Commands may be put in this file too, but that
does not make sense.
*gpg* recognizes these options:
- -a, --armor :: Create ASCII armored output.
- -o, --output =file= :: Write output to =file=.
- -u, --local-user =name= :: Use =name= as the user ID to sign. This
option is silently ignored for the list commands, so that it can be
used in an options file.
- --default-key =name= :: Use =name= as default user ID for signatures.
If this is not used the default user ID is the first user ID found in
the secret keyring.
- -r, --recipient =name=, :: Encrypt for user id =name=. If this
option is not specified, GnuPG asks for the user-id unless
--default-recipient is given
- --default-recipient =name= :: Use =name= as default recipient if
option --recipient is not used and don't ask if this is a valid one.
=name= must be a non empty.
- --default-recipient-self :: Use the default key as default recipient
if option --recipient is not used and don't ask if this is a valid
one. The default key is the first one from the secret keyring or the
one set with --default-key.
- --no-default-recipient :: Reset --default-recipient and
--default-recipient-self.
- --encrypt-to =name= :: Same as --recipient but this one is intended
for in the options file and may be used together with an own user-id
as an "encrypt-to-self". These keys are only used when there are
other recipients given either by use of --recipient or by the asked
user id. No trust checking is performed for these user ids and even
disabled keys can be used.
- --no-encrypt-to :: Disable the use of all --encrypt-to keys.
- -v, --verbose :: Give more information during processing. If used
twice, the input data is listed in detail.
- -q, --quiet :: Try to be as quiet as possible.
- -z =n= :: Set compression level to =n=. A value of 0 for =n= disables
compression. Default is to use the default compression level of zlib
(normally 6).
- -t, --textmode :: Use canonical text mode. If -t (but not --textmode)
is used together with armoring and signing, this enables clearsigned
messages. This kludge is needed for PGP compatibility; normally you
would use --sign or --clearsign to selected the type of the
signature.
- -n, --dry-run :: Don't make any changes (this is not completely
implemented).
- -i, --interactive :: Prompt before overwriting any files.
- --batch :: Use batch mode. Never ask, do not allow interactive
commands.
- --no-tty :: Make sure that the TTY (terminal) is never used for any
output. This option is needed in some cases because GnuPG sometimes
prints warnings to the TTY if if --batch is used.
- --no-batch :: Disable batch mode. This may be of use if --batch is
enabled from an options file.
- --yes :: Assume "yes" on most questions.
- --no :: Assume "no" on most questions.
- --always-trust :: Skip key validation and assume that used keys are
always fully trusted. You won't use this unless you have installed
some external validation scheme.
- --keyserver =name= :: Use =name= to lookup keys which are not yet in
your keyring. This is only done while verifying messages with
signatures. The option is also required for the command --send-keys
to specify the keyserver to where the keys should be send. All
keyservers synchronize with each other - so there is no need to send
keys to more than one server. Using the command "host -l pgp.net |
grep wwwkeys" gives you a list of keyservers. Because there is load
balancing using round-robin DNS you may notice that you get different
key servers.
- --no-auto-key-retrieve :: This option disables the automatic
retrieving of keys from a keyserver while verifying signatures. This
option allows to keep a keyserver in the options file or the
--send-keys and --recv-keys commands.
- --honor-http-proxy :: Try to access the keyserver over the proxy set
with the variable "http\_proxy".
- --keyring =file= :: Add =file= to the list of keyrings. If =file=
begins with a tilde and a slash, these are replaced by the HOME
directory. If the filename does not contain a slash, it is assumed to
be in the home-directory ("~/.gnupg" if --homedir is not used). The
filename may be prefixed with a scheme:
"gnupg-ring:" is the default one.
"gnupg-gdbm:" may be used for a GDBM ring. Note that GDBM is
experimental and likely to be removed in future versions.
It might make sense to use it together with --no-default-keyring.
- --secret-keyring =file= :: Same as --keyring but for the secret
keyrings.
- --homedir =directory= :: Set the name of the home directory to
=directory= If this option is not used it defaults to "~/.gnupg". It
does not make sense to use this in a options file. This also
overrides the environment variable "GNUPGHOME".
- --charset =name= :: Set the name of the native character set. This is
used to convert some strings to proper UTF-8 encoding. Valid values
for =name= are:
- iso-8859-1 :: This is the default Latin 1 set.
- iso-8859-2 :: The Latin 2 set.
- koi8-r :: The usual Russian set (rfc1489).
- --utf8-strings, --no-utf8-strings :: Assume that the arguments are
already given as UTF8 strings. The default (--no-utf8-strings) is to
assume that arguments are encoded in the character set as specified
by --charset. These options effects all following arguments. Both
options may used multiple times.
- --options =file= :: Read options from =file= and do not try to read
them from the default options file in the homedir (see --homedir).
This option is ignored if used in an options file.
- --no-options :: Shortcut for "--options /dev/null". This option is
detected before an attempt to open an option file.
- --load-extension =name= :: Load an extension module. If =name= does
not contain a slash it is searched in "/usr/local/lib/gnupg" See the
manual for more information about extensions.
- --debug =flags= :: Set debugging flags. All flags are or-ed and
=flags= may be given in C syntax (e.g. 0x0042).
- --debug-all :: Set all useful debugging flags.
- --status-fd =n= :: Write special status strings to the file
descriptor =n=. See the file DETAILS in the documentation for a
listing of them.
- --logger-fd =n= :: Write log output to file descriptor =n= and not to
stderr.
- --no-comment :: Do not write comment packets. This option affects
only the generation of secret keys. Please note, that this has
nothing to do with the comments in clear text signatures.
- --comment =string= :: Use =string= as comment string in clear text
signatures. To suppress those comment strings entirely, use an empty
string here.
- --default-comment :: Force to write the standard comment string in
clear text signatures. Use this to overwrite a --comment from a
config file.
- --no-version :: Omit the version string in clear text signatures.
- --emit-version :: Force to write the version string in clear text
signatures. Use this to overwrite a previous --no-version from a
config file.
- -N, --notation-data =name=value= :: Put the name value pair into the
signature as notation data. =name= must consists only of alphanumeric
characters, digits or the underscore; the first character must not be
a digit. =value= may be any printable string; it will encoded in
UTF8, so sou should have check that your --charset is set right. If
you prefix =name= with an exclamation mark, the notation data will be
flagged as critical (rfc2440:5.2.3.15).
- --set-policy-url =string= :: Use =string= as Policy URL for
signatures (rfc2440:5.2.3.19). If you prefix it with an exclamation
mark, the policy URL packet will be flagged as critical.
- --set-filename =string= :: Use =string= as the name of file which is
stored in messages.
- --use-embedded-filename :: Try to create a file with a name as
embedded in the data. This can be a dangerous option as it allows to
overwrite files.
- --completes-needed =n= :: Number of completely trusted users to
introduce a new key signer (defaults to 1).
- --marginals-needed =n= :: Number of marginally trusted users to
introduce a new key signer (defaults to 3)
- --max-cert-depth =n= :: Maximum depth of a certification chain
(default is 5).
- --cipher-algo =name= :: Use =name= as cipher algorithm. Running the
program with the command --version yields a list of supported
algorithms. If this is not used the cipher algorithm is selected from
the preferences stored with the key.
- --digest-algo =name= :: Use =name= as message digest algorithm.
Running the program with the command --version yields a list of
supported algorithms. Please note that using this option may violate
the OpenPGP requirement, that a 160 bit hash is to be used for DSA.
- --s2k-cipher-algo =name= :: Use =name= as the cipher algorithm used
to protect secret keys. The default cipher is BLOWFISH. This cipher
is also used for conventional encryption if --cipher-algo is not
given.
- --s2k-digest-algo =name= :: Use =name= as the digest algorithm used
to mangle the passphrases. The default algorithm is RIPE-MD-160. This
digest algorithm is also used for conventional encryption if
--digest-algo is not given.
- --s2k-mode =n= :: Selects how passphrases are mangled. If =n= is 0 a
plain passphrase (which is not recommended) will be used, a 1
(default) adds a salt to the passphrase and a 3 iterates the whole
process a couple of times. Unless --rfc1991 is used, this mode is
also used for conventional encryption.
- --compress-algo =n= :: Use compress algorithm =n=. Default is 2 which
is RFC1950 compression. You may use 1 to use the old zlib version
(RFC1951) which is used by PGP. The default algorithm may give better
results because the window size is not limited to 8K. If this is not
used the OpenPGP behavior is used, i.e. the compression algorithm is
selected from the preferences; note, that this can't be done if you
do not encrypt the data.
- --disable-cipher-algo =name= :: Never allow the use of =name= as
cipher algorithm. The given name will not be checked so that a later
loaded algorithm will still get disabled.
- --disable-pubkey-algo =name= :: Never allow the use of =name= as
public key algorithm. The given name will not be checked so that a
later loaded algorithm will still get disabled.
- --throw-keyid :: Do not put the keyid into encrypted packets. This
option hides the receiver of the message and is a countermeasure
against traffic analysis. It may slow down the decryption process
because all available secret keys are tried.
- --not-dash-escaped :: This option changes the behavior of cleartext
signatures so that they can be used for patch files. You should not
send such an armored file via email because all spaces and line
endings are hashed too. You can not use this option for data which
has 5 dashes at the beginning of a line, patch files don't have this.
A special armor header line tells GnuPG about this cleartext
signature option.
- --escape-from-lines :: Because some mailers change lines starting
with "From " to " :: Using an exact to
match string. The equal sign indicates this.
- :: Using the email address part which
must match exactly. The left angle bracket indicates this email
address mode.
- +Heinrich Heine duesseldorf :: All words must match exactly (not case
sensitive) but can appear in any order in the user ID. Words are any
sequences of letters, digits, the underscore and all characters with
bit 7 set.
- #34 :: Using the Local ID. This is a very low level method and should
only be used by applications which really need it. The hash character
indicates this method. An application should not assume that this is
only a number.
- Heine, *Heine :: By case insensitive substring matching. This is the
default mode but applications may want to explicitely indicate this
by putting the asterisk in front.
** RETURN VALUE
The program returns 0 if everything was fine, 1 if at least a signature
was bad, and other error codes for fatal errors.
** EXAMPLES
- gpg -se -r =Bob= =file= :: sign and encrypt for user Bob
- gpg --clearsign =file= :: make a clear text signature
- gpg -sb =file= :: make a detached signature
- gpg --list-keys =user_ID= :: show keys
- gpg --fingerprint =user_ID= :: show fingerprint
- gpg --verify =pgpfile=, gpg --verify =sigfile= [ =files= ] :: Verify
the signature of the file but do not output the data. The second form
is used for detached signatures, where =sigfile= is the detached
signature (either ASCII armored of binary) and [ =files= ] are the
signed data; if this is not given the name of the file holding the
signed data is constructed by cutting off the extension (".asc" or
".sig") of =sigfile= or by asking the user for the filename.
** ENVIRONMENT
- HOME :: Used to locate the default home directory.
- GNUPGHOME :: If set directory used instead of "~/.gnupg".
- http\_proxy :: Only honored when the option --honor-http-proxy is
set.
** FILES
- ~/.gnupg/secring.gpg :: The secret keyring
- ~/.gnupg/secring.gpg.lock :: and the lock file
- ~/.gnupg/pubring.gpg :: The public keyring
- ~/.gnupg/pubring.gpg.lock :: and the lock file
- ~/.gnupg/trustdb.gpg :: The trust database
- ~/.gnupg/trustdb.gpg.lock :: and the lock file
- ~/.gnupg/random\_seed :: used to preserve the internal random pool
- ~/.gnupg/options :: May contain options
- /usr[/local]/share/gnupg/options.skel :: Skeleton options file
- /usr[/local]/lib/gnupg/ :: Default location for extensions
** WARNINGS
Use a *good* password for your user account and a *good* passphrase to
protect your secret key. This passphrase is the weakest part of the
whole system. Programs to do dictionary attacks on your secret keyring
are very easy to write and so you should protect your "~/.gnupg/"
directory very well.
Keep in mind that, if this program is used over a network (telnet), it
is *very* easy to spy out your passphrase!
** BUGS
On many systems this program should be installed as setuid(root). This
is necessary to lock memory pages. Locking memory pages prevents the
operating system from writing memory pages to disk. If you get no
warning message about insecure memory 3our operating system supports
locking without being root. The program drops root privileges as soon as
locked memory is allocated.
diff --git a/web/documentation/manuals.org b/web/documentation/manuals.org
index 3dee9ca..d72ff1a 100644
--- a/web/documentation/manuals.org
+++ b/web/documentation/manuals.org
@@ -1,16 +1,14 @@
#+TITLE: GnuPG - Manuals
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
* Manuals
This is a list of online available manuals. Those marked as "draft" may
document features not yet available in the released software version.
- - GnuPG (2.1) manual : [[file:manuals/gnupg/][HTML]], [[file:manuals/gnupg.pdf][PDF]]
- - GnuPG (2.0) manual : [[file:manuals/gnupg-2.0/][HTML]], [[file:manuals/gnupg-2.0.pdf][PDF]]
- - Libgcrypt manual : [[file:manuals/gcrypt/][HTML]], [[file:manuals/gcrypt.pdf][PDF]], [[file:manuals/gcrypt-devel/][HTML (draft)]].
- - Libksba manual : [[file:manuals/ksba/][HTML]], [[file:manuals/ksba.pdf][PDF]].
- - Libassuan manual : [[file:manuals/assuan/][HTML]], [[file:manuals/assuan.pdf][PDF]].
- - GPGME manual : [[file:manuals/gpgme/][HTML]], [[file:manuals/gpgme.pdf][PDF]].
- - Dirmngr manual : [[file:manuals/dirmngr/][HTML]], [[file:manuals/dirmngr.pdf][PDF]] (for GnuPG 2.0).
+ - GnuPG manual :: [[file:manuals/gnupg/][HTML]], [[file:manuals/gnupg.pdf][PDF]]
+ - Libgcrypt manual :: [[file:manuals/gcrypt/][HTML]], [[file:manuals/gcrypt.pdf][PDF]].
+ - Libksba manual :: [[file:manuals/ksba/][HTML]], [[file:manuals/ksba.pdf][PDF]].
+ - Libassuan manual :: [[file:manuals/assuan/][HTML]], [[file:manuals/assuan.pdf][PDF]].
+ - GPGME manual :: [[file:manuals/gpgme/][HTML]], [[file:manuals/gpgme.pdf][PDF]].
diff --git a/web/documentation/pressreview.org b/web/documentation/pressreview.org
index 8a7b747..612f5b5 100644
--- a/web/documentation/pressreview.org
+++ b/web/documentation/pressreview.org
@@ -1,202 +1,237 @@
#+TITLE: GnuPG - Press Review
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
* Press Review
GnuPG is sometimes mentioned in the press and other media. This page
lists articles related to GnuPG we are aware of.
+ - [[International][English]] articles
+ - [[French]] articles
+ - [[German]] articles
+
* International
Here are articles originally published in English.
+** ArsTechnica UK 2016-12-20
+
+ [[http://arstechnica.co.uk/information-technology/2016/12/signal-does-not-replace-pgp/][Op-ed: Why I’m not giving up on PGP]]
+
+
** ProPublica 2015-02-05
The World’s Email Encryption Software Relies on One Guy, Who is Going Broke\\
Julia Angwin
[[http://www.propublica.org/article/the-worlds-email-encryption-software-relies-on-one-guy-who-is-going-broke][Article]]
The article was followed up at many sites, for example:
English:
- [[http://arstechnica.com/security/2015/02/once-starving-gnupg-crypto-project-gets-a-windfall-but-can-it-be-saved/][Ars Technica]]
- [[http://www.computerworlduk.com/blogs/open-enterprise/gnupg-3597056/][Computerworld]]
- [[https://gigaom.com/2015/02/06/funds-flow-in-for-gnupg-author-after-article-reveals-his-plight/][GigaOm]]
- [[http://www.itwire.com/business-it-news/open-source/66886-facebook-stripe-pledge-funds-for-gnupg-development][IT Wire]]
- [[http://www.thegamersdrop.com/2015/02/05/facebook-stripe-pledge-100000year-broke-developer/][The Gamersdrop]]
- [[http://www.theregister.co.uk/2015/02/05/gnupg_funding/][The Register]]
French:
- [[http://www.01net.com/editorial/644468/le-chiffrement-open-source-gnupg-sauve-in-extremis-par-les-dons-des-internautes/][01net]]
German:
- [[http://www.admin-magazin.de/content/view/full/15613][Admin Magazin]]
- [[http://derstandard.at/2000011366952/Finanzierung-des-Mail-Verschluesselungsprojekts-GnuPG-gesichert][Der Standard]]
- [[http://www.handelsblatt.com/technik/it-internet/it-internet/verschluesselungsprojekt-gnupg-hat-wieder-geld/11338196.html][Handelsblatt]]
- [[http://www.heise.de/newsticker/meldung/Crowdfunding-GnuPG-Entwicklung-ist-gesichert-2542745.html][Heise]]
- [[http://www.focus.de/finanzen/news/wirtschaftsticker/unternehmen-finanzierung-von-mail-verschluesselungsprojekt-gnupg-vorerst-gesichert_id_4457801.html][Focus (dpa)]]
- [[http://www.nordbayern.de/finanzierung-von-mail-verschlusselungsprojekt-gnupg-vorerst-gesichert-1.4174524][Nürnberger Nachrichten / Nordbayern]] FIX URL!
- [[http://www.nzz.ch/mehr/digital/verschluesselte-e-mails-gnupg-spenden-1.18477365][NZZ]]
- [[http://www.spiegel.de/netzwelt/web/e-mail-verschluesselungsprojekt-gnupg-finanzierung-gesichert-a-1017120.html][Spiegel]]
- [[http://www.sueddeutsche.de/news/wirtschaft/internet-finanzierung-von-mail-verschluesselungsprojekt-gnupg-vorerst-gesichert-dpa.urn-newsml-dpa-com-20090101-150206-99-04523][Süddeutsche (dpa)]]
- [[http://www.wz-newsline.de/home/multimedia/finanzierung-von-mail-verschluesselungsprojekt-gnupg-vorerst-gesichert-1.1855606][Westdeutsche Zeitung]]
** LWN 2014-12-04
The GnuPG 2.1 release\\
Nathan Willis
[[https://lwn.net/Articles/624146/][Article]]
** Daily Mail, 2013-02-13
MI5-install-black-box-spy-devices\\
(mentioned in a sidebox)
[[http://www.dailymail.co.uk/sciencetech/article-2274388/MI5-install-black-box-spy-devices-monitor-UK-internet-traffic.html][Article]]
** NYT/IHT, 2012-11-16
Trying to Keep Your E-Mails Secret When the C.I.A. Chief Couldn’t\\
By Nicole Perlroth
[[http://www.nytimes.com/2012/11/17/technology/trying-to-keep-your-e-mails-secret-when-the-cia-chief-couldnt.html][Article]] (registration required)
** LWN 2007-12-27:
GnuPG Celebrates 10 Years\\
(Werner’s mail with comments)
[[http://lwn.net/Articles/263256/][Article]]
** Linux Journal, March 2006, pp. 52--56:
GnuPG Hacks\\
Tony Stieber
[[http://www.linuxjournal.com/article/8732][Article]]
** Salon, 2002-03-27
Pretty geeky privacy\\
Bill Lamb
[[http://www.salon.com/technology/feature/2002/03/27/gnupg][Article]]
** NYT, 1999-11-19
Germany Awards Grant for Encryption\\
Peter Wayner
[[http://partners.nytimes.com/library/tech/99/11/cyber/articles/19encrypt.html][Article]]
# [[file:~/privat/archive/nyt-1999-11-19.txt]]
+* French
+
+** Linuxfr, 2017-06-08
+ Journal GnuPG lance une nouvelle campagne de financement\\
+ gouttegd
+
+ [[https://linuxfr.org/users/gouttegd/journaux/gnupg-lance-une-nouvelle-campagne-de-financement][Article]]
* German
Here are articles originally published in German.
+** Heise, 2017-06-06
+ Neue Crowdfunding-Runde für GnuPG-Entwicklung\\
+ Christiane Schulzki-Haddouti
+
+ [[https://www.heise.de/newsticker/meldung/Neue-Crowdfunding-Runde-fuer-GnuPG-Entwicklung-3735804.html][Artikel]]
+
+** Netzpolitik.org, 2016-01-26
+ Die Person hinter GnuPG: Werner Koch\\
+ Simon Rebiger
+
+ [[https://netzpolitik.org/2016/die-person-hinter-gnupg-werner-koch/][Artikel]]
+
+** WDR 5, 2016-01-18
+ GnuPG und der bescheidene Herr Koch\\
+ 'Pain in the ass' der NSA\\
+ Mirjam Wlodawer.
+
+ [[http://www1.wdr.de/radio/wdr5/gnupg-koch-100.html][Artikel]] [[http://podcast-ww.wdr.de/medstdp/fsk0/91/910864/wdr5neugiergenuegtdasfeature_2016-01-18_wernerkochdermanndermitgnupgdiensaherausfordertwdr5neugiergenuegtdasfeature18012016_wdr5.mp3][Podcast]]
+
+
** DR Wissen, 2015-06-12
Schlüssel für Snowden\\
(in Einhundert, "Candystorm")\\
Monika Ahrens
[[http://dradiowissen.de/beitrag/kryptografie-werner-kochs-software-f%25C3%25BCr-edward-snowden][Artikel]]
-
** DW, 2015-02-19
Verschlüsselung made in Deutschland\\
Matthias Von-Hein
[[http://dw.de/p/1Eebj][Artikel]]
** SZ, 2015-02-18
Wie ein Mann das E-Mail-Geheimniss verteidigt\\
Hakan Tanriverdi
[[http://www.sueddeutsche.de/digital/verschluesselungssoftware-gnu-pg-wie-ein-mann-das-e-mail-geheimnis-verteidigt-1.2355155][Artikel]]
** FAZ, 2015-02-13
- Finger Weg von meine Daten!
+ Finger Weg von meinen Daten!\\
Constanze Kurz
[[http://www.faz.net/aktuell/feuilleton/aus-dem-maschinenraum/verschluesselungssoftware-finger-weg-von-meinen-daten-13416853.html][Artikel]]
** taz, 2015-02-13
Der bescheidene Herr Koch\\
Kai Schlieter
[[http://www.taz.de/Verschluesselung-mit-GnuPG/!154635/][Artikel]]
** Rheinische Post, Lokalteil 2015-02-13
400000 Euro Spende für Programmierer\\
Dag Brückner
[[http://www.rp-online.de/nrw/staedte/erkrath/400-000-euro-spende-fuer-programmierer-aid-1.4869922][Artikel]]
** netzpolitik, 2014-11-13
Verschlüsselung im Bundestag: Fördern Bundesregierung
oder BSI die freie Software GnuPG?\\
Markus Beckedahl
[[https://netzpolitik.org/2014/verschluesselung-im-bundestag-foerdern-bundesregierung-oder-bsi-die-freie-software-gnupg/][Artikel]]
** Heise Ticker 2014-11-07
GnuPG unterstützt Krypto auf Elliptischen Kurven\\
Jürgen Schmidt
http://www.heise.de/newsticker/meldung/GnuPG-unterstuetzt-Krypto-auf-Elliptischen-Kurven-2444337.html
** Linux-Magazin 2014-08
Wer bezahlt die freien Krypto-Entwickler?\\
Chronisch klamm\\
Tim Schürmann
http://www.linux-magazin.de/Ausgaben/2014/08/Finanzierung/%28language%29/ger-DE
** Saarbrücker Zeitung, 2013-10-02, Seite E6
Sicherheit mit einem Klick\\
Von Martin Schäfer
# Attachment: Saar20131002.pdf
** Spiegel Online, 2013-07-04
Schutz gegen Internet-Spione: So verschlüsseln Sie Ihre E-Mails\\
Von Friedrich Lindenberg und Christian Stöcker
[[http://www.spiegel.de/netzwelt/netzpolitik/so-verschluesseln-sie-ihre-e-mails-mit-openpgp-a-909316.html][Artikel]]
** c't, 22/2013, Seite 136
Privatsache E-Mail\\
Nachrichten verschlüsseln und signieren mit PGP
** c't 20/2012, Seite 190
Vertrauen auf den ersten Blick\\
Automatische E-Mail-Verschlüsselung mit Steed\\
Autor: Holger Bleich, Bernhard Münkel
[[http://www.heise.de/artikel-archiv/ct/2012/20/190_Vertrauen-auf-den-ersten-Blick][Artikel]] (Paywall)
** FAS, 2010-08-15
So schützen Sie Ihre Mails\\
Nils Handler
/Die Bundesregierung hat Blackberry und iPhone verbannt, weil die
Geräte zu unsicher sind. Privatleute müssen sich ebenfalls wappnen./
[[http://fazarchiv.faz.net/document/showSingleDoc/FAS__SD1201008152800208?DT_from%3D&KO%3D&timeFilter%3D&timePeriod%3DtimeFilter&dosearch%3Dy&crxdefs%3D&sext%3D0&NN%3D&BC%3D&q%3DGnuPG&search_in%3Dq&sorting%3D&DT_to%3D&CO%3D&submitSearch%3DSuchen&maxHits%3D&CN%3D&toggleFilter%3D&annr%3D186182&highlight%3D%255C%2525eAEBEQDu%252F0IqOmdudXBnLEJFR1JJRkYsL3QFFQ%253D%253D][Artikel]] (Paywall)
# Telefonat am 2010-08-12 und 2010-08-14 für
** i'X 3/2009, Seite 161
Vor 10 Jahren:\\
Verschlüsseln mit GnuPG.
** i'X 3/1999, Seite 94
Schlüsselkind\\
Freie PGP-Implementierung GnuPG
[[http://www.heise.de/kiosk/archiv/ix/1999/3/94_Freie-PGP-Implementierung-GnuPG][Artikel]] (Paywall)
diff --git a/web/documentation/security.org b/web/documentation/security.org
new file mode 100644
index 0000000..c724827
--- /dev/null
+++ b/web/documentation/security.org
@@ -0,0 +1,29 @@
+#+TITLE: GnuPG - Security
+#+STARTUP: showall
+#+SETUPFILE: "../share/setup.inc"
+
+* Security
+
+The GnuPG Project takes the security of software it develops very
+seriously. In general we prefer a [[https://en.wikipedia.org/wiki/Full_disclosure_(computer_security)][full disclosure]] approach and all
+bugs listed in our [[file:bts.org][bug tracker]] as well as code changes in our [[../download/git.org][software
+repository]] are public. Given that GnuPG is an important part of many
+software distributions and severe bugs in GnuPG would affect their
+users directly, we co-ordinate with them in private as soon as we
+learn about a severe vulnerability.
+
+Sometimes we receive pre-notifications of research which may lead to a
+new kind of vulnerability. In these cases we may work with the
+researchers in private on a solution and co-ordinate our fix release
+with them.
+
+** Security contact
+
+If you found a *severe* security problem and you do not want to
+publish it, please report it by mail to security at gnupg.org.
+
+Note that we do not use a team OpenPGP key. Thus please write a
+non-encrypted message to the security address and ask for the keys of
+the developers at duty and then encrypt the mail to all of them. A
+list of our core developers can be found [[../people/index.org][here]]; they are all active on
+the gnupg-devel mailing list.
diff --git a/web/documentation/sites.org b/web/documentation/sites.org
index a631fff..8d730ac 100644
--- a/web/documentation/sites.org
+++ b/web/documentation/sites.org
@@ -1,12 +1,22 @@
-#+TITLE: GnuPG - Other web sites
+#+TITLE: GnuPG - Other web sites and cards
#+STARTUP: showall
#+SETUPFILE: "../share/setup.inc"
+* Press review
+
+ [[file:pressreview.org][Articles on GnuPG]]
+
* Other web sites
This page shows a list of web sites which are somehow related to GnuPG.
- [[http://pgp.iijlab.net/][Japanese PGP page]] :: A site in Japanese dedicated to PGP.
- [[http://pt.gnupg.org.][Portuguese GnuPG site]] :: A site in Portuguese dedicated to GnuPG.
- [[http://pgpru.com/][Russian OpenPGP site]] :: A site in Russian with a forum dedicated to
OpenPGP.
+
+* OpenPGP card implementations
+
+OpenPGP cards can be purchased from:
+
+- [[https://www.floss-shop.de/en/security-privacy/][FLOSS-Shop]] (formerly kernelconcepts)
diff --git a/web/donate/camp2017.de.org b/web/donate/camp2017.de.org
new file mode 100644
index 0000000..3f2f41a
--- /dev/null
+++ b/web/donate/camp2017.de.org
@@ -0,0 +1,1844 @@
+# -*- html -*-
+#+TITLE: GnuPG - Spenden
+#+STARTUP: showall
+#+SETUPFILE: "../share/setup.inc"
+#
+# Note: Do not use relative links because this page is also used as a
+# template from cgi-bin/. Using https://www.gnupg.org/... is
+# fine as it is stripped before publishing.
+
+#+BEGIN_HTML
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
GnuPG Spendenkampagne
+
+
+
+
+
+
Klicken um das Video zu starten
+
+ (erfordert JavaScript von YouTube).
+
+
+
+
+
+
+
+
GnuPG Spendenkampagne
+
+
+
[This is a snaphot of the page at the end of the
+ campaign on 2017-09-05. ]
+
+
+
+
+
+
+ pro Monat von benötigten
+
+
+
+ +
+
+ an einmaligen Spenden
+
+
+ Unterstützer
+
+
+
+
+
+
+
+
+
+
+
+
+
+ GnuPG braucht Ihre Unterstützung um Ihre Privatsphäre im
+ Internet zu schützen.
+
+
Aktivisten, Journalisten, Anwälte
+ und viele andere verlassen sich auf
+ GnuPG um ihre
+ Korrespondenz zu beschützen. Weiterhin verlassen sich
+ beinahe alle auf Freier Software basierenden
+ Betriebsysteme (die auf zwei drittel der Server des
+ Internets genutzt werden) auf GnuPG um die Integrität
+ ihrer Softwareaktualisierungen sicherzustellen.
+
Um Support und Weiterentwicklung von GnuPG zu
+ ermöglichen bitten wir, die Hauptentwickler von GnuPG,
+ um Spenden von der Allgemeinheit.
+ Unser Hauptziel
+ ist 15 000 Euro pro Monat um
+ drei Entwickler zu finanzieren;
+ unser erweitertes Ziel ist doppelt so
+ viel, 30 000 Euro pro Monat.
+
Bitte denken Sie darüber nach zu Spenden um
+ sicherzustellen, dass diese kritische Software auch
+ weiterhin für jeden funktioniert.
+
+
+
+
+
+
+
+
+
GnuPG Braucht Ihre Hilfe!
+
+ Seit 20 Jahren hilft GnuPG elektronische Kommunikation zu
+ schützen.
+ Cindy
+ Cohn , Geschäftsführerin der
+ Electronic Frontier
+ Foundation (EFF), beschreibt GnuPG als “das Werkzeug, mit dem ich am
+ häufigsten mit Menschen in Not [..] kommuniziere.”
+ Sheera
+ Frenkel ,
+ Auslandskorrespondentin für BuzzFeed News, fügt
+ hinzu: "Als eine Nachrichtenorganisation sind
+ wir ausgebildet GPG zu benutzen. Es geht um die
+ Quellen und was mit ihnen passiert wenn man ihr Land
+ verlässt, die brisante Story veröffentlicht und die
+ Regierung nach dem Informant sucht, der einem die
+ Schlüsselinformation verriet." Und GnuPG war
+ bekanntermaßen Edward Snowden's Werkzeug der Wahl um
+ sicher Journalisten über die Massenüberwachung der NSA zu
+ unterrichten.
+
+ Aber GnuPG wird nicht nur zum Verschlüsseln von E-Mails
+ benutzt. GnuPG schützt
+ Softwareaktualisierungen auf fast allen freien
+ Betriebsystemen, die
+ auf zwei
+ drittel aller Server im Internet eingesetzt werden .
+ Weiterhin wird GnuPG von einer breiten Masse an
+ Organisationen und Firmen verwendet. Arthur
+ Jordan , Vizepräsident der IT
+ von 2U, hat uns beispielsweise erzählt:
+ "als wir Universitäten kontaktierten um zu fragen, wie
+ sie sicher Dateien übertragen, stellten wir fest, dass sie
+ bereits mit GPG verschlüsselten."
+
+ Trotz der kritischen Rolle die GnuPG insbesondere für
+ Journalisten, Aktivisten und Anwälte, aber auch für jede
+ Nutzerin des Internets spielt, hatte GnuPG im Jahr 2012
+ Finanzierungsprobleme . Aufgrund von
+ ausbleibenden Aufträgen musste Werner Koch, GnuPG's
+ Hauptentwickler, seinen einzigen Mitarbeiter entlassen,
+ der Vollzeit an GnuPG gearbeitet hat. Und im Jahr 2014
+ musste Werner andere Jobs annehmen um seine Arbeit an
+ GnuPG zu finanzieren.
+
+ Die Situation war so hoffnungslos, dass Werner
+ kurz davor stand aufzugeben. Aber Freunde haben ihn
+ überzeugt, es mit einer Spendenkampagne zu
+ versuchen. Die Reaktion war überwältigend.
+ Nicht nur hat er genug Geld erhalten um seinen
+ Lebensunterhalt zu finanzieren, er bekam
+ 250 000 Euro in kleinen Spenden , und
+ Stripe, Facebook und die Linux Foundation haben
+ zugesagt, je etwa 50 000 Euro pro Jahr zu
+ spenden.
+
+
+
+
+ Das GnuPG Team auf der OpenPGP.conf 2016
+
+
+
+ Ermutigt von der überwältigenden Hilfsbereitschaft
+ hat Werner entschieden sein Team zu vergrößern.
+ Bis zum heutigen Tag hat er fünf Entwickler eingestellt,
+ und über die letzten zwei Jahre hat sich GnuPG und das
+ dazugehörende Ökosystem in einer Reihe von Punkten
+ weiterentwickelt. Zum Beispiel haben wir
+ das Finden von Schlüssel vereinfacht , ein System zur
+ Anbindung von GPG an Python adoptiert, an
+ Enigmail
+ mitgearbeitet,
+ und das
+ Gnuk Projekt unterstützt—einem Sicherheits-Token
+ bestehend aus Freier Software und Freier Hardware.
+
+ Wir möchten diese Arbeit auf lange Zeit
+ fortsetzen. Aber wir wollen, dass unsere
+ Loyalität in erster Linie der Allgemeinheit gehört.
+ Deshalb wollen wir sicherstellen, dass der Großteil der
+ Finanzierung von Individuen und nicht von Firmen kommt.
+ Weiterhin setzen wir um das Bestehen des Projektes auf
+ lange Sicht zu gewähren auf regelmäßige Spenden und nicht
+ auf einmalige Spenden wie letztes mal.
+
+ Unser Hauptziel ist es, Spenden in
+ Höhe von 15 000 Euro monatlich zu bekommen—genug
+ um drei Entwickler zu finanzieren . Wir können
+ dieses Ziel erreichen wenn nur 2000 Menschen
+ zwischen 5 und 10 Euro monatlich spenden, dass
+ entspricht etwa zwei oder drei Tassen Kaffee.
+
+
+
+
Das Gnuk Token
+
+ Das Geld erlaubt uns zunächst GnuPG zu pflegen.
+ Weiterhin werden wir unsere Arbeit an dem Gnuk
+ Sicherheitstoken finanzieren. Ein neues Projekt, welches
+ uns das Geld ermöglichen soll, ist ein Buch mit dem Titel
+ "An Advanced Introduction to GnuPG" — "Eine
+ Fortgeschrittene Einführung in GnuPG" — mit drei
+ Zielgruppen: Entwickler, die GnuPG in ihre Programme
+ integrieren wollen und die verschiedenen Konzepte,
+ Sicherheitsabwägungen und übliche Stolperfallen verstehen
+ müssen; Trainer, die Fortbildungen in digitaler Sicherheit
+ anbieten, um Endbenutzern handfeste Ratschläge geben zu
+ können; und natürlich Enthusiasten.
+
+ Unser erweitertes Ziel ist die doppelte Menge an
+ Spenden . Wenn 4000 Menschen nur fünf oder
+ zehn Euro jeden Monat spenden, werden wir unser Team
+ vergrößern und mit ihnen Projekte im GnuPG Ökosystem
+ unterstützten. Ein Projekt, an dem wir wirklich gerne
+ mitarbeiten möchten, ist GPGTools, auf das sich viele
+ Aktivisten und Journalisten verlassen um ihre
+ Onlinekommunikation zu schützen. Wir wollen
+ sicherstellen, dass die GPG-Integration für das
+ Mailprogramm von Apple unterstützt ist sobald eine neue
+ Version von macOS erscheint.
+
+ Vielleicht benutzen Sie nicht GnuPG um Ihre E-Mails zu
+ verschlüsseln. Nichtsdestotrotz verlassen sich
+ Journalisten deren Arbeit Sie schätzen auf GnuPG um ihre
+ Quellen zu schützen, verlassen sich Aktivisten die für
+ eine Sache kämpfen die Sie unterstützenswert finden auf
+ GnuPG um ihre Kommunikation zu schützen, und verlassen
+ sich Anwälte die mit ihren Klienten verkehren auf GnuPG um
+ ihrer Verschwiegenheitspflicht in unserer digitalen Welt
+ nachzukommen. Weiterhin verlassen sich Betriebsysteme
+ basierend auf Freier Software auf GnuPG um ihre
+ Softwareaktualisierungen zu verifizieren.
+
+
Falls Sie
+ —wie wir— überzeugt sind, dass diese Arbeit
+ essenziell ist um Demokratie und Privatsphäre zu schützen,
+ dann helfen Sie uns bitte unsere Arbeit fortzusetzen
+ und unabhängig zu bleiben .
+
+
+
+
+
+
+
+
+
+
+
+
+
Wartung
+
Unsere höchste Priorität ist sicherzustellen,
+ dass GnuPG auch in Zukunft gewartet wird. Dazu
+ gehört das Reagieren auf Fehlerberichte,
+ Sicherheitsprobleme zu beheben und mit dem
+ neuesten Stand der Kryptographie mitzuhalten.
+
+
+
+
+
Gnuk
+
Das Gnuk Sicherheitstoken besteht komplett aus
+ Freier Software. Auch das Hardwaredesign, entwickelt
+ von Niibe, ist frei verfügbar. Wir planen, mehr
+ in seine Produktion und seinen Vertrieb zu investieren.
+
+
+
+
+
+
+
Buch
+
Wir möchten die Dokumentation verbessern.
+ Insbesondere arbeiten wir an einem Buch mit dem
+ Titel An Advanced Introduction to GnuPG
+ — Eine Fortgeschrittene Einführung in
+ GnuPG — das erläutert wie GnuPG
+ funktioniert und wie man es am besten einsetzt.
+ Die Zielgruppen sind Trainer, die Fortbildungen in
+ digitaler Sicherheit anbieten, Programmierer, die
+ GnuPG in ihre Anwendungen einbetten und
+ Enthusiasten.
+
+
+
+
+
Größeres Ökosystem
+
Die meisten Leute nutzen GnuPG nicht direkt,
+ sondern durch Werkzeuge und Plugins.
+ Wir wollen die Entwickler solcher Programme
+ unterstützen, um die Integration von GnuPG zu
+ verbessern. Insbesondere möchten wir
+ sicherstellen, dass das GPG-Plugin für
+ Apple's Mailprogramm (GPGTools) mit jeder neuen
+ Version von macOS funktioniert.
+
+
+
+
+
+
+
+
+
+
+
+
Was andere über GnuPG sagen
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “GPG ist das Werkzeug, mit dem ich am
+ häufigsten mit Menschen in Not auf der
+ ganzen Welt kommuniziere.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Letztendlich sind wir Anwälte, wir
+ tauschen Dokumente und E-Mails aus und im
+ Herzen davon ist—die Sicherheit von
+ GPG.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Ich sprach mit einer
+ Quelle in
+ Russland. Ich habe ihm erklärt wie GPG
+ funktioniert, und er hat mir kürzlich
+ seine erste verschlüsselte E-Mail gesendet
+ und gesagt:
+ ‘Vielen Dank, es hat mich wirklich
+ beruhigt, dass sie sich um meine Sicherheit
+ sorgen.’ ”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Ob Sie einen GPG-Schlüssel haben oder
+ nicht, ob Sie je verschlüsselt E-Mails
+ versenden, Sie verlassen sich auf GPG um
+ sicherzustellen, dass
+ Softwareaktualisierungen wie erwartet
+ funktionieren.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “GPG ist der Schlüssel um die
+ Verschwiegenheitspflicht von Anwälten in
+ unserer digitalen Welt umzusetzen.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “GPG ist Teil der
+ ausgewogenen Ernährung eines jeden
+ Reporters, besonders wenn sie ihre Quellen
+ schützen wollen und von Whistleblowern
+ angesprochen werden möchten.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Die Journalisten für die wir Arbeiten
+ vertrauen darauf, dass wir wissen, wie man
+ sie am besten beschützt. Und die Art und
+ Weise wie wir die sichersten und
+ praktikablesten Werkzeuge — wie GPG
+ — einsetzen erfüllt diese
+ Anforderung.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Wir fühlen uns sehr sicher wenn wir GPG
+ einsetzen, um die Daten von Studenten zu
+ schützen beim Austausch von Akten zwischen
+ Universitäten. Es beruhigt uns wirklich
+ sehr.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Für mich ist GPG eines der
+ Schlüsselwerkzeuge das wir benötigen, um
+ selbstbestimmt in den Vereinigten Staaten
+ und auf jedem Fleck der Erde in dem
+ Digitalen Zeitalter leben zu können.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Als eine Nachrichtenorganisation sind wir
+ ausgebildet GPG zu benutzen. Es geht um
+ die Quellen und was mit ihnen passiert
+ wenn man ihr Land verlässt, die brisante
+ Story veröffentlicht und die Regierung
+ nach dem Informant sucht, der einem die
+ Schlüsselinformation verriet.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Wir [bei SecureDrop] haben uns für GPG
+ statt anderer Alternativen entschieden,
+ überwiegend da GPG das bekannteste und am
+ meisten genutzte Werkzeug zur
+ asymmetrischen Verschlüsselung ist.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Als wir Universitäten kontaktierten um zu
+ fragen, wie sie sicher Dateien übertragen,
+ stellten wir fest, dass sie bereits mit
+ GPG verschlüsselten”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Für mich persönlich ist der entscheidende
+ Vorteil von GPG, dass es mir ermöglicht
+ mit Menschen zu kommunizieren, die ich
+ sonst nicht erreichen könnte, um ihnen
+ entweder zu helfen oder ihre Geschichte zu
+ erzählen.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Aber auch wenn Sie ganz sicher sind, dass
+ Sie nichts zu verbergen haben, wenn Sie
+ denken, dass andere Menschen etwas
+ rechtmäßig und notwendig zu verbergen
+ haben, sind wir der Meinung, dass Sie GPG nutzen sollten, denn das
+ hilft diejenigen zu schützen, die wirklich
+ GPG nutzen müssen.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “GPG hat uns noch nicht den Hintern
+ gerettet, aber die Tatsache, dass es da
+ ist—es lässt uns nachts ruhig
+ schlafen.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “GPG ist das Werkzeug, mit dem ich am
+ häufigsten mit Menschen in Not auf der
+ ganzen Welt kommuniziere.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Letztendlich sind wir Anwälte, wir
+ tauschen Dokumente und E-Mails aus und im
+ Herzen davon ist—die Sicherheit von
+ GPG.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Ich sprach mit einer
+ Quelle in
+ Russland. Ich habe ihm erklärt wie GPG
+ funktioniert, und er hat mir kürzlich
+ seine erste verschlüsselte E-Mail gesendet
+ und gesagt:
+ ‘Vielen Dank, es hat mich wirklich
+ beruhigt, dass sie sich um meine Sicherheit
+ sorgen.’ ”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Ob Sie einen GPG-Schlüssel haben oder
+ nicht, ob Sie je verschlüsselt E-Mails
+ versenden, Sie verlassen sich auf GPG um
+ sicherzustellen, dass
+ Softwareaktualisierungen wie erwartet
+ funktionieren.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “GPG ist der Schlüssel um die
+ Verschwiegenheitspflicht von Anwälten in
+ unserer digitalen Welt umzusetzen.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “GPG ist Teil der
+ ausgewogenen Ernährung eines jeden
+ Reporters, besonders wenn sie ihre Quellen
+ schützen wollen und von Whistleblowern
+ angesprochen werden möchten.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Die Journalisten für die wir Arbeiten
+ vertrauen darauf, dass wir wissen, wie man
+ sie am besten beschützt. Und die Art und
+ Weise wie wir die sichersten und
+ praktikablesten Werkzeuge — wie GPG
+ — einsetzen erfüllt diese
+ Anforderung.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Wir fühlen uns sehr sicher wenn wir GPG
+ einsetzen um die Daten von Studenten zu
+ schützen beim Austausch von Akten zwischen
+ Universitäten. Es beruhigt uns wirklich
+ sehr.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Für mich ist GPG eines der
+ Schlüsselwerkzeuge das wir benötigen, um
+ selbstbestimmt in den Vereinigten Staaten
+ und auf jedem Fleck der Erde in dem
+ Digitalen Zeitalter leben zu können.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Als eine Nachrichtenorganisation sind wir
+ ausgebildet GPG zu benutzen. Es geht um
+ die Quellen und was mit ihnen passiert
+ wenn man ihr Land verlässt, die brisante
+ Story veröffentlicht und die Regierung
+ nach dem Informant sucht, der einem die
+ Schlüsselinformation verriet.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Wir [bei SecureDrop] haben uns für GPG
+ statt anderer Alternativen entschieden,
+ überwiegend da GPG das bekannteste und am
+ meisten genutzte Werkzeug zur
+ asymmetrischen Verschlüsselung ist.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Als wir Universitäten kontaktierten um zu
+ fragen, wie sie sicher Dateien übertragen,
+ stellten wir fest, dass sie bereits mit
+ GPG verschlüsselten”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Für mich persönlich ist der entscheidende
+ Vorteil von GPG, dass es mir ermöglicht
+ mit Menschen zu kommunizieren, die ich
+ sonst nicht erreichen könnte, um ihnen
+ entweder zu helfen oder ihre Geschichte zu
+ erzählen.”
+
+
+
+
+
+
+
+
+
+
+
+
+ “Aber auch wenn Sie ganz sicher sind, dass
+ Sie nichts zu verbergen haben, wenn Sie
+ denken, dass andere Menschen etwas
+ rechtmäßig und notwendig zu verbergen
+ haben, sind wir der Meinung, dass Sie GPG nutzen sollten, denn das
+ hilft diejenigen zu schützen, die wirklich
+ GPG nutzen müssen.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “GPG ist das Werkzeug, mit dem ich am
+ häufigsten mit Menschen in Not auf der
+ ganzen Welt kommuniziere.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Letztendlich sind wir Anwälte, wir
+ tauschen Dokumente und E-Mails aus und im
+ Herzen davon ist—die Sicherheit von
+ GPG.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Ich sprach mit einer
+ Quelle in
+ Russland. Ich habe ihm erklärt wie GPG
+ funktioniert, und er hat mir kürzlich
+ seine erste verschlüsselte E-Mail gesendet
+ und gesagt:
+ ‘Vielen Dank, es hat mich wirklich
+ beruhigt, dass sie sich um meine Sicherheit
+ sorgen.’ ”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Ob Sie einen GPG-Schlüssel haben oder
+ nicht, ob Sie je verschlüsselt E-Mails
+ versenden, Sie verlassen sich auf GPG um
+ sicherzustellen, dass
+ Softwareaktualisierungen wie erwartet
+ funktionieren.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “GPG ist der Schlüssel um die
+ Verschwiegenheitspflicht von Anwälten in
+ unserer digitalen Welt umzusetzen.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “GPG ist Teil der
+ ausgewogenen Ernährung eines jeden
+ Reporters, besonders wenn sie ihre Quellen
+ schützen wollen und von Whistleblowern
+ angesprochen werden möchten.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Die Journalisten für die wir Arbeiten
+ vertrauen darauf, dass wir wissen, wie man
+ sie am besten beschützt. Und die Art und
+ Weise wie wir die sichersten und
+ praktikablesten Werkzeuge — wie GPG
+ — einsetzen erfüllt diese
+ Anforderung.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Wir fühlen uns sehr sicher wenn wir GPG
+ einsetzen um die Daten von Studenten zu
+ schützen beim Austausch von Akten zwischen
+ Universitäten. Es beruhigt uns wirklich
+ sehr.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Für mich ist GPG eines der
+ Schlüsselwerkzeuge das wir benötigen, um
+ selbstbestimmt in den Vereinigten Staaten
+ und auf jedem Fleck der Erde in dem
+ Digitalen Zeitalter leben zu können.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Als eine Nachrichtenorganisation sind wir
+ ausgebildet GPG zu benutzen. Es geht um
+ die Quellen und was mit ihnen passiert
+ wenn man ihr Land verlässt, die brisante
+ Story veröffentlicht und die Regierung
+ nach dem Informant sucht, der einem die
+ Schlüsselinformation verriet.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Wir [bei SecureDrop] haben uns für GPG
+ statt anderer Alternativen entschieden,
+ überwiegend da GPG das bekannteste und am
+ meisten genutzte Werkzeug zur
+ asymmetrischen Verschlüsselung ist.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Als wir Universitäten kontaktierten um zu
+ fragen, wie sie sicher Dateien übertragen,
+ stellten wir fest, dass sie bereits mit
+ GPG verschlüsselten”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Für mich persönlich ist der entscheidende
+ Vorteil von GPG, dass es mir ermöglicht
+ mit Menschen zu kommunizieren, die ich
+ sonst nicht erreichen könnte, um ihnen
+ entweder zu helfen oder ihre Geschichte zu
+ erzählen.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “Aber auch wenn Sie ganz sicher sind, dass
+ Sie nichts zu verbergen haben, wenn Sie
+ denken, dass andere Menschen etwas
+ rechtmäßig und notwendig zu verbergen
+ haben, sind wir der Meinung, dass Sie GPG nutzen sollten, denn das
+ hilft diejenigen zu schützen, die wirklich
+ GPG nutzen müssen.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ “GPG hat uns noch nicht den Hintern
+ gerettet, aber die Tatsache, dass es da
+ ist—es lässt uns nachts ruhig
+ schlafen.”
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+