wheel rationales
This commit is contained in:
parent
a4b9ddb83c
commit
4fc723131b
15
pep-0427.txt
15
pep-0427.txt
|
@ -235,7 +235,7 @@ Signed wheel files
|
|||
------------------
|
||||
|
||||
Wheel files include an extended RECORD that enables digital
|
||||
signatures. PEP 376's RECORD is altered to include
|
||||
signatures. PEP 376's RECORD is altered to include a secure hash
|
||||
``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64
|
||||
encoding with no trailing = characters) as the second column instead
|
||||
of an md5sum. All possible entries are hashed, including any
|
||||
|
@ -316,6 +316,19 @@ Why does wheel include attached signatures?
|
|||
the signature, or individual files can be verified without having
|
||||
to download the whole archive.
|
||||
|
||||
Why does wheel allow JWS signatures?
|
||||
The JOSE specifications including JWS are designed to be easy to
|
||||
implement, a feature that is also one of wheel's primary design goals.
|
||||
|
||||
Why does wheel also allow S/MIME signatures?
|
||||
S/MIME signatures are allowed for users who need or want to use an
|
||||
existing public key infrastructure with wheel.
|
||||
|
||||
Signed packages are only a basic building block in a secured package
|
||||
update system. Wheel only provides the building block. A complete
|
||||
system would provide for key distribution and trust and would specify
|
||||
which signature format was required.
|
||||
|
||||
Appendix
|
||||
========
|
||||
|
||||
|
|
Loading…
Reference in New Issue