26 Nov 2020 |
propensive | Try publishing, and see how badly that's broken... 😉 | 00:29:03 |
propensive | You can check, cat ~/.config/fury/config.fury to see if there's a token listed. | 00:29:39 |
jozinek#0918 | yep, there is | 00:30:37 |
propensive | You should be able to publish, then. | 00:30:53 |
jozinek#0918 | fury layer publish --public --name jozi-k/scala
Checking that no modules reference local sources
The module contains references to local sources. | 00:32:48 |
jozinek#0918 | do I commit the layer? | 00:33:01 |
propensive | No, it wasn't able to publish because the layer is using sources on your hard disk. | 00:33:26 |
propensive | The idea is that you can publish a layer which depends on external Git repositories, but not if there are local sources. | 00:34:05 |
jozinek#0918 | thats right, need to unset the source then? | 00:34:27 |
propensive | That should do it. | 00:34:36 |
propensive | If you can add a repo (fury repo add -R gh:jozi-k/whatever ) with Scala sources in it, you can add a reference to them. | 00:35:21 |
jozinek#0918 | fury layer publish --public --name jozi-k/scala
Checking that no modules reference local sources
Checking that no project names conflict
Checking that all module references resolve
Publishing layer to service vent.dev
There was an invalid interaction with a third-party service | 00:35:24 |
propensive | Hmm | 00:35:31 |
propensive | That's what happens when it fails to connect to either GitHub or Piñata (which is the IPFS service which hosts the layer data). | 00:36:08 |
propensive | I'll take a closer look soon. | 00:36:26 |
propensive | I have a few layers to publish, so I need to work it out! | 00:36:44 |
propensive | I could embed the actual error in the response to Fury. | 00:37:42 |
propensive | At the moment it just sends back the "ThirdPartyError" response. | 00:37:55 |
jozinek#0918 | ok, I will try to build some real project | 00:38:38 |
28 Nov 2020 |
jozinek#0918 | Hi propensive I am currently successfully building my sandbox project but only as a lib module, when I try to actually run the code via app module it fails with:
Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "zio.json.number.bits" "read")
Also tried other project (with different library):
Exception in thread "main" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "modifyThread")
so it seems like general problem with accessing jvm internals. | 23:03:18 |
jozinek#0918 | Actually I cannot push the layer so you would not be able to reproduce this behaviour. | 23:07:24 |
29 Nov 2020 |
propensive | jozinek You have two options! | 11:42:27 |
propensive | The idea is that apps invoked by Fury shouldn't just be able to do anything they like. So you need to grant permissions, or disable the security manager. | 11:43:22 |
propensive | You can run with fury build run --disable-security-manager and everything will work. | 11:43:37 |
propensive | Otherwise, you can add permissions with, for example, fury permission require -C java.lang.RuntimePermission -T modifyThread or fury permission require -C java.util.PropertyPermission -T zio.json.number.bits -A read | 11:44:56 |
propensive | The three relevant parameters are Class, Target and Action, in the order they appear in error messages, and the action is optional. | 11:47:08 |
propensive | The permission require command specifies that your module (and downstream modules) need that permission, but additionally grants it on your system. | 11:48:11 |
propensive | If you list all the permissions you need as "required" and then publish the layer, and someone else tries to run it, then they won't even be allowed to try to run it until they have explicitly granted the permissions. | 11:49:25 |
propensive | That can be a bit fiddly to do, so I'm planning to improve the UI there. | 11:50:50 |
propensive | But there's another interesting project you might be interested in working on, which would give you more exposure to Java's security manager, and should be a nice little project... | 11:51:33 |