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.
