Hi Alex > How is your signing proposal different than the signing process already available in Maven and in use in (for example) Maven Central repository (and in use for Clojure itself and contrib releases)?
The mechanical part of GPG signing is likely to be exactly the same, it’s the surrounding verification and distribution of keys that would be improved. I’ve never published anything to Maven Central, but when Clojars was verifying GPG signing, anyone who had a user’s Clojars credentials to upload a JAR could change the authorised GPG key to their own. Without a set of trusted GPG keys, signing JARs on upload and verifying signatures on download doesn’t buy you very much security. One option I am looking at is using The Update Framework (TUF) to help manage these trust relationships. TUF is used by Docker and Pip. The high level overview of TUF applied to Clojars would be: - There is a root (offline) key of trust managed by Clojars used for signing other keys - A publisher (library developer) has an offline master key and online keys for signing releases. When they deploy a new release, they sign their new JAR with an online key. - When a user downloads a JAR or metadata from Clojars, the tooling (e.g. leiningen), verifies a freshness timestamp signed by Clojars. This ensures that the view of the world being presented is current, *and protects against replay attacks.* - The first time a user downloads a JAR, leiningen would keep a record of the association between the signing key identity, and that artifact. Any future downloads of the same artifact would need to be signed by the same key. This is Trust on first use <https://en.wikipedia.org/wiki/Trust_on_first_use>. Also, nothing would stop very security conscious users from preloading keys obtained directly from the developer, e.g. served over GitHub. - Even if an attacker gained a privileged position on Clojars infrastructure, they would have no way to sign JARs, so clients would detect a signing problem. *This protects against infrastructure compromise.* - The publisher’s online tagging keys can be rotated without disruption to users, but not the offline master key. If that was lost then they would need to communicate out of band to people what happened and which key to trust. *This enables protection against key compromise.* See https://blog.docker.com/2015/08/content-trust-docker-1-8/ and https://docs.docker.com/engine/security/trust/content_trust/ for a better explanation than mine. Thanks, Daniel. On Tue, Feb 7, 2017 at 8:32 AM Chad Stovern <c...@stovern.me> wrote: Daniel and Toby, I do DevOps-y things for a living and would be more than willing to help with ansible stuff or potentially anything else. Feel free to contact me directly. - Chad On Thursday, February 2, 2017 at 1:47:00 PM UTC-6, Daniel Compton wrote: Hi folks In 2016, thanks to the generous sponsors on our Bountysource program and open source contributors, Clojars was able to: * Move our hosting from Linode to servers sponsored by Rackspace * Define the server on Rackspace with Ansible so it is easy to rebuild * Validate deploys are correct and complete * Store JARs in Rackspace Cloudfiles for greater reliability * Serve JARs from a Fastly CDN (sponsored). This takes the Clojars servers completely out of the critical path of serving files, and should result in Clojars being very highly available * Switch from Yeller to Sentry for exception tracking * Make many smaller improvements as well As we look towards 2017, there are a number of issues on the Clojars issue tracker, but most of them are of low priority. We're interested in feedback from you the community as to where you see problems or room for improvements to Clojars. There is one major issue which I think has the potential to greatly improve security in the Clojure community: JAR signing. Previously Clojars required JAR signing to promote releases into a special repository. This only served to confuse most people, not many people promoted their artifacts, and there were minimal security benefits from signing the JARs, as people didn't have a web of trust to validate that the GPG signatures actually chained to people that they trusted. Clojars is in a very privileged position in your infrastructure, as many of you use it to directly download JARs to run on your production machines and developer infrastructure. It would be great if there was an option for security conscious organisations to be able to validate that all of the JARs they are using came from developers that they trusted. It would also be a goal that even if Clojars was compromised, clients would reject malicious code that didn't come from their expected sources. I feel that this would be useful for the Clojure (and wider JVM) ecosystem. However doing this will require a fair amount of time and effort, and it's only worth doing if people are interested and want a higher security option available to them. If you are interested, I encourage you to contribute to https://github.com/clojars/clojars-web/issues/562, https://github.com/clojars/clojars-web/issues/560, or this thread to share your perspective, requirements, and threat models that you think we should be working with. We're also interested in hearing what else you think is valuable for Clojars to focus on in 2017. Please reply on this thread with your thoughts. Thanks, Toby and Daniel. -- Daniel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Daniel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
