jabronson wrote on 12/23/2015 05:45 PM:
(XcodeGhost highlights the importance of code signing or validating
the checksum of an insecure download—e.g. one retrieved over http, or
from an unofficial mirror
[...]
- https://wiki.debian.org/SecureApt
- https://en.wikipedia.org/wiki/Gatekeeper_(OS_X)
<https://en.wikipedia.org/wiki/Gatekeeper_%28OS_X%29>
- https://wiki.mozilla.org/Add-ons/Extension_Signing
- etc.
If you're saying that core Racket should participate in OS/distro
vendor's signing system for the download of core Racket, that sounds OK.
If you're saying that Racket should have a signing system for
third-party packages, I've advocated that myself -- *but* it is
important to have an *appropriate* signing system, not merely *a*
signing system, and this is harder than it seems, especially if starting
with bad-influence role models.
The Debian approach is fine for Debian (it's worked OK for a long time,
and isn't snoopy or too authoritarian, and it pushes Debian's security
weak-links elsewhere), though not a drop-in for third-party Racket
packages. The proposed Mozilla signing system is creepy in context
(especially when you consider what pressures Mozilla is under, and some
of the pressures they seem likely to be under in the future, and
considering their spotty track record), and I'd suspect that the FSF
will have renewed interest in a Firefox fork because of this. Regarding
OS X Gatekeeper, I don't know how Apple is currently using that on OS X,
but students should look at the history of how Apple has used the iOS
App Store approval process and retroactive deletion in an abusive and
anticompetitive way (which has been a big deal, and should be a textbook
case, despite its omission from the Wikipedia page) -- it's arguably
first about strangehold middleman revenue and ongoing competition
elimination, and only second about security/quality/brand control.
One of the reasons I mention this is due to the education-heavy slant of
the Racket community. There is a cliché in IT security (actually
pervading many aspects of IT, but perhaps most painful in security), of
thinking "X will solve this security problem", which might or might not
be true, and then proceeding to do X in a very wrong way. For example,
I think Schneier's introductory crypto book is one that points out,
something like, homebrew applications of crypto seem to inevitably be
incorrect, and I've seen many real-world examples of this. What it
often reduces to is people not understanding the tools they're trying to
work with: like someone being sick, and thinking they need "medicine",
and they know that a particular antibiotic is strong. Or someone
needing to clean the floors, and thinking making a cleaning solution
from bleach and ammonia will work even better. These sound ridiculous,
but so is how IT security is usually implemented. Students should
appreciate this reality, and how it affects the industry examples they
see, and know that they have to work actively to avoid the bad practices
in their own work.
Even Racket is not immune to mistakes of enthusiasm and overconfidence
-- and everyone has made, and will occasionally continue to make,
mistakes of this kind. But security/privacy (and impositions on users
and volunteers) are some of the last places we least want to make big
mistakes. So, when we think "we need X security", I think there's a
burden on us to understand the problem well. And, bad prevailing
practices mean that we might also want to communicate that understanding.
Neil V.
--
You received this message because you are subscribed to the Google Groups "Racket
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-dev/567B4E6D.6070407%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.
