|
00:04
librasteve_ left
01:05
kjp left
01:23
kjp joined
|
|||
| Geth | MoarVM: MasterDuke17++ created pull request #2004: Check results of explicitly allocating from libc |
02:05 | |
|
04:52
apogee_ntv left
04:53
apogee_ntv joined
05:57
librasteve_ joined
|
|||
| Geth | MoarVM/main: f2e25d78d5 | MasterDuke17++ (committed using GitHub Web editor) | 2 files Check results of explicitly allocating from libc (#2004) Otherwise we could leak and/or dereference NULLs. |
08:19 | |
| MoarVM: orbisai0security++ created pull request #2005: fix: the moarvm debug server accepts connections and... in debugserver.c |
08:56 | ||
|
12:01
disbot2 left
12:02
disbot3 joined
|
|||
| timo | something we could do for access control to the debug server socket is to require a "password" / token to be passed early on in a connection attempt which moar would write to a file umasked 077 in $TEMP so if a different user wants than the process owner wants to connect, they just have to "prove" they can read that file | 12:12 | |
| then a debug client can either try to read the file automatically and just send it, or tell the user where to find the file and ask for the contents to be copy-pasted | |||
| unix domain sockets would be possible, too. there is an equivalent on windows AFAIK but I'm not sure how it works | 12:13 | ||
| how does the java management interface or whatever it's called do it? I seem to recall you can set a host and port, probably also a password, right? potentially also TLS keys and certs and such? | 12:16 | ||
| how well would it work to have an anonymous socket as an FD that you have to pull out of /proc/$PID/fd/N? :D | 12:17 | ||