This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (40)
- # boot (307)
- # boulder-clojurians (2)
- # carry (3)
- # cljs-dev (3)
- # cljsjs (16)
- # clojure (42)
- # clojure-greece (3)
- # clojure-russia (10)
- # clojure-uk (3)
- # clojurescript (116)
- # community-development (1)
- # component (5)
- # conf-proposals (2)
- # core-async (1)
- # crypto (2)
- # cursive (3)
- # devcards (1)
- # events (1)
- # hoplon (123)
- # om (28)
- # onyx (17)
- # pedestal (3)
- # proton (1)
- # re-frame (18)
- # reagent (26)
I’ve just cloned a javelin repo which uses boot - what is the fastest way to start a REPL to test modifications which i made to the lib?
but mostly snapshot releases & not so much docs so you'll probably end up reading the code 🙂
As you know, Clojars (optionally) lets you sign JARs you push to it's artifact repository - their aught to be a way of querying their API for the registered public key for a particular user. Next, there should be a way of getting a signature from their API, and finally, once you have a public key and signature, checking is straight-forward. Almost everyone just wraps bouncy-castle - here is a wrapper
but then i realized that their whole system is based on npm modules and i just don't trust it
@micha Doesn't maven/clojars provide an API for getting the public key of registered artifact authors?
one thing i would trust would be jars signed by keys that are themselves signed by a legit CA
http://keybase.io does the next best thing, which is cross reference multiple social media accounts
Eh, CAs can get hacked too. Honestly, a solution that is independent of worrying about various servers getting hacked would be CAS
at the end of the day it seems like you need to trust humans to keep everything above board
The only reason I mentioned Ethereum is that their "Swarm" system they are building out is a CAS like IPFS
Incidentally, IPFS is already dogfooding using IPFS for versioning their upstream dependencies
Check out the source code - https://github.com/ipfs/go-ipfs/blob/6f1062b4f323037983841585d706bc4d56020552/core/corenet/net.go#L7
You might consider reading the IPFS white paper - https://ipfs.io/ipfs/QmR7GSQM93Cx5eAg6a6yRzNde1FQv7uL6X1o4k7zrJa3LX/ipfs.draft3.pdf
I need to do some chores around the house, but I would not mind discussing this matter further, especially if I can get devs working on a build-tool excited.
Oh, well either the JAR has dependencies in Clojars/Maven Central, and you are in the same boat you are now
yeah i meanimmutability is good, i just don't see how it helps you trust the source of the immutable thing
It's called "Content Addressable Storage". If the merkel hash of the artifact/directory you have on your hard-drives checks out, then you must have received the right thing.
that does not help me know if the sequence of bytes was written by a human i trust or not
Honestly you have such threats now. Anybody can push whatever they want to Clojars, it could potentially be very malicious.
I am discussing a problem of "Well, checking OpenGPG signatures isn't a very good check if a server is compromised" which is true.
if the signature was associated with a legit certificate authority though, you don't care if clojars is compromised
Eh, I'm cool with source code being included in my JARs TBH and just using CAS. I'd rather have CAS for versioning anyway, since someone can always push an artifact with the same version tag to a repository and rewrite history.
I guess if you wanted to bolt on an elaborate CA thing for legal liability that's cool too. I'm not an anarchist or anything.
A certified individual would presumably need to sign some hash, might as well be a CAS hash
i wonder if it would be possible to get some kind of funding for real certs we can use to sign jars
Ethereum has a janky thing using the blockchain as their CA - https://github.com/axic/mango
Okay, step one, get support for checking these in boot, even if it's sort of just for show
so i think the only impediment is the overhead and cost of maintaining the CA relationship
we can build boot tooling to make the mechanics of correctly signing and verifying jars simple
You can tell that to the people who want to build the JS build tool. Honestly, I have no idea when I will have the time / funding to do this sort of work.
After google released their JS Closure Compiler, everyone has been excited about eventually getting a JS land build tool, since waiting for the JVM to spin up is lame.
But the mess of course is that there's no tools for dealing with JARs, not even a standard for IO for JS CLI
Nor crypto, but that's like, the last on everybody's list of thing to worry about, but it's been my living lately
when i make the UI i'm not playing around with live reaload constantly, because the UIs are for business. i don't need to have a live art performance
It's not a big deal for me either. But, I would like to sort of help the W3C out in putting the right primitives in their cryptographic API, because right now that thing is useless.
Other than that and helping the crypto situation in JS in general out of kindness, I'm ready to admit it's theatre right now when dealing with JARs.
it has some quirks but they're easy enough to understand because it always does the simplest thing when it's unsure
@xcthulhu @micha do you know this dependency story? https://www.kickstarter.com/projects/2066438441/haunts-the-manse-macabre/posts/373466
@onetom This is why the common practice amongst go developers is to "vendor" their upstream developments, and why IPFS dogfoods itself in its source code
sure, it's just a good example of a real story which shows the serious consequences of this dependency problem
Right. It's a bit tougher in go-lang than in Clojure, because you can literally put URLs in your includes, and go will fetch them.
Much as I love the idea of IPFS, there's no JVM port. Who knows when one will land...
Very interesting, I have always wanted to have a quicker build tool, especially for dev, but I agree that a maven port to js would be a big challenge (maybe Aether is enough to port?)
@xcthulhu when u said https://clojurians.slack.com/archives/boot/p1473523449001059 which white paper were you referring to? can u give an URL, pls?
it's also important to separate package management conceptually from the build process, and even from dependency management
I think it would be a good community project to make an IPFS task that works like the old
checkout task, that way boot doesnt need to care about it
all we are trying to do is download a file extract the contents and add it to the fileset.
personally i am strongly opposed to using anything but versioned dependencies in my projects
if people start publishing artifacts with dependencies on SHAs i think it will be a real shame
lots of things use sha’s for their build identifiers the are less developer friendly but more computer friendly
right if im leaving it up to the computer i probably want the latest version, it tihnk it works better for rolling systems
if you're worried about exploits and hackers you need some kind of crypto web of trust anyway
maven is great because if it builds and works today it will build and work the same in 100 years
i think it depends on why you want an IPFS file, im not arguing for it’s use with dependencies just it’s availability
If you pegged to an IPFS hash, it would not update any dependencies automatically since the thing would be immutable
TBH, you can already do this sort of thing - you can just git hashes with http://jitpack.io
@micha - I think if you email the folks at Clojars they will manually take artifacts down.
I'd rather not have to trust Toby or whoever unless they are actually incentivized (with money, not reputation) to not delete stuff.
I’d prefer to depend on people who are not incentivized by money, someone who is already incentivized is more likely to switch sides for more incentives… NSA deals with Facebook, Microsoft, Google etc.
right and prevent them from replacing packages, with say modified or corrupted ones
right moving from a version to an sha is kinda a regression since, like you said, it’s meant to convey info to the human, a different issue than using something like IPFS
but verifying that the thing at the hash url contains the correct contents is trivial with or without IPFS
if you get rid of hashes that encode version info in favor of SHAs you lose a lot i think
i really enjoy the talks in #boot and #hoplon , very interesting discussions that cover a wide range of issues 🙂
It's just so you can avoid having to worry about Clojars or mavencentral getting hacked or taking a thing down.
Cool. Well, truth be told, I will have to wrangle a contract to port IPFS to the JVM, which will take time.
I actually know someone who may be interested in helping a project like that, hes waiting for it
Btw y’all @micha @xcthulhu @flyboarder I made an #ipfs channel in here a month ago. 🙂 I’m finding myself at the intersection between Clojure world and Web 3.0 world too, but as a new developer it’ll probably be a while before I can build anything to link up to Ethereum/IPFS/Golem Network/Storj myself.
Also made an #ethereum channel. Not sure if y’all know but the EthereumJ project is a full-out Java implementation of the Ethereum node. So in theory you could run an Ethereum node in Clojure. Nothing for IPFS though from my understanding like you were mentioning. You guys should really look into the Golem Network too for basically decentralized AWS through Docker containers. It’s so cool IMO. That’s written in Python.