<pie_>
11:50 @pie_: I think I read some article yesterday about a supply chain attack and it kind of feels like we should prioritize on our supply chain integrity?
<pie_>
11:52 @pie_: On mobile btw so I’ll probably be intermittent for a bit
<pie_>
11:51 @pie_: On the other hand I’m not sure how much we can really do other than not be the element that gets owned because you can just hit upstream
<pie_>
Joined wrong channel at first :p
pie_ has quit [Quit: a]
pie_ has joined #nixos-security
<pie_>
so did I miss anything? :P
<gchristensen>
no
<gchristensen>
security is not being immune to attack, but patching what you can, and anticipating it and knowing what you'll do when you are pwnd
<pie_>
that sounds like a sad compromise :(
<gchristensen>
it isn't a compromise, it is the truth
<gchristensen>
because anticipating and planning is where you get to mitigating damage, an important component of protection
<pie_>
sure i didnt say dont do mitigation
<gchristensen>
sorry, its the facts
<gchristensen>
this is where threat models come in
<gchristensen>
and almost all threat models include sections where you say "well, I guess we'll be pwnd"
<tilpner>
And speaking of, is there a list of who contributes Hydra machines?
<pie_>
so i think github lets you use hashes of commits even if they arent merged into main yet
<pie_>
dont quote me on that
<qyliss^work>
It does, yes.
<qyliss^work>
All forks are one repo under the hood.
<tilpner>
If it is random people, there's a lot of trust placed on them
<pie_>
so maybe you could use a malicious commit hash in a version bump push
<pie_>
and thats not so easy to see
<pie_>
(?)
<andi->
I do not think that is is random people. The questions I'd (currently) ask is if they are physically trustworthy, how initial trust was established (if not underneath someones table and transitive trust models can be applied) etc...
<gchristensen>
tilpner: vcunat contributes 2 macs, all of the rest is maintained by the foundation
<tilpner>
Oh, that is good to hear :)
<gchristensen>
the foundation doesn't accept donations of CPU time
<andi->
Most of my points are relevant but for my personal threat models not an issue. I think the reproducibility (r13y.com) and the RFC#17 (intensional store) can at least eliminate a lot of the "tampering with the build outputs" cases.. Given that someone tries to reproduce/verifies things :-)
<tilpner>
gchristensen: I was looking at status.nixos.org a while ago and found a bunch of machine names that made me think they came from many different sources
<gchristensen>
they do
<tilpner>
E.g. lucifer.ewi.tudelft.nl
<gchristensen>
yeah
<gchristensen>
nixos has several machines hosted at tudelft
<gchristensen>
in their datacenter
<tilpner>
And EC2 and Packet and Cunat? That's less random than I remembered (which is good!)
<gchristensen>
and Hetzner
<tilpner>
Oh, why so many different providers?
<tilpner>
EC2 for burst usage perhaps, but Packet and Hetzner seem like the fill the same-ish niche (except ARM maybe)
<tilpner>
*the
<andi->
i think sponsorship is the thing here.
<gchristensen>
right
<gchristensen>
and grant money
<gchristensen>
tudelft hw is from a big grant from (wow) 2007
<gchristensen>
ec2 is almost entirely burst (though we have a couple small always-on machines there)
<gchristensen>
packet has written us a blank cheque for whatever we want
<gchristensen>
and hetzner has cheap servers on the auction thing
<gchristensen>
we don't really have budget to make simplifications like decide we'll just host everything at «companyA»
<gchristensen>
at any rate
<qyliss^work>
Real solution here is reproducibility
<gchristensen>
the foundation definitely knows the build farm is a key center of trust, and treats it with the access control appropriate for that
<tilpner>
I see. Thanks for clarifying! :)
<gchristensen>
yep :)
<gchristensen>
reproducibility is a huge thing, for sure
<gchristensen>
speaking of reproducibility
<gchristensen>
https://r13y.com/ anyone want to try and tackle the new docker-runc and docker-containerd instability?
<andi->
I gave the man-db a shot yesterday anf lost myself in the Makefiles
<gchristensen>
same :(
<tilpner>
Yeah
<andi->
I didn't want a stupid sed (in addition to theirs) to remove the issue
<tilpner>
I gave up man-db in favor of a faketime hook
<gchristensen>
what does debian do?
<andi->
they are upstream and the changelog is very quiet about that
<andi->
they have a sed script in tree that is supposed to run when they do po-file renderings
<gchristensen>
:|
<andi->
they also have a dependency on something (forgot name by now) which depends on man-db and causes recursion.. The process might not run for us since we are using bundled/release files?!?
<andi->
we might want to coordinate fixing the issue better.. If we alone are 3 people that poked at it...
<gchristensen>
#reproducibile-builds is also a good place to chat across OS's
<andi->
not on freenode?
<andi->
OFTC I guess?
<gchristensen>
o
<gchristensen>
yeah, OFTC :)
<pie_>
hm
<Foxboron>
If you want to chat to someone that has worked on supply chain integrity, sangy from NYU/Arch is a good guy to chat with.