<lrvick>
happy to give contributor access to anyone that wants to help refine this before we merge it up
<lrvick>
(not made PR yet)
<adisbladis>
samueldr: It depends on your threat model. Signing everything at the very least can be used to make sure a commit wasn't just inserted into history by a malicious party.
<srhb>
lrvick: This new rfc seems to conflate some sort of binary hashing into everything you mentioned last time?
<srhb>
I think that's undesirable as a general solution. Again, the existence of the cache and reproducibility are not givens. And it's unlikely that a maintainer will build eg. chromium before pushing it off to the build server, and presumably we don't want to build server to ever build anything that's untrusted, so it cannot rely on the build artifact existing yet in order to establish trust.
<srhb>
Everything that assumes that we need to build anything first to establish a trust model is, imo, a bad idea. Caches and binary artifacts are conveniences, very nice conveniences, but they really aren't a fundamental part of distributing nixpkgs, contrary to how other distros work.
<adisbladis>
Also: If possible I'd like to see real-world implementations of any proposal if possible
<adisbladis>
I have never seen anyone else using a patch-id approach.
<adisbladis>
I'd like to see what problems that will bring
<adisbladis>
srhb: That's not even considering that not all builds are reproducible. There are certain valid cases where hashes will not match.
<adisbladis>
Firefox (and probably chrome) being some of those
<srhb>
Indeed.
<srhb>
I don't think this will fly as a proposal if it doesn't stick to being about verifying authorship of nix expressions
<srhb>
Binaries should be a separate concern (and a much simpler one: Do you trust the substituter)
<adisbladis>
++
<adisbladis>
The more I think about this problem the more questions I end up with
<srhb>
So far I'm completely on-board with verifying authorship of nix expressions (if it can be implemented)
<sphalerite>
srhb: isn't it more a matter of "do you trust the owner of the signing key?"?
<sphalerite>
I can use samueldr's mirror of dezgeg's cache without placing any particular trust in samueldr
<srhb>
Yes.
<srhb>
My point was merely that it's a separate concern entirely. :)
<adisbladis>
It seems that the only mayor distro that enforces commit signing is gentoo.
<adisbladis>
I cloned some debian/fedora repos and no sigs
<adisbladis>
Arch is using svn
<adisbladis>
Suse I haven't checked yet
<srhb>
Gentoo is probably the place we can expect to find the most ideas, good call.
<srhb>
(Since it matches our "package" distribution model better)
<andi->
I am also questioning the benefit of signing things like "i bumped all the python/haskell/.. packages to the latest versions". If you still think about someone putting a backdoor in those packages would be the right place.. We have plenty of them and they are just being bumped semi-automagically. Also thinking about automated package updates in general makes me think the signatures would not really
<andi->
provide much additional trust seeing how little time is spent reading the changelogs or actually looking at the updated code.. If it is just about nixpkgs then this would work but it's probably not the weakest link in the entire chain..
<srhb>
andi-: I don't think we should start tackling transitive trust yet :D
<srhb>
andi-: "peti trusts hackage, we trust peti, haskellPackages got bumped" is ok for now :P
<srhb>
Keeping this effort minimally scoped is going to be hard enough as it is! :P
<adisbladis>
I'm not clear on how gentoo is tackling the initial trust
<ivan>
people worry about the nix expressions but the much better place to insert malware is in that 4MB configure script that no one ever looks at
<pie_>
ivan, yeah but still :P
<ivan>
we don't even check if tarballs match what's in the VCS
<pie_>
its also easy to make a typo in a url and redirect to some malicious bundle
<pie_>
"typo"
<ivan>
or regenerate configure scripts with the same autoconf, I assume (haven't checked)
<ivan>
pie_: what's the exact attack scenario?
<pie_>
random scenatio: submit a patch pointing fetchgit to g1thub.com instead of github.com?
<pie_>
ivan, ok i dont actually have one :p
<ivan>
heh
<pie_>
but integrity is undeniably good right? :p
<ivan>
try some cyrillic letters at least
<pie_>
well, /technically/ git provides integrity up to HEAD? so really this is about attribution of trust
<srhb>
ivan: What configure script is that? :P
<pie_>
which is kind of like integrity :P (?)
<pie_>
being able to trust nixos/nixpkgs i still important even if you need to decide separately whether the package you want to install is
<pie_>
*is trustworthy
<ivan>
gіthub.com / xn--gthub-n2e.com (available)
<pie_>
well then :P
<ivan>
srhb: PHP has a big one (I checked a few years ago), but other things do too
<adisbladis>
You can trust us to have the same backdoors as upstream :P
<ivan>
haha
<pie_>
also ok actual question how do we protect against that too re url lookalikes
<ivan>
check if nix even does the punycode conversion
<adisbladis>
Seriously though.. Commit signing is the easy part. How do you handle keys at this scale?
<pie_>
yeah i was wndering
<pie_>
@ punycode
<adisbladis>
ivan: Iirc it's passed off to curl as a string
<ivan>
hah wow 1and1 is refusing to let me buy my github domain ("Please use only characters from one character set.")
<pie_>
inb4 their interface cant handle it
<pie_>
encodings r hard :P
<ivan>
if I get it I wonder if markmonitor will write me a nastygram within the hour
<ekleog>
andi-: IMO this is a problem of responsibility: if upstream's code has a backdoor, it's upstream's responsibility. If nixpkgs code has a backdoor, we must be able to point out a contributor responsible for it
<andi->
ekleog: what is a backdoor in nixpkgs for you? Someone putting a patch in adding it or pointing a deriviation to another (newer?) version that has the backdoor?
<ivan>
whether or not it's upstream's responsibility you're the one getting your data exfiltrated
<srhb>
ekleog: Agreed.
<ekleog>
adisbladis: my view of handling keys is just putting the public key in the repository (so not like gentoo at all), and requiring all commits to be signed with an already-present key, so no complex key handling
<ekleog>
andi-: exactly what you said, or pointing to something that's not upstream (eg. the punicode url thing raised by ivan)
<ekleog>
(if upstream does have a backdoor in an updated version that wasn't there in the initial version and the backdoor is not well-known, then it's a mistake we couldn't reasonably prevent anyway)
<andi->
ok
<andi->
so we are on the same page :-)
<ekleog>
:)
<adisbladis>
ekleog: Yeah that would make distribution easy.
<adisbladis>
I like this: " Every commit on the left-most line of the history (that is, all the commits following the first parent of each commit) must be GPG signed by a Gentoo developer."
<adisbladis>
I take that as meaning "not every commit has to be signed, only merge commits and rebased commits"
<andi->
that might actually be a good way to do it. Picking up on what samueldr wrote yesterday about signing everything. If you just sign all development commits those probably do not have any special care in regards to verifying what you created...
viaken2 has joined #nixos-security
tilpner_ has joined #nixos-security
ivan_ has joined #nixos-security
viaken has quit [Ping timeout: 240 seconds]
ivan has quit [Ping timeout: 240 seconds]
tilpner has quit [Ping timeout: 240 seconds]
spacefrogg has quit [Ping timeout: 240 seconds]
tilpner_ is now known as tilpner
ivan_ is now known as ivan
spacefrogg has joined #nixos-security
<pie_>
ekleog, it feels a bit uncomfortable that that would make key handling heterogneeous, adding is easy, revocation is out of band? i dont have any solutions.
<pie_>
@ keys in repo can be accepted as signing keys
<pie_>
i dont actually dislike that since its nice and accessible, its just kind of weird @ revocation
<ekleog>
pie_: revocation is just someone removing the public key of someone else
<ekleog>
the fact revocation isn't out-of-band can maybe be a problem indeed, if a committer + github are both compromised, but well…
<pie_>
ekleog, no i mean, you cant retroactively remove a key from the repo
<ekleog>
then, there are tricks like having all keys in the repo also on keyservers and signed by a nixos master key and distributing the revocation certificate through keyservers in parallel, but I'm not sure what it'd bring
<pie_>
thus revocation *must* be out of band
<ekleog>
oh. well, then yeah, you can't retroactively remove a key, but why would you need to?
<ekleog>
it'd invalidate previous signatures made by said key, which would break the trust model
<pie_>
isnt the trust already broken if you want to invalidate a key
<ekleog>
well, it can simply be someone resigning from their job as contributor
<pie_>
ok what about the less nice case
<pie_>
obviously we'd hope it never happens regardless
<ekleog>
if eg. I push a backdoor, then you'll remove my key, and check all my previous commits
<ekleog>
I won't be able to push any commit from the point of key removal onwards
<pie_>
and i dont necessarily mean malicious developer, i mean what if their key/mahcine got compromised
<ekleog>
same behaviour if key/machine is compromised, except you can add a new key from me after that :°
<ekleog>
(and maybe metadata on the compromise can help identify only a subset of commits to be checked)
<pie_>
well, im not convinced but i dont have any counterarguments
<pie_>
ok so
<ekleog>
I mean, I can't see any additional advantage brought by revocation :)
<pie_>
so what if someone wants to load a repo version thats compromised
<pie_>
hhmmmmmm
<pie_>
actually thats a larger issue, because it applies to any sort of vulnerability
<pie_>
i think this is a problem but i dont have any solutions
<ekleog>
yeah, if someone wants to load a repo version that's compromised, the only thing we could do against that is history rewriting
<pie_>
say, inadvertently loading a nixpkgs version with a glibc vulnerability or something because you just want your program to run
<ekleog>
and with hundreds of contributors, well… :/
<pie_>
ok sure but the user has no notifications of the problem
<pie_>
the problem is theres some meta stuff going on here, and you cant really rewrite history obviouslt
<ekleog>
maybe there could be a file “insecure-revisions” at master, that lists known-insecure revisions, but (it's orthogonal to the current discussion of signing nixpkgs, and) it'd be hard to track by hand -- maybe andi-'s website could help for the CVE tracking part, at least, I dunno
<pie_>
yeah i agree that its orthogonal
<pie_>
it just came up as i was thinking about htis, but i think this is something we could do something about
<ekleog>
then some tooling would always check nixos/master for the “insecure-revisions” file and warn if it's checking out an insecure revision
<ekleog>
this is something we can try doing something about, at least, indeed :) though it sounds quite… time-consuming, even just the part about tracking what's secure and what's not
<ekleog>
(esp. as ~all revisions likely have some known vuln, so it'd have to be not only revision-level but also package-level)
<pie_>
but since its so easy for us to deal with various versions, i think its important to consider that as something users actually do and try to harden it
<pie_>
(or im wrong :P)
<ekleog>
(so actually my insecure-revisions idea wouldn't work)
<pie_>
i was thinking out loud to someone the other day that as it stands nixpkgs history and package history are conflated, which might not be ideal
<ekleog>
no, I agree it's an important problem too :) though I think andi-'s work for it will be a great cornerstone that we'll be able to try to improve on later
<pie_>
it should be possible for nixpkgs to always go forward while still being able to navigate package versions
<pie_>
(which probably runs into engineering issues, but after some thought, i think this is a thing regardles)
<ekleog>
yeah, that would be great too
<adisbladis>
I spoke to a previous gentoo developer about this
<pie_>
ekleog, do you maybe understand what im trying to say? i have a hard time wording this: meta verisoning and versioning
<adisbladis>
They rely entirely on github for key distribution
<pie_>
ekleog, basically some kind of two level git and i have no idea how something like that should/could work :P
<adisbladis>
So register key with github (& push to keyserver), revocation is handled in the usual pgp keyserver manner
<ekleog>
pie_: I think I already thought similar stuff: keep all previous versions of packages in nixpkgs. The problem is 1. hydra time, and 2. when I bump glibc, should I also bump it in old-firefox, or not? the advantage of nixpkgs is it's a package set that's known to work
<pie_>
ekleog, I really dont know
<pie_>
but i think it should somehow be a superset of how things currently wor
<pie_>
aaaanyway...signing :P
<pie_>
question: how *right* do we need to get it the first time?
<ekleog>
adisbladis: tbh, I think just storing the public keys in the repository would make for a simpler system than keyservers, as keyservers & WoT (both required for this scheme) are *the* hard part of OpenPGP (imo) :)
<pie_>
changing a large amount of developers workflow is of course a huge pain in the ass and inertia...what if we think of improvements later?
<adisbladis>
pie_: We can start doing things without fully enforcing them
<adisbladis>
ekleog: Fully agree
<pie_>
i dont really have a problem with keys in repo, im just scratcihn my head about revocation
<pie_>
if you dont have a good revocation scheme is there really any point to doing this?
<ekleog>
then, in exchange storing the public keys in the repository means having to develop custom tooling (at least the “how do I prevent a developer's pull from pulling in an unsigned commit” part, as github can't do this one)
<adisbladis>
pie_: You can enforce that keys are in nixpkgs AND pushed to keyservers
<ekleog>
pie_: the thing is, you don't need retroactive revocation, you only need standard revocation
<ekleog>
(ie. after the revocation the key is no longer allowed to commit)
<pie_>
ekleog, i guess we disagree on that, but my disagreement is just gut feeling :P, so feel free to ignore
<pie_>
just @ no retroactive
<pie_>
otherwise i agree
<adisbladis>
What would retroactive revocation mean?
<ekleog>
'k ^^ if you can find a threat model needing retroactive revocation for mitigation then I'd be interested in hearing it :)
<ekleog>
adisbladis: being able to invalidate previous signatures already made
<pie_>
adisbladis, removing trust from previously signed commits
<adisbladis>
Yes, but how would it be handled?
<pie_>
well thats the question
* ekleog
votes for “it doesn't need to, and actually it'd break someone coming in later and wishing to verify the whole history” :°
* pie_
still feels like theyd be verifying partially untrustable history, technically :P
<pie_>
yes there would need to be a way to "patch" the gap, i have no solutions
<pie_>
but technically there would need to be a way to patch the gap anyway
<pie_>
you just wanted to decrease the size of the gap to a more manageable level i gues
<pie_>
re: just remove trust on "hypothetical backdoor on commit x"
<pie_>
^or did i just make myself think you said something like that?
<pie_>
ok anyway i need to go do some things, so thats all the bikeshedding from me for now :p
<adisbladis>
My gut feeling is that retroactive revocation is not required and that it's something that can be added at a later point
<ekleog>
pie_: yeah, in my mind from the point step “enforce signing” is setup, it's just saying “from XXXX-XX-XX commit abcdef1234567890 onwards, all commits to master are signed” (or the variant “all signed commits to master take responsibility for the diff from previous signed commit, if we want to allow for compromise recovery without history rewriting -- should be debated, I guess)
<pie_>
so i guess to summarize, 1) i would /like/ the ability to have retroactive revocation (somehow) 2) if would be nice if any gap patching was not somehow just tacked on
<pie_>
anything security related should be an unavoidable part of the execution flow
<pie_>
i say execution flow instead of workflow because preferably most things can be kept out of the way
<adisbladis>
pie_: We could use keyservers for that part.
<ekleog>
yeah, gap patching (would it be from mistakes or from actual compromise) need to be taken care of before the RFC is pushed out IMO too :)
<adisbladis>
A keyserver revocation == retroactive revocation, removal from repo == trusted to that point
<ekleog>
I guess with appropriate tooling we can get mistakes out of the way, but actual compromise remains
<ekleog>
adisbladis: tbh, that still requires WoT & keyservers, if doing so then might as well do it all the way :)
<pie_>
hm, im not sure how hacky this is
<adisbladis>
ekleog: I'm thinking out loud :)
<pie_>
but "check revocations in head against any commit"?
<ekleog>
'k :)
* pie_
not thinking of the million ways this could go wrong)
<ekleog>
pie_: that can be done, but I still don't see with what attack model it helps :°
* pie_
is half a solution looking for a problem ;P
<ekleog>
heh ^^
<ekleog>
like, anyway just the signature on HEAD is enough to have trust, so disabling previous signatures will have little impact
<pie_>
well, thats without some gap patching technique
<pie_>
yeah idk
<ekleog>
something possible would be the “prevent checking out an unsigned commit”, but that's likely better taken care of with the same means as package compromises & vulnerabilities
<pie_>
the issue is i guess the question of history rewriting in any case
<pie_>
and the relation to tracking vulnerable commits and whatnot
<ekleog>
IMO, history rewriting before a signed commit is not reasonably possible… history rewriting after the last signed commit can potentially be thought of, if the tooling prevents fetching an unsigned ref
<ekleog>
for the “what if there's a compromise that's only discovered later”… well, it's a hard problem ^^ maybe retroactive revocation can help here better than the tracking vulnerable commits idea, but I don't really see how
<pie_>
ive been thinking for 2 minutes and i think regardless of anything else history rewriting is probably not a good idea
<pie_>
the question is how can we patch the trust chain
<pie_>
and replace a hypothetical bad commit
<pie_>
without actually rewriting history
<pie_>
i think that might be a contradiction :P
<ekleog>
yeah ^^
<ekleog>
solution: just break sha-1 \o/
<pie_>
lol
<pie_>
fighting fire with fire
<ekleog>
that wouldn't at all make things much worse :°
<adisbladis>
You are gonna have a fun time when git switches to sha256
<pie_>
ehehe
<pie_>
question?: why is history rewriting not a good idea? my reasons for such are generally just "tracking history"/semantics-like reasons
<ekleog>
more seriously, I think once a bad commit is in there, it can't really be removed, so we need tooling to prevent checking it out or similar
<pie_>
how does history rewriting work? branch off and basically reapply commits? (so a rebase i guess?
<ekleog>
the “all people who have fetched nixpkgs need to pull -f” reason is a problem
<ekleog>
yeah, rebase-like
<adisbladis>
Yes, and history rewriting also causes new trust issues
<pie_>
because i think for whatever reason, we should keep the semantic information in the old stuff around, but actually some sort of retroactive patch seems like the only real solution
<pie_>
hm youre right, one would need to resign the entire chain yes?
<adisbladis>
Yes.
<ekleog>
let's switch to pijul
<ekleog>
(/s)
<pie_>
what about one signature for the history state and one signature for patch contents
<pie_>
any history rewrite should be verified against the old version such that it contains no changes other than the trust related patch
<pie_>
i feel like that might not really be robust, but its an idea
<ekleog>
still makes… 3043 people (counting only forks, not even people who just locally cloned) pull -f :/
<pie_>
but i guess thats unavoidable?
<ekleog>
if we want to history-rewrite, then yes
<pie_>
i dont know what pull -f does but im assuming its bad because its inefficient
<adisbladis>
pie_: Pulls remote history regardless of local history
<adisbladis>
Basically push -f in reverse
<ekleog>
the alternative being to prevent using a bad commit through tooling
<pie_>
ekleog, but the commit would be bad regardless, so youd have to branch and rebase or something
<pie_>
for your own local stuff
<pie_>
(probably can be handled by tooling i guess)
<pie_>
oh shit
<adisbladis>
pie_: Why? What's wrong with a signed revert-commit?
<adisbladis>
Rewriting history is never acceptable
<ekleog>
^
<pie_>
i dont disagree :/
<ekleog>
(unless tooling prevents actually fetching said history because it's unsigned… but even then, it's most likely very borderline)
<pie_>
also history rewriting would mean hydra needs to rebuild a lot of history?
<pie_>
arguably BAD THINGS(TM) would happen very rarely regardless?
<adisbladis>
pie_: Hydra doesn't build at every commit
<pie_>
adisbladis, ok
<ekleog>
yeah, this kind of bad things should happen very rarely
<ekleog>
(I hope)
<ekleog>
like, ideally never
<pie_>
ekleog, so maybe a painful thing once a decade might not be horrible?
<pie_>
:P
<pie_>
what happens if a contributor doesnt pull -f
<ekleog>
that's actually the best argument in favor of history rewriting up to now ^^
<pie_>
nix is a thought leader anyway right? ;P
<adisbladis>
pie_: Git screams loudly about history not matching up
<ekleog>
they just can't pull in future updates
<ekleog>
now, I do think the “prevent checking out bad commits” (or prevent building things from bad commits, maybe) would actually be properly handled at the tooling level, avoiding the need for history rewriting
<ekleog>
(with “bad commits” including “commits with known CVEs”, so we'd need that tooling anyway)
<pie_>
sidenote: i wont add my concerns to the rfc since im not really using github (in the near future anyway) so if someone thinks my concerns may be warranted, feel free to add to rfc discussion
* ekleog
gotta go now, see you :)
<pie_>
ekleog, its work in any case but I like that we have the opportunity to maybe move things forward at least
<pie_>
see ya :P :D
<adisbladis>
We have _tons_ of commits in the past with known CVEs
<ekleog>
adisbladis: yeah, the point would be to somehow automatically mark as unsafe the appropriate packages from said commits :)
<pie_>
"tooling happens(TM)"
<pie_>
;D
<adisbladis>
That may be a different discussion than the signing one I think
<adisbladis>
Not a bad discussion to have but also not required for the matter at hand
<pie_>
yeah im just poking fun, but i meant it positively, if you make it they will come @ andi- 's tooling
<pie_>
unless you meant what ekleog said
<adisbladis>
It was @ ekleog
<pie_>
ah oops
* andi-
is a bit concerned about the lack of progress of his tooling that is being mentioned /o\
<pie_>
hehe
<andi->
next weekend!!!1 I fully booked it for working on it again.. First weekend in like a month or so that I can do stuff..
<adisbladis>
andi-: I know the feeling.. All work and no play
<pie_>
tfw play is also kind of work xD
<pie_>
sometimes I need a break from work any play
<adisbladis>
I'm quitting soon =) All play and no work
<pie_>
haha
<pie_>
andi-, have fun :P dont let the feature requests get you down
<andi->
pie_: I am pretty strict about features (and sid eproject right now).. I want to talk with people about my current vision of the tool at around NixCon so we can see what it solves / what goals I did miss etc.. :-)
<andi->
This weekend I am on the 4th weekend with a family celebration so lots of cake and thoughts and words but no code :/
<pie_>
my friends have this really shitty joke, "Do you have any programs for the weekend?" "No? Ok then I'll write you one."
<andi->
I am trying to figure out if and what has to be bumped in nixpkgs in response to https://webkitgtk.org/security/WSA-2018-0007.html. I'll see what breaks if I bump webkitgtk to 2.22.x instead of staying on the old (unmtaintined?) 2.20.x branch..
<pie_>
is it possible to run analyses on nix scripts? like find all things that refer to something, etc?
<pie_>
or rather, how analyzeable is nix code generally?
<andi->
I am not sure about the easiest way to find reverse dependencies but inspecting stuff is usually really nice in a nix repl
<lrvick>
adisbladis: gentoo got burned especially bad by their github account being taken over. It is better to learn these lessons from others rather than resting in survivors bias :)
<pie_>
has anyone started collecting a bibliography of this stuff? ;P
<lrvick>
I listed 6 incidents in my rfc
<lrvick>
including that one
<pie_>
cool, nice job
* pie_
has not actually read
<pie_>
ekleog, random principles: fail fast, fail safe, be recoverable
<pie_>
meh, i dont mean to preach to the choir, more like im still trying to figure out whether the way i think about things is good, and how to think about them at all
<ekleog>
pie_: agree with you on all three, fwiw :)
<ekleog>
(with “be recoverable” maybe being “have a plan for recovering in case things that can go wrong go wrong”, typically saying “ok there's been an incident, just consider the history is started only after it” would be a solution that's maybe not that bad)
<gchristensen>
we did learn lessons from Gentoo
<gchristensen>
(fwiw)
<gchristensen>
not just resting in survivorship bias
<adisbladis>
lrvick: I am trying to learn from their mistakes. I even talked to a gentoo-hardened dev about their key practices to see where their pain points and weaknesses are
<adisbladis>
lrvick: And I wasn't suggesting that we do the same, I was merely pointing out how other projects are doing things.
<adisbladis>
I think their approach is pretty terrible
<adisbladis>
There are very few distros that distribute build instructions as "packages"
<adisbladis>
Our signing needs are very different than most
<gchristensen>
for sure
<pie_>
'" just consider the history is started only after it” would be a solution that's maybe not that bad' i cant think of anything to say to that, it doesnt feel very good :c
<pie_>
i mean ideally we would like to work towards adding trust to the untrusted codebase as well no?
<pie_>
i.e. before the "signing starts from here" point
<gchristensen>
every signature implictly signs every commit before it
<pie_>
ok but still, does it make sense for the first signing commit to /really/ consider all the previous code as fully trusted? :P
<pie_>
the entirety of 2018 nixpkgs?
<pie_>
i mean, obviously it is
<gchristensen>
yes
<gchristensen>
because your signature is not on the patch or diff, but on the patch + its parent, meaning all parents
<pie_>
i know that *technically* it will be
<pie_>
all the old commits will only be overwritten by individual trusted commits once every line of every file has had some update
<andi->
I am not sure if trusted is the right wording there .
<pie_>
i mean maybe this is a point im being really pedantic on
<gchristensen>
you can't say all of history must be trusted, or it is impossible to recover from a problem
<pie_>
andi-, its not
<gchristensen>
,tofu
<{^_^}>
To get a sha256 hash of a new source, you can use the Trust On First Use model: use probably-wrong hash (for example: 0000000000000000000000000000000000000000000000000000) then replace it with the correct hash Nix expected.
<gchristensen>
oops, meant to do a PM -- sorry
<pie_>
noone's going to want to waste time rebuilding a second branch with signed commits up to the starting point, but without that a lot of code wont really have any integriy assurance...then again at this point that might not matter
<pie_>
sigh idk
<pie_>
what im saying wont matterif there is a point in time at which every line in every file has been touched by a signed commit :p
<pie_>
meh, so what security property is it that signing commits actually gets us again?
<pie_>
we know that a commit came from a given person (i mean a given key), is that it?
<gchristensen>
that is it
<adisbladis>
pie_: That a merge/commit was indeed conducted by someone trusted, not just someone with access to the github repo (ie github employee, mitm etc)
<pie_>
so without signing, unsigned parts of the code could have come from anywhere
<pie_>
except
<pie_>
from a given starting point, the head of the history structure would also be signed, so would give attribution up to the power of attacks on sha1
<pie_>
and htus integrity?
<pie_>
*and thus
<pie_>
eh. I need to think about this more, thanks for your patience.
<pie_>
still feel uncomfortable about the stuff before the initial signing point.
<adisbladis>
pie_: That stuff would be left as-is and no worse off than it is now.
<pie_>
well its not worse off, but it would be nice if it could be better off :P
<pie_>
also having better guarantees on some part of the codebase could leave false assumptions for the part where it does not apply
<adisbladis>
How can it be better off? Are you going to audit every single commit and sign?
<pie_>
adisbladis, ideally yes, in practice, probably not
<gchristensen>
you can't sign old commits
<adisbladis>
Btw, you'd have to use detached sigs since signing itself changes the sha
<pie_>
gchristensen, i know
<gchristensen>
but we could audit every line of code in existence with a known key
<pie_>
totally in actuality dumb idea: rebuild history up to the trust point in a separate branch, signing and reviewing as you go, once thats done, add some tooling that checks stuff before the trust point against the signed branch
<pie_>
gchristensen, or that (except you "only" need to audit "current" lines)
<gchristensen>
what is the threat model which makes non-current lines relevant
<pie_>
hm, well they arent i guess
<gchristensen>
what do you do if you find a commit introdced a security bug which is later fixed?
<pie_>
by current i mean you only need to look at code at the trust point
<pie_>
hm
<pie_>
you have a point about partially fixed commits
<pie_>
as in part of the commit was overwritten with a fix
<pie_>
I don't know.
<gchristensen>
the answer is signatures don't/can't mean its good
viaken2 is now known as viaken
r5d has joined #nixos-security
<andi->
At best origin can be stronger. E.g. it is the gpg key of xyz not just author & committer id. The more I think about it I question what issue we are solving right now...
<pie_>
probably need to go back and read the git signing article lol..
<lrvick>
Removed binary cache stuff and noted it for unresolved questions as that was the only comments