grarpamp, thanks for making me look at http://cryptome.org/2014/12/peck-roark-affidavit.pdf
I had dared to skip it, albeit it says a lot about the person I am holding an exchange with. On Sun, Dec 07, 2014 at 10:15:31AM -0800, coderman wrote: > On 12/7/14, carlo von lynX <[email protected]> wrote: > > I wasn't talking of (2) because that is a given which isn't questioned > > anywhere. I was only talking of (1). I don't know why you bring (2) into > > the discussion as if there was any problem with that. Unless you are > > using Microsoft Windows, there is not. > > see openwrt, for one common example. People who let openwrt update itself without cryptographic protection are irresponsible. > > Legitimately so, still the attacker has a much harder time. > > I don't understand why you reject plausible prioritization. > > By throwing all problems into one big basket you defocus. > > i am not rejecting prioritization, nor trying to defocus with a big > basket. what i am saying is that risk is a very context dependent, > multi-faceted thing. Which is a refined way of saying the same thing. > which is the bigger risk? binary packages or vulnerable applications? > it depends! > (and we should do better on both fronts :) Binary packages are the bigger risk. I have provided argumentation for that and you have not challenged that effectively. > > Yes, gentoo has been lax on that for many years. > > Now it supports gpg-signed portage updates, so that problem is fixed. > > not "fixed", but made more difficult. how well do all signers manage > their keys? would they know if a signing key was stolen? how would you > know? If I am correctly informed debian has two large attack vectors: Either you get friends with a package maintainer and get her to upload unsafe binaries (and the attacker can choose such maintainers based on evaluating all of her past email transactions etc - possibly even blackmail them with information which was supposed to be private), or they get access to the VPS machines doing the automatic compilation of the binaries the maintainers did not upload, which is probably not so hard and has the advantage that no-one within debian needs to be in the know. Ultimately, if the PGP private keys reside on those VPS servers, targeted attacks become feasible - right there in the process of a routine apt-get upgrade. Whereas with gentoo I would assume there is a limited number of persons that certify the daily generated portage images. Even if the attacker gets his hands on the private keys, he needs to falsify clear-text scripts or patches, thus material that can be easier detected and used as evidence against him compared to binaries, then choose between getting those evident changes distributed by the entire gentoo backend - maximizing the risk of getting caught - or targeting specific persons, which means making false versions of portage and knowing from which of hundreds of mirrors the targeted person will try to https-rsync it from. The attacker thus has to be close enough to the target to MITM all https-rsync operations, which depends on the system being dumb enough to not do certificate pinning. All in all the source distribution is a whole lot harder to attack than the binary distribution and can even be improved by providing system level certificate pinning like with libcertpatrol. Other option to improve the safety of the procedure would be if there was a mirror running on a .onion, .i2p or .gnu since those aren't as easily MITMable. > part of the benefit of reproducible builds is a consensus of digests > from multiple parties. this is different assurance than a signed > source package, which you build yourself. Yes, reproducible builds would be a step into the future. Right now source-code based systems are more secure, unless somebody in here can really challenge the argumentations I laid out. > > Every time a source code dares to contain a backdoor, there would > > be a responsible you can grill. And since gentoo doesn't maintain the > > source codes itself, a gentoo maintainer would have to hide it in the > > additional patch files. Good luck with that! > > you understand that the Debian openssl flaw was a patch against > upstream, rather than a rogue binary, right? I understand that sometimes such spectacular mistakes make it even on a source code level, whereas we won't even find out about unspectacular backdoors introduced on a mere binary code level. And that is the easier route to take. So there is no way to figure out how many "sleeper cells" are already in our linux DVDs. > who reads gentoo patch sets? I take random glimpses into patches and git pulls. If everyone does, there is no guarantee that the costly investment in introducing a source-code level vulnerability will pass undetected, whereas a binary vulnerability is close to a safe bet. Stays undetected until the day it is actually activated for something, and even then it takes very competent folks to observe its actions and figure out where things went wrong. > > So let's please prioritize the threats. Using somebody else's binary > > is a threat. Crosscompiling a linux from scratch for yourself is likely > > to be safe because the attack vector is just too much effort to prepare. > > i disagree that building from scratch is safe. it may be less risky > than binary packages in some situations, but that is the most you can > claim in broad strokes. Yeah yeah. Keeping people from working out priorities and making reasonable choices by throwing everything into a big basket of uncertainty. > > We got to have priorities. > > And we can use our brains to set them. > > priority #1: fix what is broken. > (unfortunately, it seems almost everything is broken :) Big basket logic. > what you don't mention here is IOMMU isolation between domains in a > Qubes OS system. your Gentoo hardened, running one vulnerable app, > leading to one vulnerable device, is a class break, as you could call > it. full compromise. Yes, I didn't mention that running a source-code based Qubes would be better than running a Gentoo. Do I also have to mention 2+2 = 4 or will you challenge me on anything I have not said? -- http://youbroketheinternet.org ircs://psyced.org/youbroketheinternet -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
