@eyedeekay
&eche|on
&kytv
+R4SAS
+RN
+T3s|4
+acetone
+dr|z3d
+orignal
+postman
+weko
Afkaid
Arch
DeltaOreo
FreefallHeavens_
Hikari
Irc2PGuest30202
Irc2PGuest42421
Irc2PGuest63764
Irc2PGuest83825
Leopold
Monokel
Nausicaa
Onn4l7h
Sleepy
Soni
T3s|4_
Teeed
aargh4
anon4
b3t4f4c3__
dr4wd3
eyedeekay_bnc
hagen_
itsjustme
limak
not_bob_afk
poriori_
profetikla
rapidash
tbqdrn
u5657
w8rabbit
wodencafe
x74a6
zzz
zzz
interesting thread on a guy trying to be his own postman + eche|on i2pforum.i2p/viewtopic.php?p=3065
zzz
eche|on didn't quite realize what he was asking for...
zzz
eyedeekay, thanks for the MR review last week, but if you could pick up the review pace that would be great, your posted deadline is looming
zzz
eche|on, can you raise the logged-in cookie timeout on i2pforum.i2p? It seems to only last about 15 minutes which is really annoying
eyedeekay
psi did something which supposedly works for in net mail which is mostly self configuring github.com/majestrate/bdsmail but I have never tried it
eyedeekay
I will do the rest of the pending reviews today
zzz
thanks
zzz
some are draft but still would appreciate a look
zzz
here's my status stats.i2p/docs/roadmap-2.6-zzz.html
zzz
acutally let me undraft the snark one now
zzz
hadn't heard of bdsmail, interesting. The forum guy has his server of choice already, thought there was some magic gateway out there waiting for him
zzz
didn't sound like he cared about in-net server-to-server
eyedeekay
Thanks re: status
zzz
eyedeekay, see my comment on your forum post on the 2.6 schedule re: dev updates, they need to be at an in-net url for automation to work I think
zzz
and a full howto would be helpful
eyedeekay
Sure I can set up an in-net URL for it and write a howto
zzz
and if you're building every rev why are we tagging the -x revs? or are there two tracks, one for every rev and one for tagged ones?
eyedeekay
The tagged ones are to make it easier to keep track of what I'm using when I do dev builds of anything that depends on the artifacts we upload to Maven. I don't have 2 tracks set up but it's <3 lines of config to set up so I'm going to do that
zzz
super. the goal is to up the number of people testing, so let's push through with howtos and posts everywhere to make it happen
eyedeekay
Sure, I'll get some of those going and/or published soon
zzz
it would take some more automation, but you could even set up separate signed news feeds and stuff the git revs or history diffs into a <pre> in a news feed entry and have it all just automatic
zzz
so every rev or every tag is a news entry and a new su3
eyedeekay
I'm inching my way toward exactly that, using i2p.firefox and i2p.android.base to try things like setting up alternate signing keys and newsfeed generation from git log for the buildbots before I move them up to i2p.i2p
eyedeekay
Right now buildbot-identifying-signing-keys is the key todo for i2p.android.base CI/CD
eyedeekay
Once I figure that out I'll be able to do su3's with similar buildbot-identifying-keys
zzz
?? what is identifying-keys about?
eyedeekay
Giving signed builds created by bots keys that say buildbot-maintainer@mail.i2p or something instead of my release keys
zzz
but then users would have to add the pubkey certs for those to certificates/, right?
eyedeekay
Yes but IMO they should, both because I don't think I should keep my release keys online on the server, and because if one or the other set of keys got stolen it would be possible to revoke one at a time
zzz
to do it right, you'd sign the buildbot keys with your release keys, and we fixup the sig verification to handle ssl cert chains
zzz
your news servers have your news privkeys on them, so just do the update signing there too?
zzz
or have a signing service on a different machine?
eyedeekay
No they don't actually, I sign in a VM on my laptop and upload static artifacts
zzz
I don't see how having the buildbot sign the su3 is magically secure if you hand it some unique signing key
zzz
the way su3 works you're just signing a hash, so there's not a lot of data going back and forth, if you do it right
zzz
seems like "identifying keys" solves nothing though?
eyedeekay
My thinking is that servers suspected of being part of our infra are potentially targeted, so leaving sensitive things on them is maybe not good
eyedeekay
Up to this point my keys have never been on a device which is always online or out of my physical control/possession, like 99% of the time the device they're on isn't plugged in.
eyedeekay
CI in general seems to expose a lot of attack surface, so that server makes me especially cautioud
zzz
sure, I get that part, but if you put a different privkey on the CI and then ask our users to trust that key, nothing has changed, right?
eyedeekay
Yes nothing has changed, the only advantage is that we can delete one key at a time
eyedeekay
And I should be able to stay online from now on...
eyedeekay
Actual cert chains are an interesting idea esp in light of plugins, might like to have one root key and sub-keys for dev builds, newsfeeds, plugins, reseed etc
eyedeekay
Well that and that they don't trust the dev build key by default, so it can only be used by people who opt-in to updates
eyedeekay
We could even give people a switch "enable dev builds" which copies the key from some inert location in the base dir to the appropriate certificates/*/ directories
zzz
I think it makes more sense to just build the zip on the CI server, then have some automation to copy it over and create the su3 on your laptop and push it to the news servers