04:06
orivej has quit [Ping timeout: 260 seconds]
04:12
tankf33der has quit [Ping timeout: 272 seconds]
04:13
tankf33der has joined #picolisp
04:24
michelp has quit [Ping timeout: 272 seconds]
04:25
michelp has joined #picolisp
05:48
orivej has joined #picolisp
07:15
rob_w has joined #picolisp
07:41
mtsd has joined #picolisp
08:22
Regenaxer has left #picolisp [#picolisp]
08:22
Regenaxer has joined #picolisp
09:47
mtsd has quit [Quit: Leaving]
09:48
wineroots has quit [Ping timeout: 265 seconds]
10:08
orivej has quit [Ping timeout: 246 seconds]
10:37
orivej has joined #picolisp
10:37
Regenaxer has left #picolisp [#picolisp]
10:37
Regenaxer has joined #picolisp
10:42
Regenaxer has left #picolisp [#picolisp]
10:43
Regenaxer has joined #picolisp
11:23
Blukunfando has quit [Ping timeout: 256 seconds]
12:09
<
Regenaxer >
tankf33der, perhaps you have an idea: I want to write a
*web push client* using openssl
12:09
<
Regenaxer >
Do you know an example?
12:09
<
Regenaxer >
it is ECDH and Prime p256dh
12:13
<
Regenaxer >
Basically two tasks:
12:13
<
Regenaxer >
— Generate p256dh, encoded in URL safe base64
12:14
<
Regenaxer >
— Decrypt payload with the private key
12:15
<
tankf33der >
never heart of this push
12:16
<
Regenaxer >
What I want to do is
12:16
<
Regenaxer >
Server side example is
12:18
<
Regenaxer >
I want to receive push notifications from Mastodon here in my IRC client
12:18
<
Regenaxer >
Everything works so far
12:19
<
Regenaxer >
just the public key sending, and the decryption of the received notification, is missing
12:19
<
Regenaxer >
I'd like to use it without encryption
12:20
<
Regenaxer >
as the transfer is ssl anyway
12:20
<
Regenaxer >
but encryption cannot be avoided it seems
12:27
<
tankf33der >
yea, they expect encryption
12:28
<
Regenaxer >
Basically a good thing, but overkill in my use case
12:28
<
Regenaxer >
Not difficult,
*if* one knows how to do it ;)
12:29
<
Regenaxer >
I succeeded to generate pub and priv key with openssl from the example in the above blog
12:30
<
Regenaxer >
But what is "URL safe" base64?
12:30
<
Regenaxer >
normal base64?
12:30
<
Regenaxer >
And how to decrypt the message with the priv key?
12:52
<
tankf33der >
i will to google the subject
12:56
* beneroth
would be interested
12:57
<
beneroth >
I looked just a tiny bit into it, then went with curl
12:57
<
beneroth >
Regenaxer, no idea about "URL safe" base64, but maybe without ";" or so?
12:58
<
beneroth >
its kinda bullshit, because url-encoding rules are quite clear I would think...
13:00
<
beneroth >
Regenaxer, lol it is as I thought.
13:01
<
beneroth >
base64, but replace + with _, / with - and = percent-encoded to %3d
13:01
<
beneroth >
or leave ending = away if length of token is fixed anyway
13:03
<
beneroth >
so basically people don't understand that URL fundamentally persist of multiple parts with complete different encodings, they cannot deal with, and the few instances where they meet this fact as an obstacle they invent additional standards to make the mixture of different formats even bigger
13:14
Blukunfando has joined #picolisp
13:16
<
Regenaxer >
thanks beneroth! :)
13:17
<
Regenaxer >
I think I can use the public key I generated from the example
13:17
<
Regenaxer >
So main problem is how do decrypt the notification message with the corresponding private key
13:18
<
Regenaxer >
Concerning the "URL safe": It is bullshit already because this is a POST transaction
13:19
<
beneroth >
it's the hottest fashion, that JWT stuff
13:19
<
Regenaxer >
I think I have the token
13:19
<
Regenaxer >
I obtained from the OAuth with the Mastserver
13:20
<
Regenaxer >
I can read private timelines etc
13:20
<
beneroth >
token = base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)
13:20
<
Regenaxer >
What I need now is just the push
13:20
<
beneroth >
you use openssl via (native) ?
13:20
<
Regenaxer >
not here
13:21
<
Regenaxer >
The rest of the Mastodon is just TLS
13:21
<
beneroth >
so piped tunnel software?
13:21
<
Regenaxer >
No, very simple
13:21
<
Regenaxer >
GET and POST
13:22
<
Regenaxer >
plus @lib/json.l
13:22
<
Regenaxer >
and 'ssl' or 'curl'
13:22
<
Regenaxer >
for GET I use 'ssl'
13:24
<
Regenaxer >
btw, I improved lib/json.l in pil21 a little
13:24
<
Regenaxer >
in fact my first real use case of @lib/json.l
13:25
<
beneroth >
woah, (ssl) is new to me 0.o
13:25
<
beneroth >
so wrapper for bin/ssl
13:25
<
Regenaxer >
yeah, simple
13:25
<
Regenaxer >
same in pil64
13:25
<
beneroth >
yeah I see
13:26
<
Regenaxer >
But 'ssl' supports only GET
13:26
<
Regenaxer >
so I use 'curl' too
13:26
<
beneroth >
I would like something like this, but I want additionally to extract certificates and TLS metadata.
13:26
<
beneroth >
so I guess I should then do a custom version of bin/ssl ?
13:26
<
Regenaxer >
I would not overload it
13:26
<
Regenaxer >
'curl' does everything, no?
13:26
<
beneroth >
curl is useful. but should be updated all the time, had some security issues over time...
13:27
<
Regenaxer >
yeah, better be in control
13:27
<
beneroth >
I'm using curl, yeah. bin/ssl I only have in use for replica
13:27
<
Regenaxer >
T, that's the main use
13:28
<
Regenaxer >
BTW, ssl for replication is also improved a little in pil21
13:28
<
Regenaxer >
before, it read the file, truncated, and tried to send
13:29
<
Regenaxer >
but if ssl is killed with -15, data would be lost
13:29
<
Regenaxer >
So now it keeps the file
13:29
<
Regenaxer >
and truncates it later
13:29
<
Regenaxer >
Critical only in PilBox I think
13:29
<
Regenaxer >
Normal servers will kill with -15
13:30
<
Regenaxer >
above I meant -9
13:30
<
beneroth >
well on servers too, because if something weird happens than surely server also gets a power hard shutdown
13:30
<
Regenaxer >
cause Android kills apps with -9 !!
13:30
<
beneroth >
yeah I understand
13:30
<
beneroth >
battery saving "feature" eh?
13:30
<
Regenaxer >
Just stupid I think
13:31
<
beneroth >
what is happening with the new DB journaling data during a replica sending attempt? ending up in a new file?
13:31
<
Regenaxer >
In PilBox it is also not critical
13:31
<
Regenaxer >
if PilBox is closed, ssl continues to run
13:31
<
Regenaxer >
but if the battery would run out meanwhile ...
13:31
<
Regenaxer >
I use the same file
13:32
<
Regenaxer >
After sending, it is truncated from the beginning
13:32
<
beneroth >
so the truncate is not a full truncate but guaranteed to only delete what is sent?
13:32
<
Regenaxer >
so there is a very short moment still dangerous
13:32
<
beneroth >
there is? how so?
13:33
<
Regenaxer >
read + truncate + write rest
13:33
<
Regenaxer >
a few msecs
13:33
<
beneroth >
ah I'm afraid about 1) read 2) db writes more 3) truncate
13:33
<
Regenaxer >
no db involved
13:33
<
beneroth >
slow network connections may prolong the send step for quite long time, I would expect
13:34
<
Regenaxer >
but no problem
13:34
<
Regenaxer >
the file just gets bigger
13:34
<
Regenaxer >
Only important that it is not killed
*after* trunc and
*before* write
13:34
<
Regenaxer >
(or partial write)
13:34
<
beneroth >
I don't understand: read + truncate + write rest
13:35
<
beneroth >
ok.. who is writing here to where?
13:35
<
beneroth >
replica to network? or db to file?
13:35
<
Regenaxer >
No, ssl sends replication data to server
13:36
<
Regenaxer >
if successful, it reads the fifo/xxx, and must delete the part which was sent
13:36
<
Regenaxer >
the file may have grown meanwhile
13:36
<
Regenaxer >
But delete from the beginning is not possibll
13:36
<
Regenaxer >
so I read the whoue file again, trunc the file
13:37
<
Regenaxer >
and write back the new part
13:37
<
Regenaxer >
Cannot be done atomically
13:37
<
Regenaxer >
but takes only a few ms
13:38
<
Regenaxer >
So if the battery goes off at that moment, the replication is bad later
13:38
<
Regenaxer >
The DB is ok cause of transaction log
13:38
<
beneroth >
not losing data, but sending same data multiple times?
13:38
<
beneroth >
is the risk?
13:38
<
Regenaxer >
this can happen, but is ok
13:38
<
Regenaxer >
the journal has block
13:39
<
Regenaxer >
can be transmitted and written remotely as often as needed
14:10
orivej has quit [Ping timeout: 246 seconds]
14:19
<
Regenaxer >
I never saw a case where an Android device switched off because of battery failure
14:19
<
Regenaxer >
I suspect Android powers down cleanly before it is completely empty
14:32
<
beneroth >
I'm not so sure
14:33
<
beneroth >
I regularly used my older Samsung Android down to 2% battery. and a few times it shutdown (I think it shutdown..but unsure)
14:34
<
Regenaxer >
yes, but there must be a small safety margin
14:34
<
Regenaxer >
otherwise the memory and the battery may damage
14:36
<
Regenaxer >
Probably 0% is not zero
14:36
<
Regenaxer >
(let's hope so ;n
15:27
tankf33der has quit [Quit: Connection closed for inactivity]
15:31
rob_w has quit [Quit: Leaving]
16:26
orivej has joined #picolisp
17:27
wineroots has joined #picolisp
19:12
orivej has quit [Ping timeout: 256 seconds]
21:43
orivej has joined #picolisp