jabronson wrote on 12/22/2015 10:26 PM:
On Sun, Dec 20, 2015 at 1:53 PM, Neil Van Dyke <[email protected]
<mailto:[email protected]>> wrote:
HTTPS should be the default for Racket package directory Web and
webservice requests, and for any Racket server stuff that
*requires* privileged access -- just as good practice, on balance.
[...]
I'm glad Racket is moving to distributing software securely. Ideally
it would also be signed, and checksums would be published too.
Simple per-author package signing might be good, though it can be
burdensome when package authors go to the work to use good key
management. (Racket third-party package releases have moved more
towards casual "here's my Git URL; guess I'm done", so we might have to
shake up current expectations of minimal practices for version releases,
before I think we could hope for many authors to keep their keys
passably secure, and also not lose the keys.)
I'm sure signing has been suggested a few times for Racket package
systems, and the first hit I got in Google was actually by me:
"http://lists.racket-lang.org/users/archive/2003-March/002004.html" says:
[...] Speaking of the author as a semi-trusted authority, there's a
truly nasty threat in network software distribution systems of
trojaned code,which we need to acknowledge. The biggest risk may be
when author A's package is well-established and widely used, so bad
guy B uploads a trojaned update. Very simple GnuPG signing of
packages by the authors would be a good way to reduce this threat.
The CSPAN user update program could automatically verify the
signature, and the author program could offer to sign the package
before uploading to CSPAN. There need not even be a centralized key
ring -- simply knowing that the same key that signed your current
version signed the new version would make things harder for a badguy.
Signing doesn't need to be in the first release of CSPAN tools, but I
think they should be designed to easily accomodate author-signing
later. (I'm intentionally avoiding the idea of bureaucratic signing
by separate reviewers, etc.) [...]
(I think "CSPAN" was probably an earlier name of the cleverly-named
"PLaneT", which was the first Racket package system.)
Later, I had some actual research-y ideas about how to increase package
security confidence with PLaneT, but that got interrupted.
(BTW, "Xc*d*Gh*st" was a great "Reflections on Trusting Trust" example,
as you say, and indeed is relevant to distributions of core Racket.
However, assuming that none of the app developers was complicit, HTTPS
of course wouldn't have helped the developers, if the downloadable
software was already compromised on the server. And official checksums
for "mirrored" software copies might not helped in this case, such as
(hypothetically) if one checks against an official checksum that was
conveyed to one -- even via HTTPS from a believed-legitimate authority
-- but one's adversary controls one's Internet pipe and a trusted CA.
And that's before we get to the possibility of developers' machines
being compromised, which isn't so unlikely. It's good to be reminded
that even simple things in security are difficult.)
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/567A3120.3000702%40neilvandyke.org.
For more options, visit https://groups.google.com/d/optout.