<davexunit>I was writing some personal packages for things that are still too experimental to go upstream. libtoxcore depends on libsodium, and then I saw on HN that libsodium just released 1.0.0... and the rest is git history.
<davexunit>now I can host my own custom package recipes on gitorious.
<mark_weaver>civodul: I think we need a way to deploy security updates to core packages without having to rebuild everything, at least in the short term. I have a couple of ideas that I think are workable.
<mark_weaver>the short-term idea is that we provide a way to specify that package C (a core package to which we will later need a security update) to be specified as an original package object to build, and a later package object that is later "swapped in" without recompiling the reverse-dependencies, as follows:
<mark_weaver>so when another package P depends on package C, the build process is as follows: first we create a derivation that builds P1 against C1 (the original version of C), and then another derivation is used to build P from P1 by simply replacing all occurrences of the C1 hash with the C2 hash.
<mark_weaver>so, this is still purely-functional. if you build P against C (where C is defined a C1 later patched to C2), then it will *always* build P first against C1 and later patch to work with C2.
<mark_weaver>the updated P would have an updated hash to reflect the fact that it has been updated, but it would be much much faster.
<mark_weaver>sorry, that could have been explained more clearly, but maybe you get the idea.
<civodul>mark_weaver: i think this is similar to the hash-rewriting thing mentioned in TODO
<civodul>probably a good idea to speed up deployment
<civodul>(but note that the problem today is the lack of a fix, rather than slowness to deploy it)
<mark_weaver>civodul: well, lack of a fix is part of the problem, but the other problem is that to change one line of code, we have to do the equivalent amount of work as all the mental work that has been done by humans in the last 10000 years.
<mark_weaver>(well, that's a total guess, but I think it's probably comparable :)
<civodul>but upgrading one's machine takes much fewer resources than rebuilding the complete distro
<civodul>but regardless, what you suggest would be a clear improvement
<mark_weaver>ideally, I'd like a system closer to the spirit of Emacs and Guile: after the pure build outputs have been produced, I'd like to be able (if I really want) to modify *any* line of code in the system and have that change take effect system-wide, efficiently on a modest system without using a build farm.
<civodul>well, that's pretty much what we get with "imperative" distros
<civodul>so it's a matter of allowing that style, while keeping closer control on side effects
<mark_weaver>right, I want to have my cake and eat it too. I want to be able to create _pure_ builds, but I also want to be able to efficiently make mutated variants of those pure builds when needed, for the short term (either for experimentation or security patches).
<mark_weaver>my YeeLoong is still running with the glibc CVE, because I've not yet finished a rebuild on it before the next CVE prompted me to abort and restart the build.
<DusXMT>Where can one buy a yeelong? I can't seem to find any offers on the internet
<mark_weaver>I really think that, going forward, it's going to be consideredd increasingly important to be able to apply security updates as quickly as possible. failure to do so effectively amounts to giving criminals such as the NSA access to our machines.
<mark_weaver>Danny Clark (former FSF sysadmin and founder of the now inactive "Freedom Included") also has several working Yeeloongs that he'd probably be happy to sell, and you'd be more likely to get one that actually works that way.
<Calinou>what's the point in Yeelong when there's X60
<mark_weaver>also, from a security perspective, I think there is a non-trivial advantage to running a minority architecture, since I guess there will be less effort put into developing exploits for it.
<mark_weaver>also, I take some comfort in the fact that the Loongson 2F processor in the YeeLoong does not have flashable microcode, so that's one less place where a back door could be planted. in fact, the early 2Fs had a bug that we've had to work around in our assemblers to avoid certain instructions.
<Calinou>if it's not updatable, why is the risk of backdoor lower?
<Calinou>not being flashable is to me a bad thing purely
<mark_weaver>I think flashable is good when I have access to the source code of the flashable code and the means to build it from source.
<mark_weaver>otherwise, it's just a black box, and all I can do is accept some blob from the company and install it, without having the slightest clue whether it's inserting a new back door, maybe because someone from the government demanded that they do it.
<mark_weaver>or because the key used to sign the updates has been compromised.
<mark_weaver>or for that matter, if someone breaks into my machine just once, they can flash this blob that I have no way to audit to achieve persistence.
<mark_weaver>well, I guess the persistence depends on it really being "flash", which is not always the case.
<mark_weaver>well, that's my current opinion anyway. feel free to disagree :)
<jxself>Hmm. Wasn't there some way to re-use a package definition in another? This seems a good idea for linux-libre-3.14 but I don't seem to see mention of it in the documentation, unless I am missing it.
<oiuoiu>I've recently git pulled and now trying to build hello, which fails while building guile
<oiuoiu>In the log, I see memoize.c:515:***Mismatching FUNC_NAME. Should be: `#define FUNC_NAME s_"@prompt"'
<oiuoiu>and .libs/libguile_2.0_la-posix.o: In function `scm_tmpnam': /tmp/nix-build-guile-2.0.11.drv-2/guile-2.0.11/libguile/posix.c:1488: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
<civodul>oiuoiu: "guix build --log-file guile" should give you the log's location
<civodul>but the above things are warnings, not errors
<oiuoiu>civodul: the build got killed after 3600 secs of silence
<mark_weaver>my idea is that we'd replace the binding for 'bash' with a special kind of 'hash-patched' package object that refers to both the original package and the updated package. and then every package that depends on 'bash' would automatically become 'hash-patched' as well, and this would propagate upward.
<civodul>actually, it may not be enough to look just at the inputs
<civodul>because some inputs may not be referred to in the build result
<civodul>or rather, looking at inputs may be too conservative
<mark_weaver>I may be using the wrong terminology, but by 'inputs' I meant the set of things that is made available in the chroot during the build process, and by 'transitive inputs' I mean the transitive closure of that.
<mark_weaver>so I didn't mean to exclude inputs whose hashes are not present in the outputs.
<mark_weaver>no problem, thanks for being receptive to my input :)
<mark_weaver>it would be interesting to see how often the grafted builds differ from the pure rebuilds.
<mark_weaver>my longer-term idea is to somehow track dependencies much more precisely. e.g. track which files are actually accessed in the inputs during a build, and eventually maybe even rig the compiler or linker to track which definitions are actually used, etc. but that's a much bigger job, and would also require changing some fundamental aspects of nix.