I'm travelling at the moment so I don't have time to respond to everything right now, but one thing about the Java 6 issue - IntelliJ won't be fully on Java 8 until IntelliJ 16. This means that Java 6 will be around until a) everyone is on whatever comes after El Capitan (the last OSX to support Apple's Java 6, which came out not long ago), or b) everyone is on IntelliJ 16, which has only just gone into beta. I support the last two major IntelliJ versions, so that'll be another two years or so. Of course, there may be a vanishingly small number of users still on Java 6 at that point but that's the timeline. It's anyone's guess when a majority of OSX users will be on JDK 8 - at some point I'll just have to say that you need to upgrade IntelliJ if you want to use Leiningen on OSX, but that won't be for a while yet - at least a year I guess.
On 3 January 2016 at 09:33, Toby Crawley <t...@tcrawley.org> wrote: > On Sat, Jan 2, 2016 at 1:59 PM, Michael Gardner <gardne...@gmail.com> > wrote: > > Still, my personal opinion (for whatever it's worth) is that ensuring > the entire process is always cryptographically secure end-to-end should be > a higher priority than establishing mirrors. > > I agree, ensuring the process is cryptographically secure end-to-end > should be a priority, but it is also a Sisyphean task, since it would > at least require: > > * getting everyone to sign releases: not difficult - we just require > signatures at deploy time on clojars.org and deal with the pain of > bringing everyone up to speed > * dealing with existing unsigned releases: deprecate them? give the > authors a way to sign them after the fact? > * changing tooling to confirm that the artifacts are signed with keys > that are in your web of trust: lein and boot can already tell you > what in the dep graph is signed, and verify that the signatures are > valid, but don't yet confirm against the caller's web of > trust. Without that, how would you know that the artifact isn't > signed with a random, throwaway key? > * organizing key-signing parties around the world to build the web of > trust for the clojure community: Phil Hagelberg started that process > with key-signing meetings at clojure conferences, but it didn't > spread very far. Initiatives like https://keybase.io/ may help with > this. > > And this assumes that everyone in your web of trust that publishes > artifacts is who you think they are, keeps their keys 100% secure, > and aren't coerceable. > > Even after all that, we still won't be able to pull jars when > clojars.org is down unless we have some alternate source. > > - Toby > > -- > 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. > -- 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.
