PEP 427: remove signing algorithms
This commit is contained in:
Daniel Holth
parent
4718959dd8
commit
895121b37d
89
pep-0427.txt
89
pep-0427.txt
|
|
@ -243,57 +243,24 @@ generated files such as .pyc files, but not RECORD. For example::
|
|||
file.py,sha256=AVTFPZpEKzuHr7OvQZmhaU3LvwKz06AJw8mT\_pNh2yI,3144
|
||||
distribution-1.0.dist-info/RECORD,,
|
||||
|
||||
RECORD.jws is not mentioned in RECORD at all. Every other file in the
|
||||
archive must have a correct hash in RECORD, or the installation will
|
||||
fail.
|
||||
The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in
|
||||
RECORD at all since they can only be added after RECORD is generated.
|
||||
Every other file in the archive must have a correct hash in RECORD,
|
||||
or the installation will fail.
|
||||
|
||||
The signature format is derived from the JSON Web Signatures (JWS)
|
||||
specification. One or more JSON Web Signature JSON Serialization (JWS-JS)
|
||||
signatures may be stored in a file RECORD.jws adjacent to RECORD.
|
||||
|
||||
A signature-aware installer could be instructed to check for a
|
||||
particular Ed25519 public key by using an extended "extras" syntax.::
|
||||
|
||||
# request a normal optional feature "extra", and indicate
|
||||
# the package should be signed by a particular
|
||||
# urlsafe-b64encode-nopad encoded ed25519 public key:
|
||||
package[extra, ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA]
|
||||
|
||||
An application could distribute a requires.txt file with many such lines
|
||||
for all its dependencies and their public keys. By installing from this
|
||||
file an application's users can know they are getting packages from the
|
||||
same publishers.
|
||||
|
||||
Applications that wish to "fail open" for backwards compatibility with
|
||||
non-signature-aware installers should specify that their package
|
||||
provides the extra ``ed25519=(key)`` with no associated dependencies.
|
||||
|
||||
|
||||
JSON Web Signatures Extensions
|
||||
''''''''''''''''''''''''''''''
|
||||
|
||||
The Ed25519 algorithm is used as an extension to the JSON Web Signatures
|
||||
specification. Wheel uses ``alg="Ed25519"`` in the header. The key
|
||||
attribute holds the signature's public JSON Web Key. In JSON Web Key
|
||||
/ JSON Private Key the Ed25519 verifying (public) key is called vk and
|
||||
the signing (private) key is called sk.
|
||||
|
||||
Example header::
|
||||
|
||||
{
|
||||
"alg": "Ed25519",
|
||||
"jwk": {
|
||||
"alg": "Ed25519",
|
||||
"vk": "tmAYCrSfj8gtJ10v3VkvW7jOndKmQIYE12hgnFu3cvk"
|
||||
}
|
||||
}
|
||||
|
||||
Example payload, always the SHA-256 hash of RECORD::
|
||||
If JSON web signatures are used, one or more JSON Web Signature JSON
|
||||
Serialization (JWS-JS) signatures may be stored in a file RECORD.jws
|
||||
adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256
|
||||
hash of RECORD as the JWS payload::
|
||||
|
||||
{ "hash": "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" }
|
||||
|
||||
A future version of wheel may include timestamps in the payload or in
|
||||
the signature.
|
||||
If RECORD.p7s is used, it must contain a PKCS#7 format signature of
|
||||
RECORD.
|
||||
|
||||
A wheel installer may assume that the signature has already been checked
|
||||
against RECORD, and only must verify the hashes in RECORD against the
|
||||
extracted file contents.
|
||||
|
||||
See
|
||||
|
||||
|
|
@ -301,7 +268,6 @@ See
|
|||
- http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html
|
||||
- http://self-issued.info/docs/draft-ietf-jose-json-web-key.html
|
||||
- http://self-issued.info/docs/draft-jones-jose-json-private-key.html
|
||||
- http://ed25519.cr.yp.to/
|
||||
|
||||
|
||||
Comparison to .egg
|
||||
|
|
@ -342,27 +308,12 @@ Wheel defines a .data directory. Should I put all my data there?
|
|||
resource)`` even though *those* files will usually not be distributed
|
||||
in *wheel's* ``.data`` directory.
|
||||
|
||||
Why are you using Ed25519 and JWS instead of PGP, S/MIME, or ECDSA?
|
||||
Wheel's signing scheme is designed to protect against cryptography
|
||||
that is not used. The system yields a tiny, performant pure-Python
|
||||
implementation that can just be included with the reference installer.
|
||||
The 32-byte public keys are convienent to share directly in the
|
||||
same way you would share a SHA-256 digest. Since the signatures
|
||||
are inside the archive itself, they are more likely to be present
|
||||
at install time compared to detached signatures.
|
||||
|
||||
Wheel's signing system is designed to be used more like an md5 sum
|
||||
or a secure hash used to verify the integrity of an archive than
|
||||
something like PGP or X.509 signatures. A secure hash can verify
|
||||
the integrity of a single archive, but a wheel signing key verifies
|
||||
the signer of all packages signed with that key. Once you know to
|
||||
expect a particular signing key, a signature-verifying installer
|
||||
protects you from installing anything but intact packages from the
|
||||
expected signers. It makes no difference whether the wrong packages
|
||||
come from choosing the wrong package index, disk corruption, or an
|
||||
actual attack; if a package is not signed with the expected key,
|
||||
with its file contents matching their hashes in RECORD, then it will
|
||||
not be installed.
|
||||
Why does wheel include attached signatures?
|
||||
Attached signatures are more convenient than detached signatures
|
||||
because they travel with the archive. Since only the individual files
|
||||
are signed, the archive can be recompressed without invalidating
|
||||
the signature, or individual files can be verified without having
|
||||
to download the whole archive.
|
||||
|
||||
Appendix
|
||||
========
|
||||
|
|
|
|||
Loading…
Reference in New Issue