On Wed, Jun 16, 2010 at 6:35 PM, Dimitrios Apostolou <jimis@xxxxxxx> wrote: > On Wed, 16 Jun 2010, Dan McGee wrote: >> >> On Wed, Jun 16, 2010 at 6:08 PM, Dimitrios Apostolou <jimis@xxxxxxx> >> wrote: >>> >>> Hey, what do you think about this way of verifying packages? >>> >>> On Tue, 15 Jun 2010, Dimitrios Apostolou wrote: >>>> >>>> On another note, an easy but maybe a bit costly way to avoid any MITM >>>> tampering to packages, is serve *.md5 files for every package through a >>>> trusted HTTPS host. Then everyone can query that single host and check >>>> if >>>> the package he got from a mirror is safe. >>>> >>>> Costs: A little more traffic by serving hash files to everyone plus the >>>> cost of the certificate from a CA. Is the income Arch receives from ads >>>> and >>>> schwag enough for such a simple solution? >>> >>> Let me explain it a bit more: >>> >>> Pacman downloads package-1.tar.xz from a random mirror. >>> It then fetches: >>> >>> https://sums.archlinux.org/exactly/the/same/path/package-1.tar.xz.sha1 >>> >>> Pacman should then know whether the connection to sums.archlinux.org was >>> tampered, since the certificate is signed from a CA in ca-bundle.crt. So >>> if >>> the two hashes match, the package is safe (as safe as the archlinux >>> server...) >>> >>> That way any type of file can be verified (packages, db files, PKGBUILDs, >>> patches etc) provided that its cryptographic hash is in that HTTPS host. >>> Obviously to be able to verify db files, they need a timestamp appended >>> to >>> them, e.g. core-YYYYMMDDHHMM.tar.gz. That necessary change is perhaps the >>> most difficult part of this proposal. >>> >>> If too many small files is a problem, maybe the whole db.tar.gz can be >>> served (at the cost of a higher bandwidth utilisation). >>> >>> >>> This solution doesn't use package signing nor a web-of-trust. It simply >>> piggybacks on the tried and true HTTPS mechanism. Primary advantage is >>> the >>> lack of complexity which makes it easy to understand and implement. >>> >>> >>> What do you think? >> >> I think that someone could blow this apart. I break in, touch a >> package of my choosing without telling anyone, and update the checksum >> file. Bam- everyone's systems are fucked and the developers never knew >> because you didn't do anything both cryptographically secure and >> verifiable, you just added some indirection to the process. > > HTTPS is both cryptographically correct and verifiable. The case you mention > is if someone breaks the one end, that must be guarded most. The danger is > there everywhere, on the web-of-trust case someone that broke into a dev's > machine and got the key, can sign anything he wants and serve it to the > user, who would know? On the distro-wide key case, it's like someone > stealing that key, and be able to serve/sign everything. > > Here, we don't have a key to keep safe, but a server. So it needs special > attention about who has access and how hashes are submitted (although HTTPS > can secure this process too). But I admit that keeping a server safe is a > bit harder than keys, if that was your point. Yes, I probably should have clarified more. With individual package signing, if a developer's key is cracked, then *only* those packages have to be discarded, not our entire repository. With the above scheme, once you have had a break-in and are unable to know exactly what happened, the entire repository is suspect. Our verifiable server SSL cert means nothing if someone gains access to the machine. The whole idea of there being some universal but well-guarded key is a joke, in my opinion- I definitely do not think that is the right way to approach any signing outside of maybe at the DB level. At the package level, and the way we currently build things, I don't think that makes any sense. -Dan
