<avsm1>
I'm missing this one from the tls pull req
<avsm1>
dont the cstubs need to be synched? Curious about how it boots without them :)
<thomasga>
still using cstruct 1.5.0
agarwal1975 has joined #mirage
<avsm1>
aha
<avsm1>
no harm in releasing new mirage-xen is there? i can do that now
<avsm1>
that'll reduce the load on the constraint engine
<thomasga>
yea that would be neat to avoid recompilation as well
<thomasga>
(as there can be a lot of upgrade/downgrade between cstrcut 1.5.0 and 1.6.0)
mcclurmc has joined #mirage
<avsm1>
ok
avsm1 has quit [Read error: Connection reset by peer]
avsm has joined #mirage
<avsm>
thomasga: is the openmirage.org checkout on miriod on punk the TLS fork?
<avsm>
the configure.sh doesnt seem to have TLS=1
<thomasga>
only mirage.io
<thomasga>
openmirage.org is master
<avsm>
aha got it
<avsm>
ill merge with mirage.io and do a proper fix later
<avsm>
just getting redirect sorted
<thomasga>
the config on miriod is not totally obvious though
<thomasga>
would be nice to document it somewhere when it's stable :-)
<avsm>
just getting one kernel booted first :)
<thomasga>
yup
<avsm>
that TLS key stuff is confusing to setup
<hannes>
"TLS key stuff"?
<thomasga>
if you have any better idea for the user interface, feel free to propose. Currently I'm moving the keys in a temporary dir anyway for crunching
<thomasga>
(at lest in mirage-seal)
<avsm>
hannes: the .pem and .crt
<avsm>
right now you have to concat the gandi crt and intermediate cert
<avsm>
and then private key in another file
<avsm>
and if you concat the certs in the wrong order then you get an exception
<hannes>
we can also use a single file...
<avsm>
right, i just randomly muddled around until it worked
<hannes>
we could also do reordering within ocaml-tls...
<avsm>
is that reliable?
<avsm>
i guess it is. there's only one combintaion that makes sense :)
<hannes>
well, according to the ietf working group, the only demand is that server certificate comes first, random order later...
<avsm>
basically it would be useful in tlstunnel to give instructions on what those keys and certs arguments mean
<avsm>
ah interesting!
<avsm>
i can annotate them with the gandi specific instructions (and i'm sure others will pitch in too)
<hannes>
spec says server cert, then in order chain... but implementations seems to ignore ordering.. wg still discussing what they should write in the new rfc (and whether they should relax it according to the real world)
<hannes>
my opinion is that we should be as relax as needed for the real world... and in our server setup I'd demand/sort the certificates
<hannes>
and by sorting I mean we can easily try out any order and look which one fits well (and use this)... if it is not a chain, complain to the user
<avsm>
alright i'll create an issue on tlstunnel then
<avsm>
although the fix is in tls really isnt it?
<hannes>
yes.. I'm creating an issue... it is partially in tls (the sending side), and partially in x509 (the receiving side)
<hannes>
for tlstunnel btw, key can be in the cert pem, and if no --key is specified, the --cert is used..
wildsebastian has quit [Quit: Konversation terminated!]
<avsm>
ok great
<avsm>
hannes: eyah i like the tlstunnel behaviour, but just adding info in the README about what to do is most useful
<avsm>
most other stud/stunnel also dont document this, which i hate :)