Fork me on GitHub
#boot
<
2016-01-16
>
seancorfield07:01:54

OK, a very basic version of Boot new now exists: boot -d seancorfield/boot-new:0.1.0-SNAPSHOT new -t {templatename} -n {projectname}

seancorfield07:01:03

that will run any Leiningen template

seancorfield07:01:05

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!).

seancorfield07:01:33

So there won't be a non-snapshot release until I've bludgeoned GPG back into submission. Again.

magomimmo07:01:21

@seancorfield: keep going on….

seancorfield07:01:53

LOL! I'll get boot-template support in next with boot.new.templates and then built-in app, default, task, template stuff too.

seancorfield07:01:25

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...

seancorfield07:01:18

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.

seancorfield07:01:05

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"...

seancorfield07:01:23

That's some serious elitist shit.

magomimmo08:01:24

@seancorfield: I know what you mean….I started using that signing stuff 20 years ago and they still hurt me simple_smile

tcrawley13:01:48

@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.

tcrawley13:01:18

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

tcrawley13:01:44

and anyone can generate a key to sign artifacts, so that's not real security

tcrawley13:01:11

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

tcrawley13:01:39

clojars doesn't require signatures, btw, it's just the default in lein (and boot? I'm not sure.)

tcrawley13:01:59

what's the process for releasing clojure.java.jdbc? Maven central requires GPG signatures. Does that all happen on CI?

tcrawley13:01:44

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.

micha15:01:01

boot jars are not signed, because i need to deploy from different machines that i don't trust to have my keys on

micha15:01:31

not that the machines are not trusted, but i just don't want to have my gpg secret keys in different places

seancorfield16:01:03

I assume the CI system signs Clojure core and contrib releases to Maven?

seancorfield16:01:25

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.

seancorfield16:01:58

Mostly so I could say "Yeah, I run GPG and it sucks" 😸

tcrawley16:01:21

good news! promotion is now disabled, and will soon be removed entirely :)

seancorfield16:01:40

Hahaha... Ok. Why?

tcrawley16:01:45

read the last comment on ^, and let me know if you have more questions

seancorfield16:01:18

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!

tcrawley16:01:09

sonatype only requires signatures on releases, so SNAPSHOTS are fine

micha16:01:21

i definitely plan to work out a good way to sign the boot jars and have some other trusted people sign my public key

tcrawley16:01:01

and mvn seems to do a better job of handling signing (surprisingly) than the gpg command line tool

seancorfield16:01:02

Phil was all over having your Clojars credentials file encrypted too which always seemed overkill to me.

seancorfield16:01:30

I'd like to uninstall GPG frankly.

tcrawley16:01:41

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

micha16:01:00

boot used to do that, too

micha16:01:05

using bouncycastle

micha16:01:15

but there is no clean way to interact with gpg-agent then

micha16:01:27

which is a deal breaker for some people

tcrawley16:01:48

