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.

Reply via email to