<gchristensen>
you know you're in a bad place when github won't render the file in the diff
<andi->
gchristensen: well, my firefox doesn't have access to the system fonts .. Probably the reason. Haven't made up my mind if that is a good or bad sign for websites :-)
<MichaelRaskin>
I just wanted to handle a few hanging PRs with a request review towards me, but of course the problem is always about Darwin…
jtojnar has quit [Remote host closed the connection]
<gchristensen>
infinisil: yep, sorry -- I missed that
<gchristensen>
infinisil: we could hook that up, sure
<infinisil>
gchristensen: Cool, what do I need to know to do this?
<gchristensen>
well ... I need to build it :P
<gchristensen>
nobody has asked for it until now
<gchristensen>
will you want every channel, or just some of them? would you want to filter?
<gchristensen>
what is your use case?
<infinisil>
gchristensen: Two use cases: For one I'd like for my nixbot to get the update events, so I can have variables stable/nixos-1809 or so to always point to the actual channel version, instead of just the nixpkgs-channels one
<gchristensen>
oh cool
<infinisil>
And another is an experiment for some nixpkgs automation experiments
<infinisil>
(that could've been worded better)
<infinisil>
I'd want every channel probably, no filter needed
<gchristensen>
cool
<infinisil>
gchristensen: Ah so to implement this, you'd add a list of urls it should make an http post request to when channel updates happen
<infinisil>
And I'd give you the url to my server
<gchristensen>
we could do that
<gchristensen>
another option is I could send you a rabbitmq message
<gchristensen>
what is your preference?
<infinisil>
Oh right, well I'm not too much of a fan of rabbitmq, since it's quite a hassle to set up and understand, but it might be good to have stuff like knowing that a message arrived
<gchristensen>
I'm not sure I understand the "But it might be good..." part
<infinisil>
The thing about confirmation requests, and acks, and stuff
<infinisil>
But anyways, I'd prefer a simple http thing
<gchristensen>
ah
<gchristensen>
in that case, yeah, I'd probabl ysend you a little JSON blob with content-type: application/json
<infinisil>
That sounds good
<gchristensen>
I suppose ideally it'd be signed with a shared secret you can validate
<gchristensen>
would you check it?
<infinisil>
Or a signature of your domain
<infinisil>
Yeah some security would probably be a good idea
<gchristensen>
ok
* infinisil
thinks about how that should work
<infinisil>
gchristensen: Found this idea on SO: Instead of sending the data in a message to my server, just send a "Something changed" message, then I curl your server for the updated data, all going through TLS
<gchristensen>
you'd need to curl each channel
<gchristensen>
there isn't a single url you could fetch
<gchristensen>
give me 15min to relax and finish off this PR ^ and then I'll think on the webhook a bit
<gchristensen>
oh, heh
<gchristensen>
no need for a shared secret
<gchristensen>
it can be a well known public key / private key thing
<gchristensen>
since it isn't tailored for *you*
<andi->
I was thinking about just having tags on channel bumps in nixpkgs-channel.. Wouldn't that remove a bit of the need for your channel bump history? (My use-case would become easier, …)
<gchristensen>
not sure git likes that many tags
<andi->
The way I understand it checking out a tag would be easier on it then "crawling" for it..
<andi->
The slowest part of my use-case is currently checking out the commits :/
<gchristensen>
hrm
<andi->
but don't let me stop you now :-) Shouldn't be around at this time anyway..
<gchristensen>
git doesn't store tags well
<infinisil>
gchristensen: No need to do this today, I don't have much time right now anyways
<infinisil>
After looking at it some more, I think the most reasonable thing to have security is to use TLS with client cert verification
<infinisil>
s/thing/thing to do/
<gchristensen>
I don't often hear TLS client certs and "reasonable" in the same sentence
<infinisil>
Hmm.. yeah and I don't even know if it's possible to only allow a specific certificate..
<gchristensen>
the threat model here is: "somebody not me sends you junk data"
<infinisil>
Yeah
<gchristensen>
the data is not unique to you, if I send it to 1 or 100 people it is the same
<infinisil>
So we don't need encryption, only integrity, and also replay attacks should be prevented
<infinisil>
(but replay-attack prevention is only a nice-to-have, not necessary)