I use gpg for other things (encrypting files, mainly), but do it through other tooling (http://www.passwordstore.org/, emacs)

micha16:01:52

because gpg-agent uses unix domain sockets which require hacks for JVM

seancorfield16:01:20

Pretty sure I have keys not generated via GPG...?

micha16:01:03

i am thinking about signing all commits in the boot repo as well

seancorfield16:01:17

Anyways this sounds like good news to me simple_smile

micha16:01:27

the only problem is how people can know whether my key is trustable or not

tcrawley16:01:29

micha: I'd be happy to sign your key next time we are proximate

micha16:01:45

maybe you can be the clojure CA?

tcrawley17:01:02

seancorfield: what do you use those keys for?

micha17:01:40

i was thinking about just buying a cert and signing the jars the jartool way, have you ever done that @tcrawley ?

tcrawley17:01:56

I haven't done that, no

seancorfield17:01:21

We wrote an OAuth 2 authorization server and that uses key pairs for each tier (DEV, CI, QA, production).

micha17:01:28

the jvm will handle a legit verification then, i think

tcrawley17:01:03

seancorfield: they could be openssl keys

tcrawley17:01:55

or certs generated by a web-based CA

seancorfield17:01:01

The DEV key is generated by Java (well, Clojure). Not sure about the others -- the ops team created those.

tcrawley17:01:39

there are lots of ways to generate crypto keys, but they all won't work with gpg, unfortunately

seancorfield17:01:30

But yeah OpenSSL gen'd keys are what I use with Unfuddle and a bunch of other sites.

micha17:01:24

@tcrawley: is it possible for a 3rd party to somehow sign jars from repos they don't control?

micha17:01:33

like is that a thing in java already?

tcrawley17:01:39

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

tcrawley17:01:06

nor do any of the repos that I know of allow you to add signatures for a particular release once it has been released

micha17:01:09

yeah no out of band thing for verifying jars

micha17:01:20

i was thinking about maybe a commercial service

micha17:01:40

you can get pretty far with open source stuff by analyzing github repos for instance

micha17:01:44

with clojure anyway

micha17:01:50

because source isn't compiled

micha17:01:06

so you could at least verify that the jar contains the clojure namespaces you expect

micha17:01:19

and that the git history hasn't been messed with

micha17:01:22

things like that

micha17:01:44

and then you could have your own signature in one gian manifest of vetted jars

micha17:01:49

and you sign that

micha17:01:59

it's kind of a scary situation

micha17:01:21

some transitive dependency jar being replaced with a malicious trojan

tcrawley17:01:35

yeah, transitives are the bugaboo

micha17:01:54

and that jar used in a web app for walmart with millions of customers private data going through it

micha17:01:02

and clojure with alter-var-root and all

tcrawley17:01:24

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"?

tcrawley17:01:12

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

micha17:01:33

yeah totally

tcrawley17:01:44

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

micha17:01:59

well you could at least hire a responsible 3rd party

micha17:01:07

to handle the basics

micha17:01:12

like basic auditing

micha17:01:36

really what i need is to know that a jar isn't being swapped out with me unawares i guess

tcrawley17:01:43

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

tcrawley17:01:16

so maybe a maven proxy that handles that for you

micha17:01:37

that's an interesting idea yeah

micha17:01:45

the proxy could keep track of these things

tcrawley17:01:45

it has a prepopulated set of vetted jars, and you'd have to request vetting of any thing you wanted added

micha17:01:35

yeah i mean i trust the clojure community to be responsible, so really tracking stability would go like 99% of the way

micha17:01:11

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

micha17:01:29

or inject commits into a github repo from which jars are built

micha17:01:25

like enforcing immutability in the proxy

micha17:01:35

if an artifact changes then reject it

micha17:01:02

or if an artifact contains different .clj than what's in the repo for that tag

micha17:01:18

or if the repo has had its history rewritten

seancorfield17:01:27

How much can you really trust JARs on Maven Central tho'?

tcrawley17:01:51

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

tcrawley17:01:07

we plan to add checksum checking to clojars at some point

tcrawley17:01:24

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

tcrawley17:01:32

if not, alarm bells go off

seancorfield17:01:34

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?

tcrawley17:01:02

yes, there's not much we can do about that with tooling, unfortunately

tcrawley17:01:21

cryptocurrencies seem to suffer from that exact problem

seancorfield17:01:29

Right, so how paranoid do you want to be?

micha17:01:55

well when you update things you watch and monitor

micha17:01:07

that's up to your deployment procedures and how paranoid you want to be

micha17:01:13

or are required to be by law

seancorfield17:01:40

Sure, and you could roll back to 2.1.12 but my point is the damage would be done -- through a trusted channel.

micha17:01:49

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

seancorfield17:01:33

Yeah, I'm with you on that. A known, trusted, older version should never be allowed to change.

micha17:01:53

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?

seancorfield17:01:09

(Although look how long it took to find the OpenSSL vulnerabilities!)

juhoteperi18:01:32

Hmm. Keybase looks quite interesting. They support e.g. device specific keys.

malcolmsparks18:01:45

As to http://keybase.io I've been thinking along these lines recently.

micha18:01:48

yeah and persistent web of trust

malcolmsparks18:01:07

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.

micha18:01:27

@malcolmsparks: interesting!

juhoteperi18:01:21

I'll try it and if it works nice I will "encourage" my co-workers to sign up also 😄

micha18:01:00

it's not only banks of course

micha18:01:19

everyone deals with information or services that would put them out of business if they were exploited

juhoteperi18:01:42

Yeah we have several clients were it would be definitely good to be able to verify the deps

micha18:01:27

if you perform any services on behalf of other businesses, and your service is exploited it cascades to be their problem too

micha18:01:41

which is pretty much every internet business

malcolmsparks18:01:35

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 :)

