suzanne.soy/fork-openpgpjs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Enables JSDoc Markdown Plugin

Browse Source
This commit is contained in:
Mahrud Sayrafi 2018-02-28 14:13:27 -08:00
parent 7eef65926a
commit 9275119dbc
No known key found for this signature in database
GPG Key ID: C24071B956C3245F
23 changed files with 100 additions and 1545 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.jsdocrc.js Normal file
View File

@ -0,0 +1,3 @@
module.exports = {
plugins: ['plugins/markdown']
};

1
Gruntfile.js
View File

@ -181,6 +181,7 @@ module.exports = function(grunt) {
dist: {
src: ['README.md', 'src'],
options: {
configure: '.jsdocrc.js',
destination: 'doc',
recurse: true
}

1472
src/crypto/hash/sha.js
View File

File diff suppressed because it is too large Load Diff

53
src/enums.js
View File

@ -192,37 +192,44 @@ export default {
signature: {
/** 0x00: Signature of a binary document. */
binary: 0,
/** 0x01: Signature of a canonical text document.<br/>
/** 0x01: Signature of a canonical text document.
*
* Canonicalyzing the document by converting line endings. */
text: 1,
/** 0x02: Standalone signature.<br/>
/** 0x02: Standalone signature.
*
* This signature is a signature of only its own subpacket contents.
* It is calculated identically to a signature over a zero-lengh
* binary document. Note that it doesn't make sense to have a V3
* standalone signature. */
standalone: 2,
/** 0x10: Generic certification of a User ID and Public-Key packet.<br/>
/** 0x10: Generic certification of a User ID and Public-Key packet.
*
* The issuer of this certification does not make any particular
* assertion as to how well the certifier has checked that the owner
* of the key is in fact the person described by the User ID. */
cert_generic: 16,
/** 0x11: Persona certification of a User ID and Public-Key packet.<br/>
/** 0x11: Persona certification of a User ID and Public-Key packet.
*
* The issuer of this certification has not done any verification of
* the claim that the owner of this key is the User ID specified. */
cert_persona: 17,
/** 0x12: Casual certification of a User ID and Public-Key packet.<br/>
/** 0x12: Casual certification of a User ID and Public-Key packet.
*
* The issuer of this certification has done some casual
* verification of the claim of identity. */
cert_casual: 18,
/** 0x13: Positive certification of a User ID and Public-Key packet.<br/>
/** 0x13: Positive certification of a User ID and Public-Key packet.
*
* The issuer of this certification has done substantial
* verification of the claim of identity.<br/>
* <br/>
* verification of the claim of identity.
*
* Most OpenPGP implementations make their "key signatures" as 0x10
* certifications. Some implementations can issue 0x11-0x13
* certifications, but few differentiate between the types. */
cert_positive: 19,
/** 0x30: Certification revocation signature<br/>
/** 0x30: Certification revocation signature
*
* This signature revokes an earlier User ID certification signature
* (signature class 0x10 through 0x13) or direct-key signature
* (0x1F). It should be issued by the same key that issued the
@ -231,7 +238,8 @@ export default {
* revokes, and should have a later creation date than that
* certificate. */
cert_revocation: 48,
/** 0x18: Subkey Binding Signature<br/>
/** 0x18: Subkey Binding Signature
*
* This signature is a statement by the top-level signing key that
* indicates that it owns the subkey. This signature is calculated
* directly on the primary key and subkey, and not on any User ID or
@ -240,12 +248,13 @@ export default {
* contains a 0x19 signature made by the signing subkey on the
* primary key and subkey. */
subkey_binding: 24,
/** 0x19: Primary Key Binding Signature<br/>
/** 0x19: Primary Key Binding Signature
*
* This signature is a statement by a signing subkey, indicating
* that it is owned by the primary key and subkey. This signature
* is calculated the same way as a 0x18 signature: directly on the
* primary key and subkey, and not on any User ID or other packets.<br/>
* <br/>
* primary key and subkey, and not on any User ID or other packets.
*
* When a signature is made over a key, the hash data starts with the
* octet 0x99, followed by a two-octet length of the key, and then body
* of the key packet. (Note that this is an old-style packet header for
@ -254,7 +263,8 @@ export default {
* the subkey using the same format as the main key (also using 0x99 as
* the first octet). */
key_binding: 25,
/** 0x1F: Signature directly on a key<br/>
/** 0x1F: Signature directly on a key
*
* This signature is calculated directly on a key. It binds the
* information in the Signature subpackets to the key, and is
* appropriate to be used for subpackets that provide information
@ -263,27 +273,30 @@ export default {
* about the key itself, rather than the binding between a key and a
* name. */
key: 31,
/** 0x20: Key revocation signature<br/>
/** 0x20: Key revocation signature
*
* The signature is calculated directly on the key being revoked. A
* revoked key is not to be used. Only revocation signatures by the
* key being revoked, or by an authorized revocation key, should be
* considered valid revocation signatures.a */
key_revocation: 32,
/** 0x28: Subkey revocation signature<br/>
/** 0x28: Subkey revocation signature
*
* The signature is calculated directly on the subkey being revoked.
* A revoked subkey is not to be used. Only revocation signatures
* by the top-level signature key that is bound to this subkey, or
* by an authorized revocation key, should be considered valid
* revocation signatures.<br/>
* <br/>
* revocation signatures.
*
* Key revocation signatures (types 0x20 and 0x28)
* hash only the key being revoked. */
subkey_revocation: 40,
/** 0x40: Timestamp signature.<br/>
/** 0x40: Timestamp signature.
* This signature is only meaningful for the timestamp contained in
* it. */
timestamp: 64,
/** 0x50: Third-Party Confirmation signature.<br/>
/** 0x50: Third-Party Confirmation signature.
*
* This signature is a signature over some other OpenPGP Signature
* packet(s). It is analogous to a notary seal on the signed data.
* A third-party signature SHOULD include Signature Target

6
src/key.js
View File

@ -514,8 +514,10 @@ function getExpirationTime(keyPacket, selfCertificate, defaultValue=null) {
/**
* Returns primary user and most significant (latest valid) self signature
* - if multiple users are marked as primary users returns the one with the latest self signature
* - if no primary user is found returns the user with the latest self signature
* - if multiple primary users exist, returns the one with the latest self signature
* - otherwise, returns the user with the latest self signature
*
* NOTE: call verifyPrimaryUser before calling this function.
* @param {Date} date use the given date for verification instead of the current time
* @return {{user: Array<module:packet/User>, selfCertificate: Array<module:packet/signature>}|null} The primary user and the self signature
*/

7
src/packet/compressed.js
View File

@ -16,9 +16,10 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of the Compressed Data Packet (Tag 8)<br/>
* <br/>
* {@link https://tools.ietf.org/html/rfc4880#section-5.6|RFC4880 5.6}: The Compressed Data packet contains compressed data. Typically,
* Implementation of the Compressed Data Packet (Tag 8)
*
* {@link https://tools.ietf.org/html/rfc4880#section-5.6|RFC4880 5.6}:
* The Compressed Data packet contains compressed data. Typically,
* this packet is found as the contents of an encrypted packet, or following
* a Signature or One-Pass Signature packet, and contains a literal data packet.
* @requires compression/zlib

9
src/packet/literal.js
View File

@ -16,10 +16,11 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of the Literal Data Packet (Tag 11)<br/>
* <br/>
* {@link https://tools.ietf.org/html/rfc4880#section-5.9|RFC4880 5.9}: A Literal Data packet contains the body of a message; data that
* is not to be further interpreted.
* Implementation of the Literal Data Packet (Tag 11)
*
* {@link https://tools.ietf.org/html/rfc4880#section-5.9|RFC4880 5.9}:
* A Literal Data packet contains the body of a message; data that is not to be
* further interpreted.
* @requires enums
* @requires util
* @module packet/literal

12
src/packet/marker.js
View File

@ -15,15 +15,15 @@
// License along with this library; if not, write to the Free Software
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of the strange "Marker packet" (Tag 10)<br/>
* <br/>
* {@link https://tools.ietf.org/html/rfc4880#section-5.8|RFC4880 5.8}: An experimental version of PGP used this packet as the Literal
* Implementation of the strange "Marker packet" (Tag 10)
*
* {@link https://tools.ietf.org/html/rfc4880#section-5.8|RFC4880 5.8}:
* An experimental version of PGP used this packet as the Literal
* packet, but no released version of PGP generated Literal packets with this
* tag. With PGP 5.x, this packet has been reassigned and is reserved for use as
* the Marker packet.<br/>
* <br/>
* the Marker packet.
*
* Such a packet MUST be ignored when received.
* @requires enums
* @module packet/marker

9
src/packet/one_pass_signature.js
View File

@ -16,14 +16,15 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of the One-Pass Signature Packets (Tag 4)<br/>
* <br/>
* {@link https://tools.ietf.org/html/rfc4880#section-5.4|RFC4880 5.4}: The One-Pass Signature packet precedes the signed data and contains
* Implementation of the One-Pass Signature Packets (Tag 4)
*
* {@link https://tools.ietf.org/html/rfc4880#section-5.4|RFC4880 5.4}:
* The One-Pass Signature packet precedes the signed data and contains
* enough information to allow the receiver to begin calculating any
* hashes needed to verify the signature. It allows the Signature
* packet to be placed at the end of the message, so that the signer
* can compute the entire signed message in one pass.
* @requires util
* @requires util
* @requires enums
* @requires type/keyid
* @module packet/one_pass_signature

4
src/packet/public_key.js
View File

@ -16,8 +16,8 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of the Key Material Packet (Tag 5,6,7,14)<br/>
* <br/>
* Implementation of the Key Material Packet (Tag 5,6,7,14)
*
* {@link https://tools.ietf.org/html/rfc4880#section-5.5|RFC4480 5.5}:
* A key material packet contains all the information about a public or
* private key. There are four variants of this packet type, and two

7
src/packet/public_key_encrypted_session_key.js
View File

@ -16,9 +16,10 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Public-Key Encrypted Session Key Packets (Tag 1)<br/>
* <br/>
* {@link https://tools.ietf.org/html/rfc4880#section-5.1|RFC4880 5.1}: A Public-Key Encrypted Session Key packet holds the session key
* Public-Key Encrypted Session Key Packets (Tag 1)
*
* {@link https://tools.ietf.org/html/rfc4880#section-5.1|RFC4880 5.1}:
* A Public-Key Encrypted Session Key packet holds the session key
* used to encrypt a message. Zero or more Public-Key Encrypted Session Key
* packets and/or Symmetric-Key Encrypted Session Key packets may precede a
* Symmetrically Encrypted Data Packet, which holds an encrypted message. The

4
src/packet/secret_key.js
View File

@ -16,8 +16,8 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of the Key Material Packet (Tag 5,6,7,14)<br/>
* <br/>
* Implementation of the Key Material Packet (Tag 5,6,7,14)
*
* {@link https://tools.ietf.org/html/rfc4880#section-5.5|RFC4480 5.5}:
* A key material packet contains all the information about a public or
* private key. There are four variants of this packet type, and two

4
src/packet/signature.js
View File

@ -16,8 +16,8 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of the Signature Packet (Tag 2)<br/>
* <br/>
* Implementation of the Signature Packet (Tag 2)
*
* {@link https://tools.ietf.org/html/rfc4880#section-5.2|RFC4480 5.2}:
* A Signature packet describes a binding between some public key and
* some data. The most common signatures are a signature of a file or a

5
src/packet/sym_encrypted_integrity_protected.js
View File

@ -16,9 +16,8 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of the Sym. Encrypted Integrity Protected Data
* Packet (Tag 18)<br/>
* <br/>
* Implementation of the Sym. Encrypted Integrity Protected Data Packet (Tag 18)
*
* {@link https://tools.ietf.org/html/rfc4880#section-5.13|RFC4880 5.13}:
* The Symmetrically Encrypted Integrity Protected Data packet is
* a variant of the Symmetrically Encrypted Data packet. It is a new feature

7
src/packet/sym_encrypted_session_key.js
View File

@ -16,9 +16,10 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Public-Key Encrypted Session Key Packets (Tag 1)<br/>
* <br/>
* {@link https://tools.ietf.org/html/rfc4880#section-5.1|RFC4880 5.1}: A Public-Key Encrypted Session Key packet holds the session key
* Public-Key Encrypted Session Key Packets (Tag 1)
*
* {@link https://tools.ietf.org/html/rfc4880#section-5.1|RFC4880 5.1}:
* A Public-Key Encrypted Session Key packet holds the session key
* used to encrypt a message. Zero or more Public-Key Encrypted Session Key
* packets and/or Symmetric-Key Encrypted Session Key packets may precede a
* Symmetrically Encrypted Data Packet, which holds an encrypted message. The

9
src/packet/symmetrically_encrypted.js
View File

@ -16,10 +16,11 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of the Symmetrically Encrypted Data Packet (Tag 9)<br/>
* <br/>
* {@link https://tools.ietf.org/html/rfc4880#section-5.7|RFC4880 5.7}: The Symmetrically Encrypted Data packet contains data encrypted
* with a symmetric-key algorithm. When it has been decrypted, it contains other
* Implementation of the Symmetrically Encrypted Data Packet (Tag 9)
*
* {@link https://tools.ietf.org/html/rfc4880#section-5.7|RFC4880 5.7}:
* The Symmetrically Encrypted Data packet contains data encrypted with a
* symmetric-key algorithm. When it has been decrypted, it contains other
* packets (usually a literal data packet or compressed data packet, but in
* theory other Symmetrically Encrypted Data packets or sequences of packets
* that form whole OpenPGP messages).

6
src/packet/user_attribute.js
View File

@ -16,15 +16,15 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of the User Attribute Packet (Tag 17)<br/>
* <br/>
* Implementation of the User Attribute Packet (Tag 17)
*
* The User Attribute packet is a variation of the User ID packet. It
* is capable of storing more types of data than the User ID packet,
* which is limited to text. Like the User ID packet, a User Attribute
* packet may be certified by the key owner ("self-signed") or any other
* key owner who cares to certify it. Except as noted, a User Attribute
* packet may be used anywhere that a User ID packet may be used.
* <br/>
*
* While User Attribute packets are not a required part of the OpenPGP
* standard, implementations SHOULD provide at least enough
* compatibility to properly handle a certification signature on the

4
src/packet/userid.js
View File

@ -16,8 +16,8 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of the User ID Packet (Tag 13)<br/>
* <br/>
* Implementation of the User ID Packet (Tag 13)
*
* A User ID packet consists of UTF-8 text that is intended to represent
* the name and email address of the key holder. By convention, it
* includes an RFC 2822 [RFC2822] mail name-addr, but there are no

4
src/type/ecdh_symkey.js
View File

@ -16,8 +16,8 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Encoded symmetric key for ECDH<br/>
* <br/>
* Encoded symmetric key for ECDH
*
* @requires util
* @module type/ecdh_symkey
*/

4
src/type/kdf_params.js
View File

@ -16,8 +16,8 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of type KDF parameters RFC 6637<br/>
* <br/>
* Implementation of type KDF parameters RFC 6637
*
* @requires enums
* @module type/kdf_params
*/

5
src/type/keyid.js
View File

@ -16,8 +16,9 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of type key id ({@link https://tools.ietf.org/html/rfc4880#section-3.3|RFC4880 3.3})<br/>
* <br/>
* Implementation of type key id
*
* {@link https://tools.ietf.org/html/rfc4880#section-3.3|RFC4880 3.3}:
* A Key ID is an eight-octet scalar that identifies a key.
* Implementations SHOULD NOT assume that Key IDs are unique. The
* section "Enhanced Key Formats" below describes how Key IDs are

5
src/type/oid.js
View File

@ -17,8 +17,9 @@
/**
* Wrapper to an OID value
* <br/>
* An object identifier type from {@link https://tools.ietf.org/html/rfc6637#section-11|RFC6637, section 11}.
*
* An object identifier type from
* {@link https://tools.ietf.org/html/rfc6637#section-11|RFC6637, section 11}.
* @requires util
* @requires enums
* @module type/oid

5
src/type/s2k.js
View File

@ -16,8 +16,9 @@
// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
/**
* Implementation of the String-to-key specifier ({@link https://tools.ietf.org/html/rfc4880#section-3.7|RFC4880 3.7})<br/>
* <br/>
* Implementation of the String-to-key specifier
*
* {@link https://tools.ietf.org/html/rfc4880#section-3.7|RFC4880 3.7}:
* String-to-key (S2K) specifiers are used to convert passphrase strings
* into symmetric-key encryption/decryption keys. They are used in two
* places, currently: to encrypt the secret part of private keys in the