hannes changed the topic of #mirage to: bug cleaning day every first friday in month (14:00 UTC - late, next: 2nd Feb); MirageOS 3 is released, happy hacking!
smkz has quit [Quit: WeeChat 1.9.1]
smkz has joined #mirage
smkz has quit [Quit: WeeChat 1.9.1]
smkz has joined #mirage
dograt has quit [Ping timeout: 256 seconds]
mort___ has joined #mirage
argent_smith has joined #mirage
dtornabene has joined #mirage
olle has joined #mirage
AltGr has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
<mort___> random q: is anyone involved in muen around?
<reynir> ping kensan ^
<hannes> mort___: kensan is :)
<mort___> aha ta!
<mort___> kensan: muen.codelabs.ch appears to have an invalid ssl cert according to firefox
<mort___> not sure if that's your thing or not?
<mort___> "muen.codelabs.ch uses an invalid security certificate. The certificate is only valid for the following names: codelabs.ch, git.codelabs.ch, www.codelabs.ch "
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
<dstolfa> kensan: safari doesn't even open it with default settings
<kensan> mort___: Hm just a sec, let me check it out
<kensan> That's strange
<kensan> it works for me with firefox
<kensan> It's a lets encrypt cert with SHA-1 fp: 9C:12:B0:05:EE:23:66:6D:21:54:A5:C6:2C:C3:C3:DF:C6:5D:84:EA
<reynir> It seems you're not sending the CA cert along, maybe?
<kensan> The CA certificate of let's encrypt should be in your browsers certificate store...
<reynir> I think sometimes the intermediate certs are not
<hannes> kensan: no no, only the "DST Root CA X3" should be in your trust anchors, the "Let's Encrypt authority X3" should be sent by your server.
<kensan> hannes: I see. Will look into it.
<kensan> mort___: Thanks for reporting! (and also trying to visit the website ;)
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
<mort___> (sorry was afk teaching :)
<mort___> np- it looked like the cert simply didn't cover the right domain name— does LE do wildcards yet?
<mort___> fwiw this is on 57.0.4 (64-bit) which i've just noticed is telling me to restart to update
<mort___> kensan: ^
<kensan> mort___: What IP address does muen.codelabs.ch resolve for you?
dtornabene has quit [Remote host closed the connection]
<kensan> mort___: It should resolve to 81.6.36.251
<mato> kensan: FYI, it works for me (Firefox ESR 52.6.0)
<kensan> mort___: Does https://git.codelabs.ch show the same error? Can you try https://muen.sk ?
<kensan> mato: Thanks for confirming.
<kensan> I suspect that a stale DNS entry is served for that host. We updated the address some time before christmas...
<mort___> kensan: sorry afk again (more teaching…)
<mort___> : mort@greyjay:week-2$; dig +nocmd muen.codelabs.ch any +multiline +noall +answer
<mort___> muen.codelabs.ch.72460 IN A 217.150.249.120
<mort___> : mort@greyjay:week-2$; dig @8.8.4.4 +nocmd muen.codelabs.ch any +multiline +noall +answer
<mort___> muen.codelabs.ch.21599 IN A 217.150.249.120
<mort___> git.codelabs.ch resolves to the same IP but shows no error, presumably because the cert covers the name git.codelabs.ch explciitly… ?
<hannes> mort___: .oO(we're in week 4, not week 2)
<kensan> mort___: Yes indeed.
<mort___> hannes: smart arse :) it's week 2 of full term for us, and i was marking work set for this week :p
<hannes> muen.codelabs.ch. 300 IN A 81.6.36.251
<hannes> is what i get from 141.1.1.1
<kensan> mort___: Thanks for verifying. It seems that somehow our DNS update has not propagated :(
<mato> kensan: random question, in a recent PR comment you linked directly to an excerpt of code on Github, how did you do that?
<mato> kensan: I can't find the syntax for it anywhere....
<hannes> (and all ns of codelabs.ch return 81...) -- maybe you didn't bump the serial? ;)
<mort___> mato: #lineno-lineno at the end isn't it?
<kensan> hannes: Checked that, we did...
<kensan> mato: If you hover the mouse on the left side of the line you get a (+) symbol that you can use to get a link :)
<hannes> kensan: well, for me at least 8.8.8.8 and 8.8.4.4 and 9.9.9.9 all resolve muen.codelabs.ch to the 81.6.36.251...
<kensan> hannes: Yeah, it just changed in the last hour or so!
<kensan> hannes: But there are still other DNS servers resolving to the old address.
<hannes> kensan: ah, ic. yes, sure... dns and ttl is all a lie ;)
<mort___> 8.8.4.4 is resolving to the 81 address for me now
<mort___> with the new much shorter ttl
<mort___> : mort@greyjay:week-2$; dig @8.8.4.4 +nocmd muen.codelabs.ch any +multiline +noall +answer
<mort___> muen.codelabs.ch.299 IN A 81.6.36.251
<mort___> i guess it's just propagation and a long original timeout...?
<mort___> (someone — hannes! — needs to do a piece of infrastructure that couples deployment of certs with dns updates perhaps… :)
<hannes> mort___: yes! working on that! using acme (let's encrypt)
<kensan> He should get google to use the OCaml DNS implementation for its servers. *heh*
<mort___> hannes: cool :) kensan: yes! :)
<hannes> I also think provisioning should be done via dhcp on bootup (client sends hostname and csr, receives ip and let's encrypt signed certificate)
<kensan> mort___: So I assume you do not get the SSL error any longer?
<mort___> actually i do
<mort___> but i suspect that's firefox caching badly
<mort___> i'll try again in a while
<mort___> (as in, caching dns)
<mort___> time for some talk…
<kensan> mort___: Ok, thanks a lot!
<hannes> mort___: hmm, not sure. my plan is to publish (really soon now) a DNS resolver which can be run by anyone on their laptop :)
* mort___ wanders off mumbling about systems being about coupling the coupled things and decoupling the decoupled things.. ;)
<hannes> 'coz I don't really see the advantage of "caching open recursive resolvers"..
<mort___> amen to that...
<hannes> but today I'm rewiring infrastructure and computers, upgrading, etc.
<mato> kensan: thanks!
<kensan> mort___: btw, my I ask what motivated you to look at the website in the first place? ;)
<mort___> er good question
<mort___> oh yes
<mort___> the class i was taking this morning was the mphil systems reading class
<mort___> today's papers were on os structure (exokernel, unikernel, multikernel)
<kensan> Ah I see.
<mort___> someone mentioned about relying on the ocaml runtime being correct for mirage; i noted that you always rely on lots of things lower down, and i wanted to give muen as an example of proving more of the lower down things
<mort___> i think
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
<kensan> Yeah, the Trusted Computing Base with current software stacks is massive. And thanks to Meltdown/Spectre everybody is now reminded that it also includes the hardware :)
<hannes> so all we need is vmm extensions for risc-v, risc-v chips with vmm extensions, and muen on risc-v then? :)
<dstolfa> hannes: well, an open ISA alone doesn't make the hardware itself open
<kensan> hannes: The first part is being worked on. There is a draft for hypervisor extensions for the RISC-V ISA.
<kensan> hannes: Supposedly implementation in the SPIKE ISA emulator is slated for Q1/18 with QEMU support following that.
<kensan> hannes: So err... very early days *hehe*
<mort___> let's just target the megacomputer
<mort___> that way manual inspection will suffice to see the attack presumably
mort___ has quit [Quit: Leaving.]
mort___ has joined #mirage
<kensan> Right, we fixed the DNS issues. Once all caches are flushed and replenished everybody should receive the correct IP address.
<kensan> mort___: Thanks again for reporting!
dograt has joined #mirage
olle has quit [Quit: olle]
<mort___> np!
demonimin has quit [Ping timeout: 268 seconds]
demonimin has joined #mirage
mort___ has quit [Quit: Leaving.]
AltGr has left #mirage [#mirage]
argent_smith has quit [Quit: Leaving.]
mort___ has joined #mirage