malcolmsparks18:01:51

Yeah it's not (just) banks

malcolmsparks18:01:15

Security is no longer an academic topic these days

micha18:01:18

i'm pretty paranoid at my job

micha18:01:34

@malcolmsparks: do you have an invite for keybase?

malcolmsparks18:01:57

Yes 5 i think. do you need one?

juhoteperi18:01:06

I would also like one.

micha18:01:07

that would be awesome, yes

micha18:01:42

@malcolmsparks: sorry i slacked on the documentation, I'll do it today for sure

malcolmsparks18:01:49

Send me the email address you'd use for http://keybase.io and I'll send you an invite

malcolmsparks18:01:49

Give me 30 mins I'm in a baggage hall :)

juhoteperi19:01:11

I ordered few Yubikeys also

nha19:01:57

If the 5 from Malcolm are not enough, I also have 3 invites simple_smile

micha19:01:13

@malcolmsparks: this is some really good info, thanks

richiardiandrea19:01:15

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)

richiardiandrea19:01:10

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

malcolmsparks19:01:50

Yes true. The main advantage is you are provided with evidence that helps you trust the pgp keys of people you only know online

richiardiandrea19:01:10

(btw not a security expert here, but a crypto/privacy fan)

malcolmsparks19:01:29

It's a starting point. Paranoid users could override and use their own Web of trust

micha19:01:24

@malcolmsparks: i was thinking of signing all commits that make it into master with my own GPG key

richiardiandrea19:01:27

so you sacrifice a bit of your privacy for an easier identification process, well fair enough, but not solving it all

micha19:01:38

only alan and I have clojars access to push artifacts

juhoteperi19:01:29

As I see it, Keybase is better than nothing, which is what we currently have

malcolmsparks19:01:05

@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

malcolmsparks19:01:19

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.

richiardiandrea19:01:03

yes it's a start simple_smile

richiardiandrea19:01:52

(switched off paranoid android mode)

malcolmsparks19:01:36

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!

malcolmsparks19:01:07

And if any of those keybase (or arch) keys is found to be fraudulent, they can be removed from the whitelist

richiardiandrea19:01:53

well, all those signatures were signed and (hopefully) fully verified, id included, that is how the original web of trust was supposed to work

malcolmsparks19:01:02

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

malcolmsparks19:01:35

the point is those signatures are trusted by the arch package manager - they aren't (necessarily) in my personal GPG database

malcolmsparks19:01:14

but if we started with (something like) keybase we could allow the option for (truly paranoid) folks to override with their own whitelists

malcolmsparks19:01:40

there are lots of clojure devs in London who I have met, shared a few pints with and can verify

richiardiandrea19:01:52

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

richiardiandrea19:01:23

keybase is a good compromise I reckon

micha19:01:38

or letsencrypt, someday

malcolmsparks19:01:39

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

micha19:01:07

i think java 9 will have the letsencrypt CA bundled with the trust store

malcolmsparks19:01:56

yeah. I had a fairly empty PGP database until I joined keybase. Now I have loads of keys

micha19:01:09

there was some issue with the cross signing of the letsencrypt CA

malcolmsparks19:01:36

not sure letsencrypt is relevant here, the http://keybase.io site is trustable with establised CAs

micha19:01:54

i mean that's the optimal way, isn't it?

malcolmsparks19:01:04

(not taking anything away from letsencrypt, it's great - I've used it to migrate a ton of websites to TLS)

micha19:01:14

sign your jars with a key that's established with a CA that verifies you, like an SSL cert

malcolmsparks19:01:32

I think the jar signing part is well established via GPG

