On 3 January 2015 at 01:31, Paul Moore <p.f.moore@gmail.com> wrote:
On 2 January 2015 at 14:25, Donald Stufft <donald@stufft.io> wrote:
> Either way though, I suggest focus on PEP 458 (with an eye towards not
> making any decisions which will require changes on the client side to implement
> PEP 480).

+1 on all of this.

I agree that PEP 458 is (relatively speaking) an obvious thing to do,
and if the people who have to do the work for it are happy, I think it
should just go ahead.

I'd like to see the PEPs reworded a bit to be less intimidating to the
non-specialist. For PEPs about the trust model for PyPI, it's ironic
that I have to place a lot of trust in the PEP authors simply because
I don't understand half of what they are saying ;-)

FWIW, Niels Ferguson's and Bruce Scheier's "Practical Cryptography" was probably the single most enlightening book I've read on the topic. The NIST standards in this area are also genuinely excellent (the occasional less than ideal technical recommendation from certain government agencies notwithstanding), and if you can afford the paywall (or work for an organisation that can do so), actually reading relevant sections of IEEE 802.11i was a key part of my own learning. (My specific interest was in authentication protocols for access control, hence why I was reading the Wi-Fi WPA2 spec, but a lot of the underlying cryptographic concepts are shared between the different kinds of digital verification)

For broader context, Schneier's "Secrets and Lies" is good from a technical perspective, while the more recent "Liars and Outliers" looks to situate the security mindset in a broader social environment. There's a reason Schneier is as well respected as he is - if you're ever looking for general advice on how to be pragmatically paranoid, then he's a great source to turn to.

That said, while I doubt we're going to be able to completely de-jargonise the PEP details, I agree it would be worthwhile to ensure there's a clear explanation of the practical consequences for folks that we'd otherwise lose in the cryptographic weeds.


Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia