This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-16
Channels
- # admin-announcements (94)
- # aws (6)
- # beginners (8)
- # boot (303)
- # cider (5)
- # cljsrn (25)
- # clojure (82)
- # clojure-art (28)
- # clojure-chicago (2)
- # clojure-dev (2)
- # clojure-france (1)
- # clojure-japan (1)
- # clojure-my (1)
- # clojure-russia (78)
- # clojurescript (21)
- # clojurex (3)
- # dirac (1)
- # events (3)
- # funcool (5)
- # hoplon (12)
- # jobs (1)
- # ldnclj (2)
- # off-topic (49)
- # om (207)
- # proton (3)
- # re-frame (24)
- # reagent (45)
- # spacemacs (1)
- # yada (48)
OK, a very basic version of Boot new now exists: boot -d seancorfield/boot-new:0.1.0-SNAPSHOT new -t {templatename} -n {projectname}
that will run any Leiningen template
Currently I'm locked out of signing artifacts on Clojars due to a local GPG failure (I really hate this stupid signing shit! I've had so much grief from trying to deal with GPG over the years!).
So there won't be a non-snapshot release until I've bludgeoned GPG back into submission. Again.
@seancorfield: keep going on….
LOL! I'll get boot-template support in next with boot.new.templates and then built-in app, default, task, template stuff too.
And at some point over the weekend I hope to restore my ability to sign artifacts... Something on my system has "forgotten" my secret passphrase and of course I can't remember the stupid "super secret" thing either since I last used it years ago...
I'm not a giant fan of encryption. I understand that it's important for some stuff. But this whole crap about signing JARs on Clojars just annoys me. And it always has.
I've never managed to get it working on Windows. It barely works on Mac. And Phil was just very snarky about how "it works just fine on Linux"...
That's some serious elitist shit.
@seancorfield: I know what you mean….I started using that signing stuff 20 years ago and they still hurt me
@seancorfield: I agree - GPG is a pain. And it doesn't really work any better on linux, it only works well if you have fully internalized the esoteric tooling and infrastructure. The reason clojars uses GPG is because maven uses GPG for signing.
The value of signing releases is debatable, since we don't have tooling in place to verify that the artifacts are signed by a party you trust, all boot/lein can tell you is the artifacts are signed
you can, however, manually check a signature, but that requires some assurance that the signer is who they say they are (which requires a web of trust, signing parties, etc), and knowledge of gpg tooling
clojars doesn't require signatures, btw, it's just the default in lein (and boot? I'm not sure.)
what's the process for releasing clojure.java.jdbc
? Maven central requires GPG signatures. Does that all happen on CI?
I think having a way to verify that artifacts are signed by parties you trust is important. Unfortunately, what we have now isn't the right answer. I don't know what is - the fix is larger than any one person or group.
boot jars are not signed, because i need to deploy from different machines that i don't trust to have my keys on
not that the machines are not trusted, but i just don't want to have my gpg secret keys in different places
I assume the CI system signs Clojure core and contrib releases to Maven?
I started signing releases to Clojars so I could "promote" them after Phil gave me a lot of grief for being negative about how painful the process was.
Mostly so I could say "Yeah, I run GPG and it sucks" 😸
Hahaha... Ok. Why?
Interesting. I do release snapshots of the Frege compiler to Sonatype. I don't remember whether that requires signing. So maybe I no longer have to worry about dealing with GPG at all? Yay!
i definitely plan to work out a good way to sign the boot jars and have some other trusted people sign my public key
and mvn seems to do a better job of handling signing (surprisingly) than the gpg command line tool
Phil was all over having your Clojars credentials file encrypted too which always seemed overkill to me.
I'd like to uninstall GPG frankly.
you have to use gpg to generate a key, but mvn doesn't use the gpg binary for signing, it does it all in java I believe
I use gpg for other things (encrypting files, mainly), but do it through other tooling (http://www.passwordstore.org/, emacs)
Pretty sure I have keys not generated via GPG...?
Anyways this sounds like good news to me
i was thinking about just buying a cert and signing the jars the jartool way, have you ever done that @tcrawley ?
We wrote an OAuth 2 authorization server and that uses key pairs for each tier (DEV, CI, QA, production).
The DEV key is generated by Java (well, Clojure). Not sure about the others -- the ops team created those.
there are lots of ways to generate crypto keys, but they all won't work with gpg, unfortunately
But yeah OpenSSL gen'd keys are what I use with Unfuddle and a bunch of other sites.
@tcrawley: is it possible for a 3rd party to somehow sign jars from repos they don't control?
you can sign anything, but there is no legitimate way to get those signatures in to a repo that you don't have write access to
nor do any of the repos that I know of allow you to add signatures for a particular release once it has been released
and that jar used in a web app for walmart with millions of customers private data going through it
what if you could do something like [foo.bar "1.2.3" :sha1 "abcde" :signature "34e4df"]
to say "the jar must have the given sha, and be signed by the given gpg key"?
if our tooling supported that, and we had a way to trust that the 34edf
key was owned by someone we trust, you could have more assurance about the deps
though, if you need that level of trust, you really need to be auditing all your deps to the src level and building them yourself
really what i need is to know that a jar isn't being swapped out with me unawares i guess
being able to specify sha1, etc in the dep spec would require changes to maven, since you'd want to do it all the way down
it has a prepopulated set of vetted jars, and you'd have to request vetting of any thing you wanted added
you could call it http://projars.com
yeah i mean i trust the clojure community to be responsible, so really tracking stability would go like 99% of the way
like just making sure that someone didn't get access to a clojars login and upload something, or exploit something to swap out a jar
How much can you really trust JARs on Maven Central tho'?
if the artifact comes form clojars or central, a particular version shouldn't change w/o a larger compromise of the repo, since you can't overwrite existing versions
we would have a copy of the checksums on a separate host, and it would periodically check to confirm those checksums match what's in the primary repo
But if someone releases a legit useful library that gets into everyone's projects and then in release 2.1.13 after folks have been using it for ages and happily upgrading it introduces a Trojan... Won't folks get caught by that anyway?
Right, so how paranoid do you want to be?
Sure, and you could roll back to 2.1.12 but my point is the damage would be done -- through a trusted channel.
the problem that concerns me is changing older versions that we trust more simply because someone would have found something if there was anything bad, over time
Yeah, I'm with you on that. A known, trusted, older version should never be allowed to change.
like when i download clojure version 1.7.0 which has been well tested, how do i know that i'm really getting the jar that everyone else has been using?
(Although look how long it took to find the OpenSSL vulnerabilities!)
Hmm. Keybase looks quite interesting. They support e.g. device specific keys.
As to http://keybase.io I've been thinking along these lines recently.
A number of developers including myself have signed up with http://keybase.io, includingJames Reeves, Martin Trojer,Philip Meier and James Henderson. If enough Clojure devs start using this service we can begin to build a trusted library distribution system based on it, and perhaps get Maven to use it for verifying a user-defined subset of signatures.
@malcolmsparks: interesting!
I'll try it and if it works nice I will "encourage" my co-workers to sign up also 😄
everyone deals with information or services that would put them out of business if they were exploited
Yeah we have several clients were it would be definitely good to be able to verify the deps
if you perform any services on behalf of other businesses, and your service is exploited it cascades to be their problem too
I didn't consider boot because I felt signature verification should have to be built into aether itself. But a boot implementation would be a good start and lead the way. I'm not sure how to get the maven devs to consider http://keybase.io - my java enterprise ties are a little frayed these days :)
Yeah it's not (just) banks
Security is no longer an academic topic these days
@malcolmsparks: do you have an invite for keybase?
Yes 5 i think. do you need one?
I would also like one.
@malcolmsparks: sorry i slacked on the documentation, I'll do it today for sure
Send me the email address you'd use for http://keybase.io and I'll send you an invite
Give me 30 mins I'm in a baggage hall :)
I ordered few Yubikeys also
@malcolmsparks: this is some really good info, thanks
I have read the intro page, but I don't see any big advantage in using keybase, maybe I am not reading it right...the cmd line tool seems easier than gpg I agree, but it is really just a centralized web of trust (at least to me)
and it basically relax the concept of having to introduce yourself with you ID to someone in order to prove his/her identity and sign his/her gpg key
Yes true. The main advantage is you are provided with evidence that helps you trust the pgp keys of people you only know online
(btw not a security expert here, but a crypto/privacy fan)
It's a starting point. Paranoid users could override and use their own Web of trust
@malcolmsparks: i was thinking of signing all commits that make it into master with my own GPG key
so you sacrifice a bit of your privacy for an easier identification process, well fair enough, but not solving it all
As I see it, Keybase is better than nothing, which is what we currently have
@richiardiandrea: but it's a start. The choice right now is between checking signatures from a built-in whitelist of developers whose PGP keys are published on http://keybase.io, and not checking signatures at all
The theory is it's hard to subvert http://keybase.io because people on there have associated their keybase identities to their twitter accounts, bitcoin wallets, domain names, etc.
yes it's a start
(switched off paranoid android mode)
for example, when I upgrade my arch linux machine, I have to trust the (centralized) keys published on the arch website that are downloaded into the package manager. But I would rather do that then turn off all signature checking entirely!
And if any of those keybase (or arch) keys is found to be fraudulent, they can be removed from the whitelist
well, all those signatures were signed and (hopefully) fully verified, id included, that is how the original web of trust was supposed to work
I'm not saying that it would be impossible for an impostor to become established in the clojure community as a library author, but at least we'd have a chance to review her library code
the point is those signatures are trusted by the arch package manager - they aren't (necessarily) in my personal GPG database
but if we started with (something like) keybase we could allow the option for (truly paranoid) folks to override with their own whitelists
there are lots of clojure devs in London who I have met, shared a few pints with and can verify
pgp has the concept of trust level, but not a lot of people (me included) actually employ it correctly -> https://www.phildev.net/pgp/gpgtrust.html
keybase is a good compromise I reckon
there's enough opportunities for us to meet each other and create a transitive graph of trust - even if not all of us fly to other continent
oh really
yeah. I had a fairly empty PGP database until I joined keybase. Now I have loads of keys
not sure letsencrypt is relevant here, the http://keybase.io site is trustable with establised CAs
(not taking anything away from letsencrypt, it's great - I've used it to migrate a ton of websites to TLS)
sign your jars with a key that's established with a CA that verifies you, like an SSL cert
I think the jar signing part is well established via GPG
it's the signature verification piece that is missing
we have a ton of resources on how to use GPG - in fact it's mandatory for uploading to clojars right?
yeah, you don't need CAs in this process - I mean, we want individuals (beginners) to write clojure right and contribute libraries right?
(sorry guys Slack bugs)
we don't want people to have to go through all that CA verification mullarky just to contribute
i don't see how the verification malarkey is any different than building a web of trust
Hmh, I don't know how one would use Let's Encrypt cert to sign jars?
Let's Encrypt certs require domain validation which is probably not very good fit for this?
yeah I agree, anyway it's a solved problem - way more solved than the verification part
To create let's encrypt cert you need an domain and web server
it's great for adding https to websites where you don't want to spend $100 on a wildcard SSL certr
e.g. http://yada.juxt.pro, http://malcolmsparks.com, http://modularity.org etc.
@malcolmsparks: about the verification part, it is a very interesting topic and I started some time ago to assign an Explicit level of (not) trust to some of my imported keys and I have to say that it was not a pain and definitely feels like the orthodox way of doing thing. For example my girlfriend has lower level of trust, she for sure would not know all the implications of the web of trust, therefore any key signed by her would be less "trust-worthy"
just stop the server, run the letsencrypt thing once (5 secs), and restart your server
from the link before "a key is considered validated if it meets both of the following two conditions":
a. It is signed by enough valid keys, meaning one of the following:
You have signed it personally
It has been signed by one fully trusted key
It has been signed by three marginally trusted keys
b .The path of signed keys leading from K back to your own key is five steps or shorter.
I think we (as in the clojure community) could potentially create a whitelist of trusted devs
of course it would be a bit of an obstacle for people who want to join it, and we'd have to think about that
gpg has already thought about this, and probably needs better UX 😄
but it would give the clojure downloader the option to enforce checking, add in exceptions, etc..
or disable completely
but at least it's the user's choice
keybase gives good UX it seems, agree with the whitelist
right now we just install jars on everyone's machines and don't even give them the option of checking sigs
and anyone found to be naughty gets booted off
devs you meet in Conferences can be fully verified, if I go to Clojure/West I will have my PGP stand 😉
plus, anyone who wants to upload non-opensource code would have to jump through more hoops
@richiardiandrea: I would I know it was you at the PGP stand?
anyone right now can upload anything to clojars right?
but we can also sign our git tags
if there was some way of tying a jar signature to a tag signature
@malcolmsparks: there is always a certain level of trust to be put by ourselves
is there a way of being able to prove that a jar came from a particular sha1 of code on github?
git history can be rewritten, but not without changing the sha1 - and you can sign those
I sign all my jars before they are uploaded to clojars
and I sign all my git tags
(but it's all rather pointless without sig verification)
@micha, yeah, you can trust the sha1 - it's hard to forge
yeah but sha is just a hash so you cannot map 1:1 with code
i was just pointing out that you can make a malicious jar and associate it with a malicious sha, too
the sha isn't mapping 1:1 with code, it's mapping 1:1 (more or less) with the sequence of commits
@richiardiandrea: yes, you're right. You can't every /prove/ that I actually used boot to build that particular version of code to create a particular jar...
unless...
it wasn't you that built it, but a third-party...
like circle-ci
hmm, that would be interesting. Have a service whereby circle-ci would build a jar for you but only if you gave it a signed git tag to use
probably we are reaching high level of paranoia here 😄 So interesting!
i guess that's not true, because you can't just have a service that signs anyone's jars
yes, circle-ci could sign the jar with its private key - and the trust would be established by the fact it had git pulled the code-base from a (signed) tag provided by the developer
and that would also make using a CI server mandatory
whether that's a good thing or not I don't know but it's intriguing
we're definitely not being paranoid here. There's a huge gaping hole of an attack vector we're providing to anyone who wants to use it
it should be like this in every software worth its salt, really <- mandatory CircleCI
large organsations download our stuff, through their firewalls, every day
yeah installing jars on people's computers is pretty much the most invasive thing you can do
it's the ultimate trojan horse opportunity
and there's no java sandbox when you run java -jar
does anyone know the circle-ci folks? do you think they would be amenable to discussing this?
yeah, I installed keycloak last year and the number of java dependencies that came down was horrific
mmm no don't know them, maybe someone in re-frame
or reagent
channel, dunno why I recall some conversation there, but I might be absolutely wrong
yep probably some initial boot support would open the doors to some more people to join in
Does anyone know whether npm and the nodejs folks do signature verification?
@otfrom do you know any of circle-ci crowd?
We're musing whether there's a part they could play
Boot itself can have an important role in the opsec ux
i'm not a nodejs expert or anything but i've pushed things to npm and there was no signing involved that i know of
That sounds like a disaster waiting to happen given their footprint. Mind you, we should get our own house in order first
On the topic of npm and security http://blog.npmjs.org/post/80277229932/newly-paranoid-maintainers
Good read. There's another discussion about whether clojars or jcenter
there was a thing on reddit recently where someone inspected the 50 most downloaded npm packages and found all kinds of npm logins and passwords that could be used to push artifacts
woah that's crazy
@malcolmsparks not well enough
one really good thing about the maven ecosystem is that dependency graphs are pretty much immutable
unlike ruby or nodejs where you might get different versions of things at different times, like when someone releases a new version of some transitive dependency you don't even know about
And @technomancy (or whoever it was) did us a great favor by insisting on gpg creds for clojars uploads, and keeping them outside the project in .lein
I think the clojure community could take a lead here
because then if people put the .travis.yml or whatever in their project you could implement your own trusted build service
the .travis.yml type file would be the link between the source repo and the jar artifacts
so if you didn't trust the official build service you could make your own that could still fetch transitive deps from git and produce verified jars
advertising this 😄 -> https://twitter.com/richiardiandrea/status/688460962458763264
Scrolling up through the security discussion from earlier (thanks @malcolmsparks for the pointer)
OK, that was unexpected… I called util/exit-ok
expecting to get a clean exit from a task but instead got an exception…