malcolmsparks19:01:42

it's the signature verification piece that is missing

micha19:01:48

but it lacks the CA infrastructure

malcolmsparks19:01:58

we have a ton of resources on how to use GPG - in fact it's mandatory for uploading to clojars right?

micha19:01:14

it's not mandatory

micha19:01:29

but this problem is already "solved" with SSL in browsers

micha19:01:38

why not use the same thing with jars?

micha19:01:42

java already supports it

malcolmsparks19:01:55

yeah, you don't need CAs in this process - I mean, we want individuals (beginners) to write clojure right and contribute libraries right?

richiardiandrea19:01:57

(sorry guys Slack bugs)

malcolmsparks19:01:18

we don't want people to have to go through all that CA verification mullarky just to contribute

micha19:01:18

sure, that's why letsencrypt is good, cause it's not an ongoing expense

micha19:01:46

i don't see how the verification malarkey is any different than building a web of trust

micha19:01:52

it's just more easily automated

micha19:01:04

you still need to verify yourself and so on if you want to be trusted

micha19:01:26

and there are people whose jobs depend on doing it right

micha19:01:35

which is i think good?

juhoteperi19:01:33

Hmh, I don't know how one would use Let's Encrypt cert to sign jars?

juhoteperi19:01:16

Let's Encrypt certs require domain validation which is probably not very good fit for this?

malcolmsparks19:01:19

yeah I agree, anyway it's a solved problem - way more solved than the verification part

juhoteperi19:01:33

To create let's encrypt cert you need an domain and web server

malcolmsparks19:01:59

it's great for adding https to websites where you don't want to spend $100 on a wildcard SSL certr

richiardiandrea19:01:22

@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"

malcolmsparks19:01:36

just stop the server, run the letsencrypt thing once (5 secs), and restart your server

richiardiandrea19:01:27

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.

malcolmsparks19:01:07

I think we (as in the clojure community) could potentially create a whitelist of trusted devs

malcolmsparks19:01:38

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

richiardiandrea19:01:47

gpg has already thought about this, and probably needs better UX 😄

malcolmsparks19:01:02

but it would give the clojure downloader the option to enforce checking, add in exceptions, etc..

malcolmsparks19:01:07

or disable completely

malcolmsparks19:01:20

but at least it's the user's choice

richiardiandrea19:01:28

keybase gives good UX it seems, agree with the whitelist

micha19:01:29

and to have an audit trail

malcolmsparks19:01:47

right now we just install jars on everyone's machines and don't even give them the option of checking sigs

malcolmsparks19:01:04

and anyone found to be naughty gets booted off

richiardiandrea19:01:11

devs you meet in Conferences can be fully verified, if I go to Clojure/West I will have my PGP stand 😉

malcolmsparks19:01:26

plus, anyone who wants to upload non-opensource code would have to jump through more hoops

micha19:01:46

how do you mean?

malcolmsparks19:01:35

@richiardiandrea: I would I know it was you at the PGP stand?

malcolmsparks19:01:02

anyone right now can upload anything to clojars right?

malcolmsparks19:01:13

but we can also sign our git tags

malcolmsparks19:01:33

if there was some way of tying a jar signature to a tag signature

richiardiandrea19:01:48

@malcolmsparks: there is always a certain level of trust to be put by ourselves

micha19:01:02

git history can be rewritten, too

malcolmsparks19:01:06

is there a way of being able to prove that a jar came from a particular sha1 of code on github?

malcolmsparks19:01:31

git history can be rewritten, but not without changing the sha1 - and you can sign those

micha19:01:53

and the sha does provide the information about the entire lineage, like a block chain

malcolmsparks19:01:00

I sign all my jars before they are uploaded to clojars

malcolmsparks19:01:06

and I sign all my git tags

malcolmsparks19:01:15

