Nathan, I wasn’t concerned with Github per se but the CI server compiling/running arbitrary code should some library’s repo get pwnd in some way or that a rogue library could make it into the list of repos to build in the proposed system. A hand curated list of repos would mitigate this last concern.
I suppose CircleCI/Travis have this figured out (sandboxes?) given that they already run arbitrary code via tests. I’ve not used any of the cloud-based CI services, just in-house installations that are tightly controlled. Never mind... I think I’ve left my paranoia dial set to 11 after reading about remote Spectre attacks. Alan On Jul 30, 2018, at 1:01 PM, Nathan Fisher <nfis...@junctionbox.ca> wrote: If it’s run on CircleCI or Travis and has readonly access to github, I wouldn’t be too concerned. The most frequent downloads API in Clojars is a good idea. Could use it as a basis for the hand rolled site for now and target it for automation in the future. I’m wondering how amenable/suitable it would be for the data to live in Clojars. On Mon, Jul 30, 2018 at 02:17, Alan Moore <kahunamo...@coopsource.org> wrote: > Has anyone looked for vulnerabilities exposed by pulling random libraries > from github.com (or gitlab.com?) and building them? Macros come mind > (mined?!) Solved problem? AFAIK the Rust compiler can't run arbitrary code. > > Also instead of choosing "top-N projects on Github" I would begin with > the "most used projects on clojars" (# downloads in the last 12 months?) as > that might be a better metric/signal for prioritizing which libraries to > include. #RememberLeftPad > > Don't get me wrong, I like the idea. I'm just trying to think through the > possible hazards. > > Alan > > > On Friday, July 27, 2018 at 4:11:27 PM UTC-7, Nathan Fisher wrote: >> >> Hi Folks, >> >> Reading up the recent blog post “What is Rust 2018” and happened upon >> this; >> >> “We put in a lot of work to make upgrades painless; for example, we run a >> tool (called “crater”) before each Rust release that downloads every >> package on crates.io and attempts to build their code and run their >> tests.” - https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html >> >> Seems an interesting idea and with Travis and other CI services providing >> free builds for OSS it doesn’t need to put a heavy financial/operational >> burden on a single entity. The main benefit for this is for people could >> get a quick centralised overview of compatibility of various projects and >> impending releases of Clojure. >> >> The main idea would be to have a grid view of the latest Clojure projects >> and their status against HEAD of Clojure (are snapshots pushed to a maven >> repo automatically as a result of a commit build?). Travis allows periodic >> builds so that could be used to trigger verification even when changes >> haven’t occurred. >> >> In terms of initial focus targeting the top-N projects on Github makes >> the most sense to me. The bit I’m still thinking through is providing some >> form of dashboard/aggregation without requiring a large investment in >> changes, infrastructure, etc. Might fit in nicely with something like >> clojars? Was thinking initially having a Github page with a table of >> projects and their build badges and talking to maintainers about >> configuring periodic builds with the latest Clojure snapshot. >> >> Thoughts? >> >> Cheers, >> Nathan >> -- >> - sent from my mobile >> > -- > 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. > -- - sent from my mobile -- 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 a topic in the Google Groups "Clojure" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/krAB_1nJ6Hw/unsubscribe. To unsubscribe from this group and all its topics, 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.
