On 09/22/2015 03:16 PM, Sam Tobin-Hochstadt wrote:
On Tue, Sep 22, 2015 at 9:04 AM Michael Wilber <wilmic1...@gmail.com> wrote:

Thank you for disclosing these vulnerabilities! Responsible disclosure
helps everyone.

Sam Tobin-Hochstadt <sa...@cs.indiana.edu> writes:
* Check any packages you have uploaded to the site, to ensure that no
unexpected changes have been made to them.

Is package signing on Racket's roadmap? The only way to protect against
these kinds of attacks is to have clients verify package signatures.
Every major Linux package manager now does this. I think it's at least
worth seriously considering.


This is definitely worth considering. I know people have thought about it,
but I don't think it's on anyone's near-term roadmap that I know of -- but
maybe someone's working on it an planning to speak up.

If you want something like GPG but simpler, take a look to signify. It was created by an OpenBSD developer and is used to sign the OpenBSD releases and snapshots.

http://www.openbsd.org/papers/bsdcan-signify.html
http://www.tedunangst.com/flak/post/signify


One challenge here is that the majority of the packages on the site are
pointers to GitHub, which update continuously. That means we could sign the
GitHub reference, but not the package contents, unlike in a Linux
distribution where they sign the actual package you download.That might
still be worth it, though.

I have an idea for packages which use a git repo. You could add an option to raco to generate a file with the sha256 checksum of every file in the repo (or maybe to add the hashes to info.rkt), then to sign the git sha reference and the file with the checksums in the server. raco could install two versions of each package, the latest signed checkout (it would be the default) and the HEAD (raco pkg --insecure).

If the developers want to update the version signed in the pkg server, they only need to regenerate the checksum file, to sign it locally and to commit the changes.

The server would check everyday each repo for changes in the checksum files. If it find any change in that file, then it downloads the git repo and checks the checksums and signed files.

As always, the ideas are cheap but the code is the hard part :)



One question: If an attacker was able to access the server under the
privileges of the package website, what's stopping them from just
silently uploading a change and then removing that entry from the
"Package Changes" list?


That is certainly a possibility, and it's why we can't rule out a
compromise even though we have no evidence for one. We recommend that you
look at the actual contents of your package entries on the server, and make
sure that they're correct.

Sam



--
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 racket-dev+unsubscr...@googlegroups.com.
To post to this group, send email to racket-dev@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-dev/mtvj2p%24fo3%242%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to