(but it's all rather pointless without sig verification)

malcolmsparks19:01:32

@micha, yeah, you can trust the sha1 - it's hard to forge

richiardiandrea19:01:51

yeah but sha is just a hash so you cannot map 1:1 with code

micha19:01:06

i was just pointing out that you can make a malicious jar and associate it with a malicious sha, too

micha19:01:33

like rework the git history so that they match

micha19:01:14

the sha isn't mapping 1:1 with code, it's mapping 1:1 (more or less) with the sequence of commits

micha19:01:26

which is probably more useful, in fact

malcolmsparks19:01:43

@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...

malcolmsparks19:01:00

it wasn't you that built it, but a third-party...

malcolmsparks19:01:02

like circle-ci

micha19:01:34

and circle-ci could sign the jars with a legit SSL type cert

malcolmsparks19:01:43

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

micha19:01:53

that would be verified by the existing jar stuff in the JVM

richiardiandrea19:01:04

probably we are reaching high level of paranoia here 😄 So interesting!

micha19:01:38

i guess that's not true, because you can't just have a service that signs anyone's jars

malcolmsparks19:01:45

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

micha19:01:16

this si a very interesting discussion

malcolmsparks19:01:36

and that would also make using a CI server mandatory

malcolmsparks19:01:46

whether that's a good thing or not I don't know but it's intriguing

micha19:01:55

i think it's fine, really

micha19:01:03

we could automate it in boot

malcolmsparks19:01:17

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

richiardiandrea19:01:18

it should be like this in every software worth its salt, really <- mandatory CircleCI

malcolmsparks19:01:44

large organsations download our stuff, through their firewalls, every day

micha19:01:53

yeah installing jars on people's computers is pretty much the most invasive thing you can do

malcolmsparks19:01:54

it's the ultimate trojan horse opportunity

malcolmsparks19:01:41

and there's no java sandbox when you run java -jar simple_smile

micha19:01:58

especially like guice.bean.scanners:0.6.7:jar

micha20:01:15

who knows what that is, but it looks so boring i don't want to investigate

malcolmsparks20:01:21

does anyone know the circle-ci folks? do you think they would be amenable to discussing this?

malcolmsparks20:01:09

yeah, I installed keycloak last year and the number of java dependencies that came down was horrific

richiardiandrea20:01:36

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

richiardiandrea20:01:04

yep probably some initial boot support would open the doors to some more people to join in

malcolmsparks20:01:00

Does anyone know whether npm and the nodejs folks do signature verification?

malcolmsparks20:01:58

@otfrom do you know any of circle-ci crowd?

micha20:01:21

hi @otfrom

malcolmsparks20:01:26

We're musing whether there's a part they could play

malcolmsparks20:01:02

Boot itself can have an important role in the opsec ux

micha20:01:16

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

malcolmsparks20:01:17

That sounds like a disaster waiting to happen given their footprint. Mind you, we should get our own house in order first

malcolmsparks20:01:53

Good read. There's another discussion about whether clojars or jcenter

micha20:01:07

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

micha20:01:30

garbage from build tools that made it into the packages, things like that

micha20:01:42

contributers who gisted their credentials

richiardiandrea20:01:55

woah that's crazy

otfrom20:01:05

@malcolmsparks not well enough

otfrom20:01:28

👋 hello everyone

micha20:01:56

one really good thing about the maven ecosystem is that dependency graphs are pretty much immutable

micha20:01:07

i mean resolving dependencies is idempotent

micha20:01:43

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

malcolmsparks20:01:53

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

malcolmsparks20:01:40

I think the clojure community could take a lead here

micha20:01:58

the trusted build service is a really interesting angle

micha20:01:51

just publishing a specification for such a service would be a huge thing i think

micha20:01:21

because then if people put the .travis.yml or whatever in their project you could implement your own trusted build service

micha20:01:26

the .travis.yml type file would be the link between the source repo and the jar artifacts

micha20:01:31

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

micha20:01:40

hi @mikeb !

micha21:01:41

hello @aszenasi and @jarohen !

micha21:01:37

and @imre, too simple_smile

jarohen21:01:51

Scrolling up through the security discussion from earlier (thanks @malcolmsparks for the pointer)

benedek21:01:28

hi, same here simple_smile

micha21:01:40

hi @benedek

seancorfield23:01:18

OK, that was unexpected… I called util/exit-ok expecting to get a clean exit from a task but instead got an exception…