13 April 2018. SMS. GnuPG 1.4.22 for VMS (1.4.22a) ============================== ------------------------------------------------------------------------ Disclaimer ---------- No claims of any sort are made herein. The main GnuPG developers are aware of (and have been helpful to) this effort, but are not responsible for the VMS-specific code. (Any suggestions for improving the code in the VMS-specific sections are welcome, but low expectations are more realistic than high ones.) ------------------------------------------------------------------------ Description ----------- This note accompanies a quick VMS port of GnuPG version 1.4.22. "GnuPG is the GNU project's complete and free implementation of the OpenPGP standard as defined by RFC2440." Some of the most obvious features seem to work (mostly), but many have not been tested. Built and tested (slightly) in these environments: OpenVMS Alpha V8.4, HP C V7.3-010 OpenVMS IA64 V8.4, HP C V7.3-020 OpenVMS VAX V7.3, Compaq C V6.4-005 ------------------------------------------------------------------------ GnuPG Web Resources ------------------- Main Web page: https://gnupg.org/ HTML documentation: https://www.gnupg.org/documentation/index.html ------------------------------------------------------------------------ Cautions -------- The VMS-specific "entropy gathering" code ([.cipher]rndvms.c, used to assist pseudo-random number generation) has not been evaluated for quality. Poor quality here could result in low-quality keys. Suggestions for improvement are always welcome. Files with any RMS record formats are accepted as input by GPG, but, as with most UNIX-oriented programs, RMS file attributes are not preserved. All output files are Stream_LF, so any input files with more exotic attributes may be seen as corrupted after they've been processed by GPG. If RMS attribute preservation is important, it would be best to preprocess the input file(s) using Info-ZIP Zip (or VMS BACKUP) before GPG encryption, and then postprocess using UnZip (or BACKUP, after the usual save set attribute adjustment) after GPG decryption. GPG normally resists overwriting an existing output file, prompting an interactive user with a question like: "File `name.type' exists. Overwrite? (y/N)". "Overwrite" may appear to be safe, because a new file version will be created instead of actually overwriting the existing file. However, if the existing file has non-UNIX-like attributes ("Record format: Variable length", for example), then the new file will inherit the attributes of the old file, and the result may be a corrupt file, because the UNIX-like GPG code writes its output in ways which do not conform to the original file's record structure. Overwriting a Stream_LF file should be harmless. Unless "-o" ("--output") is used to specify an output file name, GPG expects to derive its output file name from its input file name by adding or removing a file name extension. For example, on a UNIX system, encrypting "fred.txt" normally produces "fred.txt.gpg". On VMS, this would emerge as "fred^.txt.gpg" on an ODS5 file system, or "FRED.TXT-GPG" on an ODS2 file system. Keyring backup files are always "XXXring.gpg_bak" instead of "XXXring.gpg~", as they would be on UNIX. Specifying files with version numbers will almost certainly confuse these programs. GPG uses a UNIX-like path, "/SYS$LOGIN/gnupg", to locate files like a user's keyrings. This may cause problems when the equivalence name for SYS$LOGIN is a search list, as it's likely to be, for example, for user SYSTEM ("SYS$LOGIN" = "SYS$SYSROOT:[SYSMGR]", where "SYS$SYSROOT" is a search list). A typical failure might look like this: gpg: can't create `/SYS$LOGIN/gnupg/pubring.gpg_tmp': no such file or directory gpg: error writing keyring `/SYS$LOGIN/gnupg/pubring.gpg': file open error To work around this problem, one can define the logical name GNUPGHOME, which overrides the default path, "/SYS$LOGIN/gnupg". Specify some suitable value which does not involve a search list. For example: define GNUPGHOME "/SYS$COMMON/SYSMGR/gnupg" Any user may define GNUPGHOME, but only a user for whom SYS$LOGIN involves a search list should need to do it. See notes below, under "Installation - Configuration Files" for more details involving GNUPGHOME. The password agent (gnupg-agent) features (as currently coded) require support for UNIX sockets, which is missing on VMS, so these features have been disabled ([.vms]config.h_vms: ENABLE_AGENT_SUPPORT). OpenPGP Card (smart card) support features have been disabled ([.vms]config.h_vms: ENABLE_CARD_SUPPORT). SHA-384 and SHA-512 digests are not available on VAX ([.vms] config.h_vms: USE_SHA512). The tests (in [.checks]) have not been run, as the automated test procedure requires a Bourne shell. The current VMS builder should create the [.tools] programs, and use them to generate the test data files (in the architecture-specific [.check.*] directory), but that's all. (Perhaps the GNV environment could be used to complete this.) Many features have not been tested. ------------------------------------------------------------------------ Building GnuPG on VMS --------------------- Extract the files from the distribution kit. The full kit includes objects and executables for Alpha, IA64, and VAX, in the corresponding host-specific subdirectories: [.ALPHAL] Alpha, with large-file support. [.ALPHAS] Alpha, without large-file support. [.IA64L] IA64, with large-file support. [.IA64S] IA64, without large-file support. [.VAX] VAX, where large-file support is not available. The unusual "S" suffix on non-VAX systems without large-file support is used to avoid collisions (on Alpha) with the [.mpi.alpha] directory in the source kit. These builds were done with optional large-file support (except VAX), and bzip2 compression support. LDAP support is also available on non-VAX systems. MMS or MMK is required. MMS commands are shown in the examples, but MMK should work. (An exception is for automatic dependency generation. See [.vms]descrip_mkdeps.mms for details.) Normally (starting in the [.vms] subdirectory, basic build): MMS ! Large-file on non-VAX, ! small-file on VAX. MMS /MACRO = (NOLARGE=1) ! Small-file on non-VAX. Instructions for various build options are included in the main builder file, [.vms]descrip.mms. The optional support for features like bzip2 compression and cURL support (see "Keyserver Programs", below) requires software which is not included in this kit. Large-file support is available only on non-VAX systems with a sufficiently recent C run-time library. LDAP support requires the shareable library, SYS$SHARE:LDAP$SHR.EXE. To avoid a lot of source code changes, the builders compile the code with the PTRMISMATCH1 warning disabled (where needed). This should have stopped all the compiler warnings. Keyserver Programs ------------------ GnuPG has options to allow transferring key data to and from key servers (--recv-keys, --search-keys, --send-keys). These options use a set of external helper programs, which are built as "[.keyserver.*]GPGKEYS_*.EXE". Two of these programs are self-contained, designed to handle a specific communication scheme: gpgkeys_finger and gpgkeys_ldap. Two others are intended to be linked with a cURL object library, if one is available: gpgkeys_curl and gpgkeys_hkp. These are always built using a GnuPG cURL emulation library. If true cURL support is enabled (by defining the MMS macro GPG_CURL at build time), then the "real cURL" versions of these programs will also be built. Presumably, the real cURL code allows gpgkeys_curl to support more schemes than the GnuPG cURL emulation does. If a cURL object library is specified, then various GPG LINK options depend on details of the cURL object library build. These are controlled by adding various MMS macro definitions to the MMS command line: - HP SSL: If the cURL object library was built with HP SSL support, then add "GPG_CURL_HP=1". - HP SSL1: If the cURL object library was built with HP SSL1 support, then add "GPG_CURL_HP1=1". - OpenSSL (shareable image): If the cURL object library was built with OpenSSL shareable images, then add "GPG_CURL_OE=1". - Kerberos: If the cURL object library was built with Kerberos support, then add "GPG_CURL_KERB=1". - /NAMES = AS_IS: If the cURL object library was built using /NAMES = AS_IS, then add "GPG_CURL_ASIS=1". See [.vms]descrip.mms for details.) PSWAPM Privilege ---------------- Use of the secure memory feature requires the privilege PSWAPM. This means that it will work only for an appropriately privileged user, or if the GPG executable is linked /NOTRACEBACK (the default) and INSTALLed with the appropriate privileges. A command to install the executable image should look like this: INSTALL ADD dev:[dir]GPG.EXE /PRIVILEGED = (PSWAPM) Without the PSWAPM privilege, you may expect GPG to emit warnings like these: gpg: WARNING: PSWAPM privilege is required for secure memory on VMS. gpg: WARNING: can't lock memory: insufficient privilege or object protection violation gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information Note that if the builder process lacks the PSWAPM privilege, then late in the build, when the builder runs the newly created GPG executable to generate the test data files, MMS tends to fail with various complaints (especially noisy on IA64) involving abnormal process termination. MMK tends to hang in this situation. CTRL/C will kill off the hung MMK run. With either MMS or MMK, re-running the build (repeatedly) will get all the test data files built, except for the final (and generally inconsequential) one, [.checks.*]PREPARED.STAMP. Whatever the problem is when PSWAPM is lacking, it seems to have no obvious effect outside of MMS or MMK; interactive GPG operation seems to be unaffected. ------------------------------------------------------------------------ Installation - Foreign Commands ------------------------------- GPG executables are created in architecture-specific subdirectories in the source tree ("[.g10.*]GPG*.EXE" and "[.keyserver.*]GPGKEYS_*.EXE", plus "[.vmslib.*]DECC_VER.EXE"). It may be desirable to move or copy all the important executables to some central (accessible) location. Set the symbols for the primary foreign commands: GPG :== $ actual_device:[actual.directory]GPG.EXE GPGV :== $ actual_device:[actual.directory]GPGV.EXE On non-VAX systems, with SET PROCESS /PARSE_STYLE = EXTENDED, GPG will preserve the case of the command line. On VAX systems (or with SET PROCESS /PARSE_STYLE = TRADITIONAL), command-line options and arguments with upper-case content must be quoted to avoid conversion to lower case by the C run-time library. Keyserver Programs ------------------ GnuPG has options to allow transferring key data to and from key servers (--recv-keys, --search-keys, --send-keys). These options use external helper programs, like the ones in the set of programs, "[.keyserver.*]GPGKEYS_*.EXE". On VMS, GPG expects to run these programs (using the C RTL "system()" function) using a command like "gpgkeys_XXX [option ...]", where "XXX" will be "curl" or some specific scheme name, like "finger", "hkp", or "ldap". This means that another set of DCL foreign command symbols must be defined to enable such commands to find the proper programs. In general, GPG will use "gpgkeys_curl" for all the schemes which do not have a known, scheme-specific program. For the FINGER, HKP, and (optional) LDAP schemes, GPG will use the scheme-specific program, "gpgkeys_finger", "gpgkeys_hkp", or "gpgkeys_ldap", respectively. Thus, multiple "gpgkeys_XXX" symbols may be needed: $ gpgkeys_finger :== $ actual_dev:[actual.dir]GPGKEYS_FINGER.EXE To use the programs built using GnuPG cURL emulation: $ gpgkeys_curl :== $ actual_dev:[actual.dir]GPGKEYS_CURL.EXE $ gpgkeys_hkp :== $ actual_dev:[actual.dir]GPGKEYS_HKP.EXE Or, if they were built, the programs built using the real cURL library: $ gpgkeys_curl :== $ actual_dev:[actual.dir]GPGKEYS_CURL_RC.EXE $ gpgkeys_hkp :== $ actual_dev:[actual.dir]GPGKEYS_HKP_RC.EXE If LDAP support was enabled: $ gpgkeys_ldap :== $ actual_dev:[actual.dir]GPGKEYS_LDAP.EXE Note that GPG attempts to verify that it can access any special "gpgkeys_XXX" program before it tries to use it. If it can't find the program (that is, on VMS, if the foreign command symbol is not defined, or if the program file itself can't be found), then it silently (!) falls back to using "gpgkeys_curl", which will probably fail with some obscure and uninformative error message. ------------------------------------------------------------------------ Installation - Configuration Files ---------------------------------- Configuration and Data File Locations: System-wide: /SYS$MANAGER/gnupg_share/ Individual user (keyrings, et c.): /SYS$LOGIN/gnupg/ Copy (and, optionally, customize) the [.g10]options.skel template GPG options file to the system-wide location: CREATE /DIRECTORY SYS$SYSROOT:[SYSMGR.GNUPG_SHARE] COPY /PROTECTION = W:RE [.g10]options.skel - SYS$SYSROOT:[SYSMGR.GNUPG_SHARE] This file will be copied (except for the first three lines) to a user's /SYS$LOGIN/gnupg/ directory the first time the user runs GPG. The [.gnupg] directory will be created under SYS$LOGIN, if it does not already exist. Note that GPG will automatically create a directory ([.gnupg]) only in the default home directory, SYS$LOGIN. If the user has defined GNUPGHOME, then the user is responsible for creating that directory. (This policy prevents GPG from trying to create directories or files in strange locations if a user defines GNUPGHOME badly.) For privacy, this directory must be accessible by only its owner. So, for example, the user SYSTEM might use commands like the following: define GNUPGHOME SYS$COMMON/SYSMGR/gnupg create /directory /protection = (G, W) SYS$COMMON:[SYSMGR.gnupg] The definition of GNUPGHOME would typically be added to the user's SYS$LOGIN:LOGIN.COM script. With GNUPGHOME defined, and the corresponding directory created, GPG should automatically copy SYS$SYSROOT:[SYSMGR.GNUPG_SHARE]options.skel to the user's GNUPGHOME directory the first time the user runs GPG, just as it would to the default location if GNUPGHOME were not defined. ------------------------------------------------------------------------ News ---- Version 1.4.22a 2018-04-15 --------------------------- - Update to GnuPG 1.4.22. - Added MMS option macros to the VMS builders to deal with variations in the way a cURL object library can be built (optionally used for some keyserver programs). For details, see [.vms]descrip.mms. - GPG_CURL_ASIS: cURL object library was built with /NAMES = AS_IS. - GPG_CURL_HP1: cURL object library was built using HP SSL1. - GPG_CURL_KERB: cURL object library was built with Kerberos support. [.vms]curl.h (new), [.vms]descrip.mms, [.vms]descrip_src.mms, [.vms]descrip_src_cmn_2.mms, [.vms]gpg_kerb.opt (new), [.vms]gpg_ssl_hp1.opt (new) - Changed the VMS builders to accommodate structure changes to [.cipher]. [.cipher]descrip_src.mms - Added more LIB$WAIT floating-point format code definitions when is not used (for VMS Alpha V6.x). [.vmslib]vms.c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.21a 2016-08-17 --------------------------- - Update to GnuPG 1.4.21. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.20a 2015-12-20 --------------------------- - Update to GnuPG 1.4.20. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.19a 2015-03-26 --------------------------- - Update to GnuPG 1.4.19. - Changed VMS builders: - Enable large-file support by default on Alpha and IA64 (with a run-time check on Alpha, using a new DCL script). Specify NOLARGE to disable large-file support on non-VAX systems. Specify LARGE explicitly to bypass the run-time check on Alpha. - Added a new MMS target, DASHV, to generate a "gpg --version" report using the local GPG.EXE executable. [.vms]check_large.com, [.vms]descrip.mms, [.vms]descrip_src.mms, [.vms]descrip_src_cmn_1.mms, [.vms]descrip_src_cmn_2.mms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.18a 2014-06-30 --------------------------- - Update to GnuPG 1.4.18. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.17a 2014-06-24 --------------------------- - Update to GnuPG 1.4.17. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.16a 2013-12-18 --------------------------- - Update to GnuPG 1.4.16. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.15a 2013-10-05 --------------------------- - Update to GnuPG 1.4.15. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.14a 2013-07-29 --------------------------- - Update to GnuPG 1.4.14. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.13a 2012-12-23 --------------------------- - Update to GnuPG 1.4.13. - Because the patents have expired, the real IDEA code ([.cipher]idea.c) is now present, and enabled. Edit [.vms]config.h_vms to disable it ("#define USE_IDEA 1"). if desired. - The automatic dependency generation description file now handles the generated header files better. (CLEAN_ALL deletes them, and they are generated when missing.) [.vms]descrip_mkdeps.mms. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.12b 2012-09-20 --------------------------- - Adjusted the builders, and added some dummy network-related functions to help building on VMS VAX versions before V7.0. Note that a successful build does not imply that all program features work properly. New MMS/MMK macros: DISABLE_WARNS, GPG_UCX. New C macros: LACK_LIBWAITDEF_H, GPG_UCX_OLD. (Old versions of MMS may have more trouble than newer versions of MMK. UCX V4.0 may have more problems than later (TCPIP) versions.) Typical usage: MMK /MACRO = (CDEFS_USER="LACK_LIBWAITDEF_H=1, GPG_UCX_OLD=1", - DISABLE_WARNS=PTRMISMATCH, GPG_UCX=1) [.cipher]descrip_src.mms, [.g10]descrip_src.mms, [.intl]descrip_src.mms, [.keyserver]descrip_src.mms, [.tools]descrip_src.mms, [.util]descrip_src.mms, [.vms]config.h_vms, [.vms]descrip.mms, [.vms]descrip_src.mms, [.vms]gpg_ucx.opt, [.vmslib]descrip_src.mms, [.vmslib]vms.c - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.12a 2012-01-31 --------------------------- - Update to GnuPG 1.4.12. The main-stream GnuPG 1.x code now includes all known VMS-related changes, so there are now no "changed-for-VMS" source files, only several "new-for-VMS" files, which are listed in another section of this document. Code changes in version 1.4.12 ("HAVE_UNSIGNED_TIME_T") appear to have cleared all the QUESTCOMPARE[1] informational complaints. [.vms]config.h_vms. - Revised (dummy) file locking code to accommodate main-stream changes. (No functional changes -- still no actual functionality.) [.vmslib]dotlock_vms.c. - Minor changes to the builders eliminate a spurious dependency file, "[.checks]DESCRIP_DEPS.MMS". [.vms]descrip.mms, [.vms]descrip_mkdeps.mms. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.11b 2011-09-08 --------------------------- - Fixed the "fix" in version 1.4.11a which added "ctx=stm" to some file open operations. Files created by GnuPG on a VMS system normally have Record format: Stream_LF, but files transferred by FTP to a VMS system can emerge with other record formats, and these can cause problems for a program like GnuPG with its UNIX-style-I/O expectations. The original complaint involved problems when reading binary files with fixed-512 record format. The "fix" in version 1.4.11a solved that problem, but introduced a new problem when reading text files (like ASCII-armored data) with variable-length record format. A typical symptom was spurious messages like: gpg: no valid OpenPGP data found. gpg: decrypt_message failed: eof The VMS-specific file open code now uses stat() to determine the record format of an input file, and then uses the "ctx=stm" option for files with fixed-length record format only. This should solve the original problem by using stream-mode access with fixed-512 binary files, while preserving the correct record-mode access with text files in stream or variable-length record format. [.vmslib]vms.c. - In a VMS batch job, an attempt to use the "terminal" (SYS$COMMAND) could get stuck in an endless loop. This situation should now result in the intended (fatal) error message, like: gpg: cannot open tty, `_ALP$DKC0:': no such file or directory [.util]ttyio.c. - In a VMS batch job, an attempt to do something interactive could trigger a "cannot open tty" (fatal) error (or cause the program to loop when it tried and failed to emit the error message). Now, in a VMS batch job, the default setting for the "--[no-]batch" option is "--batch". This seems to handle the known problem cases without explicit user action. The GnuPG documentation suggests that "--no-tty" may also be needed in some cases, but currently this is not set automatically. [.g10]gpg.c, [.vmslib]vms.c, [.vmslib]vms.h. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.11a 2010-10-22 --------------------------- - Update to GnuPG 1.4.11. The GnuPG developers have graciously included many VMS-related changes in the official source kit, so there are now (almost) no "changed-for-VMS" source files, only several "new-for-VMS" files, which are listed in another section of this document. - Fixed a problem (spurious I/O error messages, bad behavior) when reading input files with fixed-length records. (Added "ctx=stm" to appropriate [f]open() argument lists.) [.vmslib]vms.c. - Changed the builders to deal with changes to cURL on VMS on Alpha systems. Older cURL versions (version 7.19.7 or older?) used a "[.axp]" subdirectory, while newer ones use "[.alpha]". The new builders should detect and use either of the two expected subdirectories on Alpha systems. - Changed the builders to use [.ALPHAS] instead of plain [.ALPHA], and, for consistency, [.IA64S] instead of [.IA64], for product destination directories on non-VAX systems without large-file support. This change obviates renaming the [.mpi.alpha] directory in the standard source kit. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.10b 2010-08-20 --------------------------- - Changed various builders ("[...]descrip*.mms") to solve some build problems, and to add optional support for the IDEA algorithm. Changed the GPG_HPSSL option macro to GPG_CURL_HP, and added GPG_CURL_OE. Now, GPG_CURL_HP should be defined when using a cURL library which was built using HP SSL shared images, and GPG_CURL_OE should be defined when using a cURL library which was built using OpenSSL shared images. The names of OpenSSL shared images may vary with the OpenSSL kit, so some editing of the associated link options file, [.vms]gpg_ssl_open.opt, may be needed. See [.vms]descrip.mms for details. - Explicit "^" characters in file specifications in [.checks]descrip_src.mms ("pubring^.pkr.asc", "secring^.skr.asc") triggered (spurious) %MMS-E-CDDACCERR (and related) complaints from MMS V3.9-00. They're gone now. - Since version 1.4.8a, [.vms]config.h_vms had defined HAVE_BZIP2 unconditionally, instead of letting the builders do it (under user control), causing build problems (LINK warnings) if bzip2 support was not requested ("%LINK-I-UDFSYM, COMPRESS_FILTER_BZ2", ...). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.10a 2009-12-07 --------------------------- - Update to GnuPG 1.4.10. - Added VMS-specific code for faster file size determination when a UNIX-like file format makes the fstat() value accurate. [.vmslib]vms.c:vms_file_size(). - Added jacket header file [.vms]time.h, to add a prototype for [.util]timegm.c:timegm(). - Added simple auto-sensing of some version-dependent cURL functions in the builders. (There's still no true "configure" script, however.) - Kits are now packaged on an ODS5 file system, obviating [.vms]vms_name_fix.sh, which is no longer included. The builders have been revised to sense and cope with multi-dot file names on an ODS5 file system, or the altered file names which will be found on an ODS2 file system. The builders should emit a message like the following when ODS2-altered filenames are used: (Expecting ODS2 under-dot names for multi-dot file names.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.9b 2008-04-01 -------------------------- - Added some VMS-specific changes to RMS parameters to improve I/O speed. Now, principal file open operations use a callback function to set non-default RMS parameters: file extend quantity (deq) = 16384, multi-block count (mbc) = 127, and multi-buffer count (mbf) = 2. Explicitly set RMS_DEFAULT values override these built-in values. ("-vv" shows details at run-time.) - Added VMS-specific file-locking code for use with the random seed file (normally, "/SYS$LOGIN/gnupg/random_seed"). This should stop the annoying accumulation of multiple versions of this file. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.9a 2008-03-26 -------------------------- - Update to GnuPG 1.4.9. No VMS-specific code changes since version 1.4.8a. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.8a 2007-12-23 -------------------------- - Update to GnuPG 1.4.8. - Improved handling of file name suffixes, to reduce errors like: gpg: can't create `fred.txt.gpg': i/o error on ODS2 file systems, and (anywhere): gpg: fred.txt-gpg: unknown suffix - Fixed a problem enabling PSWAPM for GPG.EXE installed with that privilege. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.7a 2007-03-08 -------------------------- - Update to GnuPG 1.4.7. No VMS-specific code changes since version 1.4.6a. Some changes were needed in the builders and [.vms]config.h_vms, to cope with changes in the source files. [.vms]g10defs.h_vms has been removed. [.vms]libgnuintl.h_vms is now copied into both [.intl]libgnuintl.h and [.intl]libintl.h. Changes to "configure" have moved to "config.h_in" ("config.h.in"). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.6a 2006-12-06 -------------------------- - Update to GnuPG 1.4.6. No VMS-specific code changes since version 1.4.5a. - VMS builders should now produce all-upper-case binary files (.EXE, .OBJ, .OLB) on ODS5 file systems, matching the results on ODS2 file systems. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Version 1.4.5a 2006-07-09 -------------------------- - New. Probably needs work. ------------------------------------------------------------------------ Changes to Source Files ----------------------- Files changed for VMS: None. Files new for VMS: [.cipher] rndvms.c VMS-specific "entropy gathering" code. [.vms] bzlib.h Jacket header file for bzip2 support. (/NAMES = AS_IS.) cert_vms.h Header file with some otherwise missing items. check_large.com DCL script to check large-file support (on Alpha) collect_deps.com Dependency collector for descrip_mkdeps.mms. config.h_vms VMS-specific config.h. configmake.h Dummy configmake.h to satisfy (defective) [.intl]localcharset.c. curl.h Jacket header file for cURL support. (/NAMES = AS_IS.) descrip.mms Main MMK or MMS description ("make") file. descrip_config.mms Generated headers description file. descrip_mkdeps.mms Source dependency generator description file. descrip_src.mms Source list description file. descrip_src_cmn_1.mms Common description file (early). descrip_src_cmn_2.mms Common description file (late). descrip_src_flags.mms Compile and link flags description file. find_bzip2_lib.com bzip2 file location DCL script. gpg_kerb.opt LINK options file for the HP Kerberos shared image. (cURL-related.) gpg_ldap.opt LINK options file for the HP LDAP shared image. gpg_ssl_hp.opt LINK options file for the HP SSL shared images. (cURL-related.) gpg_ssl_hp1.opt LINK options file for the HP SSL1 shared images. (cURL-related.) gpg_ssl_open.opt LINK options file for the OpenSSL shared images. (cURL-related.) gpg_tcpip.opt LINK options file for the socket shared image. gpg_ucx.opt LINK options file for the (UCX) socket library or shared images. libgnuintl.h_vms VMS-specific [.intl]libgnuintl.h (and [.intl]libintl.h). mman.h Jacket header file for VMS. Adds prototype for [.vmslib]mlock_vms.c:mlock(). mod_dep.com Dependency modifier for descrip_mkdeps.mms. search.com MMS-compatible SEARCH DCL script. search_cm.com DCL script to extract a C macro value (cURL version information) from a source file. stream_lf.fdl FDL definition file for a Stream_LF file. time.h Jacket header file for VMS. Adds prototype for [.util]timegm.c:timegm(). vms_notes.txt These notes. [.vmslib] decc_ver.c Program to show versions: VMS, C compiler, C run-time library. dotlock_vms.c VMS-specific (currently dummy) replacements for the excessively UNIX-or-Windows functions in [.util]dotlock.c. mlock_vms.c VMS-specific mlock() implementation. vms.c Various VMS-specific code: DEC C run-time initialization, file name adjustment, file size determination, foreign command symbol checking, terminal echo control, fractional-second sleep. vms.h VMS-specific header file. Function prototypes for vms.c. [.] descrip*.mms Various MMS description files. ------------------------------------------------------------------------ The accompanying source kit was constructed on an ODS5 file system, so multi-dot or other ODS2-invalid file names should be preserved when extracted onto an ODS5 (or UNIX(-like)) file system. When extracted onto an ODS2 file system, these exotic file names should be simplified in the usual ways by a modern UnZip or VMSTAR program. The builders should sense the local situation and act accordingly without user intervention. When reporting problems, especially build problems, with GnuPG for VMS, it is often useful to reveal precise compiler, run-time library, and VMS version information. The program DECC_VER.C (included in the kit) is intended to make that easier. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode.info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547