Re: APT vulnerability [DSA 4371-1]
FYI, I wrote a script to check the amd64 packages against the published hash, if anyone wants to use it, it is attached. .hc Evgeny Kapun: > On 22.01.2019 16:59, Vladislav Kurz wrote: >> Hello everybody, >> >> is this vulnerability affecting also apt-get ? > > Yes, the vulnerability is in http backend, which is used by apt-get. > >> If yes, will there be another DSA soon? > > No, because apt-get tool is in the package apt. > >> I'm also encountering many errors when using >> apt -o Acquire::http::AllowRedirect=false update >> apt -o Acquire::http::AllowRedirect=false upgrade >> >> As written in announcement: This is known to break some proxies when >> used against security.debian.org. >> >> However I do not use proxy at all. I have problems with jessie/updates, >> cdn.debian.net, and http.debian.net > > Try these URLs: http://cdn-fastly.deb.debian.org/debian, > http://cdn-fastly.deb.debian.org/debian-security. The domains > cdn.debian.net and http.debian.net are deprecated, use deb.debian.org > instead. > >> Err http://security.debian.org jessie/updates/main i386 Packages >> 302 Found [IP: 217.196.149.233 80] >> Err http://security.debian.org jessie/updates/contrib i386 Packages >> 302 Found [IP: 217.196.149.233 80] >> Err http://security.debian.org jessie/updates/non-free i386 Packages >> 302 Found [IP: 217.196.149.233 80] >> Fetched 151 kB in 9s (16.2 kB/s) >> >> Err:14 http://cdn.debian.net/debian stretch Release >> 302 Found [IP: 2001:4f8:1:c::15 80] >> Err:15 http://cdn.debian.net/debian stretch-updates Release >> 302 Found [IP: 2001:4f8:1:c::15 80] >> Err:16 http://cdn.debian.net/debian stretch-backports Release >> 302 Found [IP: 2001:4f8:1:c::15 80] >> >> Err:7 http://http.debian.net/debian stretch Release >> 302 Found [IP: 2001:67c:2564:a119::148:14 80] >> Err:8 http://http.debian.net/debian stretch-updates Release >> 302 Found [IP: 2001:67c:2564:a119::148:14 80] >> Err:9 http://http.debian.net/debian stretch-backports Release >> 302 Found [IP: 2001:67c:2564:a119::148:14 80] >> >> > check.sh Description: application/shellscript signature.asc Description: OpenPGP digital signature
Re: HTTPS enabled Debian Security repository
Ansgar Burchardt: > Henrique de Moraes Holschuh writes: >> On Fri, 27 Oct 2017, Hans-Christoph Steiner wrote: >>> This idea that GPG signatures on the index files is enough has been >>> totally disproven. There was a bug in apt where Debian devices could be >>> exploited by feeding them crafted InRelease files: >>> >>> https://www.debian.org/security/2016/dsa-3733 >> >> This was the *one* bug of this sort in the entire lifetime of apt thus >> far, AFAIK. > > No, there was also >https://security-tracker.debian.org/tracker/CVE-2013-1051 > which I found. That one was fairly easy to exploit (concatenate > manipulated Release with wrong "-BEGIN PGP SIGNATURE" markers and > correctly signed InRelease; gpg would verify the signature at the end, > but apt would use the unsigned, manipulated Release from the beginning) > > Similar bugs were present in several other places in Debian's > infrastructure as well. > > The one from 2016 is harder to exploit: I asked on #-apt back then and > the sample exploit had a 1/4 success change with a 1.3 GB InRelease file > on a memory starved i386 system). That hit rate is enough to build malware around... >>> If HTTPS was used, that would mean exploiting that would require >> >> One of the dozens of zero-days already found in the TLS stack we had to >> run like crazy to patch ? > > That is still valid of course, though I'm not sure if GnuPG or TLS > libraries get wider testing... > > Ansgar > Don't get me wrong, I agree that HTTPS is very overcomplicated and terrible in a lot of ways. But the days of plain HTTP/TCP are over. All connections need to be moving towards encryption. Even with HTTPS' faults, we are better off using it than plain HTTP. .hc
Re: HTTPS enabled Debian Security repository
Christoph Biedl: > 林博仁 wrote... > >> I believe that there's no benefit on accessing Debian archive with HTTPS as >> they uses GnuPG for authentication > > GnuPG indeed serves the purposes of authenticity and integrity very > well. Modulo bugs every now and then, but they happen on other layers as > well. > > Also, nobody should rely on the privacy in this case since the server > content is public and the clients have a fairly simple access pattern. > Decoding the transfers from this isn't trival but seems doable with some > effort - one day I'll write a prove of concept for this. > > There is however a reason for https, a sad one though: Braindead > "security" applicances that do deep packet inspection and might reject > the download of packages. > > Christoph > This idea that GPG signatures on the index files is enough has been totally disproven. There was a bug in apt where Debian devices could be exploited by feeding them crafted InRelease files: https://www.debian.org/security/2016/dsa-3733 If HTTPS was used, that would mean exploiting that would require compromising the mirror servers. With HTTP only, anyone that can see the network traffic can exploit the Debian box. Plus there are other things that using HTTPS improves: https://guardianproject.info/2014/10/16/reducing-metadata-leakage-from-software-updates/ HTTPS does not entirely solve all these problems, but it does drastically improve things. .hc
Re: embedding openssl source in sslcan
Seems like a decent idea for this, if other packages need an insecure openssl. As for making it hard to link to, the .so can be put into a non-standard dir so it has to be explicitly enabled both with a -lcrypto-insecure and -L/usr/lib/openssl-insecure. .hc Jonathan Yu: > Given that this would be useful for other tools, perhaps it's best to > create an "openssl-insecure" package which would ship a version of openssl > that has all the bells-and-whistles enabled (including the insecure ones). > We would have to take care that nothing is unintentionally linked to the > library. It would be a useful companion to software like testssl.sh (which > has similar requirements to sslscan) > > I certainly don't have strong feelings about this, especially given that I > haven't done any of the work... Just a thought :) > > On Fri, Dec 23, 2016 at 9:53 AM, Moritz Mühlenhoff wrote: > >> Sebastian Andrzej Siewior schrieb: >> >> Please use t...@security.debian.org if you want to reach the security >> team, not debian-security@ldo. >> >>> tl;dr: Has anyone a problem if sslscan embeds openssl 1.0.2 in its >>> source? >> >> That's for post-stretch, right? Right now it can simply link against >> the 1.0.2 copy, >> >> Seems fine to me for that use case, and it won't need any security >> updates to the embedded openssl copy for all practical purposes anyway. >> >> Cheers, >> Moritz >> >> > >
Re: HTTPS needs to be implemented for updating
Hans-Christoph Steiner: > > > Peter Lawler: >> >> >> On 18/12/16 22:03, Christoph Moench-Tegeder wrote: >>> second point requires a lot of work >>> to resolve. >>> >>> Regards, >>> Christoph >>> >> >> Monday morning yet-to-be-caffienated thoughts... >> >> I'm going to ignore the 'inconvenience' because I think in this case >> that's a specious argument. >> >> I acknowledge there's a bucketload of work to implement this. Just gets >> me to thinking, staging a switch over may be better. eg, a new apt >> config for https as either 'required' 'desired' and 'off'. This reduces >> the initial workload. Start with the default 'off', then at some future >> release move to 'desired' then 'required'. >> >> Further, I suggest perhaps an automated survey of the major mirrors to >> find which ones already support https may be in order. Perhaps the >> resultant data could be used by the apt-transport-https package for now, >> as well as deciding when the above mentioned switch over might occur. >> >> As I say, decaffienated Monday morning thoughts. >> > > Here's a script I wrote to do just that, find all Debian mirrors that > support HTTPS: > > https://gist.github.com/eighthave/7285154 > > .hc Also, it would be really awesome if there was: https://httpsredir.debian.org/debian Which automatically redirected to mirrors that support HTTPS. I filed an issue here: https://github.com/rgeissert/http-redirector/issues/78 .hc
Re: HTTPS needs to be implemented for updating
Peter Lawler: > > > On 18/12/16 22:03, Christoph Moench-Tegeder wrote: >> second point requires a lot of work >> to resolve. >> >> Regards, >> Christoph >> > > Monday morning yet-to-be-caffienated thoughts... > > I'm going to ignore the 'inconvenience' because I think in this case > that's a specious argument. > > I acknowledge there's a bucketload of work to implement this. Just gets > me to thinking, staging a switch over may be better. eg, a new apt > config for https as either 'required' 'desired' and 'off'. This reduces > the initial workload. Start with the default 'off', then at some future > release move to 'desired' then 'required'. > > Further, I suggest perhaps an automated survey of the major mirrors to > find which ones already support https may be in order. Perhaps the > resultant data could be used by the apt-transport-https package for now, > as well as deciding when the above mentioned switch over might occur. > > As I say, decaffienated Monday morning thoughts. > Here's a script I wrote to do just that, find all Debian mirrors that support HTTPS: https://gist.github.com/eighthave/7285154 .hc
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
Patrick Schleizer: > Julian Andres Klode: >> (2) look at the InRelease file and see if it contains crap >> after you updated (if it looks OK, it's secure - you need >> fairly long lines to be able to break this) > > Thank you for that hint, Julian! > > Can you please elaborate on this? (I am asking for Qubes and Whonix > (derivatives of Debian) build security purposes. [1]) > > Could you please provide information on how long safe / unsafe lines are > or how to detect them? > > Ideally could you please provide some sanity check command that could be > used to detect malicious InRelease files such as 'find /var/lib/apt > -name '*InRelease*' -size +2M' or so? > > The problem is, > > - debootstrap can only bootstrap from one source such as > 'http://ftp.de.debian.org/debian' - which still contains vulnerable apt. > (Correct me if I am wrong, I would hope to be wrong on that one.) > > - bootstrapping from 'http://security.debian.org' is not possible > [contains only security updates, not a complete repository]. > > - So in conclusion one has a chance to get compromised when > bootstrapping from 'http://ftp.de.debian.org/debian' and then apt-get > upgrading from 'http://security.debian.org'. > > Is there any way to break this cycle? > > Best regards, > Patrick > > [1] https://github.com/QubesOS/qubes-issues/issues/2520 > One thing that would help a lot with future issues like this is to use only encrypted connections in /etc/apt/sources.list. That can be either HTTPS or a Tor Hidden Service .onion address. For in depth discussion of this, see: * https://labs.riseup.net/code/issues/8143 * https://guardianproject.info/2016/07/31/howto-get-all-your-debian-packages-via-tor-onion-services/ * https://guardianproject.info/2014/10/16/reducing-metadata-leakage-from-software-updates/ For the official Debian Tor Hidden Service addresses including apt mirrors, see: https://onion.debian.org/ .hc
Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?
The Android SDK is really probably more like Eclipse. About 5 years of support, they are still maintaining Android 2.3.3 to some degree and that's at least 5 years old. https://android.stackexchange.com/a/84816 Also, the security profile is relatively low risk for the Android SDK in general: * mostly various user utilities * no setuid or special permissions * only one daemon-like thing, adb, with no net access by default * a good chunk is just files on the filesystem (e.g. libs for Android apps) .hc Hans-Christoph Steiner: > > BoringSSL is just a part of the Android SDK. It has an unstable API > because it is only the C backing to a single Java library called > conscrypt. That library is in turn only used as part of the Android > SDK. Using the upstream build system, all of the source code is checked > out at once from many git repos, and built together. Compare this to > Firefox, OpenJDK, gcc, or any large project: there are lots of chunks of > source code that are organized internally as "libraries". > > We are packaging these chunks separately because we believe it will make > it easier to maintain. Security updates can happen only in the > particular package rather than having to build the whole Android SDK > together as one giant source tree. > > Upstream is already good at providing security fixes for all of the > various bits, and they maintain quite a few stable releases in parallel. > Security maintenance for the Android SDK packages will mostly be a > matter of just including any new patch versions (i.e. 6.0.1_r14 vs > 6.0.1_r15). > > .hc > > Ralph Sanchez: >> My opinion might not mean much, but as a user, I agree with this. If >> i'm installing from the stable depository, we expect certain things >> from packages there and everything must be held to those guidelines. >> And mostly if we are using it from unstable, we are hoping to see it >> evolve into being put into the stable form, not just stagnate or we >> won't use it, which is bad for the both the user (losing out on >> promising programs) and the company (losing out on users), i think >> >> On Tue, May 17, 2016 at 11:27 AM, Michael Stone wrote: >>> On Tue, May 17, 2016 at 04:02:37PM +0800, seamli...@gmail.com wrote: >>>> >>>> BoringSSL is also free software, as long as there are maintainers who >>>> are willing to spend time on it, I think it has rights to exist in >>>> Debian. Well I have been contributing to Debian for not long, so >>>> please point me out my mistakes. :) >>> >>> >>> The question is, "who does the security updates for the package 5 years from >>> now". As a general rule, we don't allow private embedded copies of libraries >>> because then a security update for a library means chasing down and fixing >>> any number of copies. (In historic terms, this was a huge issue, for >>> example, with zlib bugs.) On top of that, if the upstream says flat-out that >>> it's an unstable API, putting it into a debian release seems like a bad >>> idea. Putting it unstable and never letting it make it to stable is a >>> possibility, but the point of unstable is to eventually get packages into a >>> released version so that seems somewhat an abuse of the system. If it's >>> really a standalone component that's expected to change a lot and not >>> interact with anything else in debian, then putting it in an external >>> repository seems like a better fit. >>> >>> Mike Stone >>> >> >
Re: Will Packaging BoringSSL Bring Any Trouble to the Security Team?
BoringSSL is just a part of the Android SDK. It has an unstable API because it is only the C backing to a single Java library called conscrypt. That library is in turn only used as part of the Android SDK. Using the upstream build system, all of the source code is checked out at once from many git repos, and built together. Compare this to Firefox, OpenJDK, gcc, or any large project: there are lots of chunks of source code that are organized internally as "libraries". We are packaging these chunks separately because we believe it will make it easier to maintain. Security updates can happen only in the particular package rather than having to build the whole Android SDK together as one giant source tree. Upstream is already good at providing security fixes for all of the various bits, and they maintain quite a few stable releases in parallel. Security maintenance for the Android SDK packages will mostly be a matter of just including any new patch versions (i.e. 6.0.1_r14 vs 6.0.1_r15). .hc Ralph Sanchez: > My opinion might not mean much, but as a user, I agree with this. If > i'm installing from the stable depository, we expect certain things > from packages there and everything must be held to those guidelines. > And mostly if we are using it from unstable, we are hoping to see it > evolve into being put into the stable form, not just stagnate or we > won't use it, which is bad for the both the user (losing out on > promising programs) and the company (losing out on users), i think > > On Tue, May 17, 2016 at 11:27 AM, Michael Stone wrote: >> On Tue, May 17, 2016 at 04:02:37PM +0800, seamli...@gmail.com wrote: >>> >>> BoringSSL is also free software, as long as there are maintainers who >>> are willing to spend time on it, I think it has rights to exist in >>> Debian. Well I have been contributing to Debian for not long, so >>> please point me out my mistakes. :) >> >> >> The question is, "who does the security updates for the package 5 years from >> now". As a general rule, we don't allow private embedded copies of libraries >> because then a security update for a library means chasing down and fixing >> any number of copies. (In historic terms, this was a huge issue, for >> example, with zlib bugs.) On top of that, if the upstream says flat-out that >> it's an unstable API, putting it into a debian release seems like a bad >> idea. Putting it unstable and never letting it make it to stable is a >> possibility, but the point of unstable is to eventually get packages into a >> released version so that seems somewhat an abuse of the system. If it's >> really a standalone component that's expected to change a lot and not >> interact with anything else in debian, then putting it in an external >> repository seems like a better fit. >> >> Mike Stone >> >
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
René Mayrhofer wrote: > On 2014-09-25 06:24, Hans-Christoph Steiner wrote: >> >> W. Martin Borgert wrote: >>> On 2014-09-24 23:05, Hans-Christoph Steiner wrote: >>>> * the signature files sign the package contents, not the hash of >>>> whole .deb file (i.e. control.tar.gz and data.tar.gz). >>> So preinst and friends would not be signed? Sounds dangerous to me. >> All package contents would be signed, except the signature itself. The >> signature would be a separate file in the ar archive of the .deb that signs >> control.tar.gz and data.tar.gz. See jar or apk format for an example of how >> this works. > I know I'm late to the discussion, but for the record, I fully agree > with this approach as the probably best compromise between usability > (don't underestimate that, see the emergence of the various "app shops" > for Linux applications), security, and flexibility. If anybody wants to > work on that, I'm happy to support it in the University Linz context > (i.e. as student work, thesis, etc.) and contribute to the process > (although, depressingly but realistically, not the implementation). > > Rene Since you mention Austria, I'll be based in Vienna from Oct 30th until March 3rd, perhaps we could even arrange a dev meeting/sprint on this topic in Linz or Vienna. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543fe36a.5070...@at.or.at
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
W. Martin Borgert wrote: > On 2014-09-24 23:05, Hans-Christoph Steiner wrote: >> * the signature files sign the package contents, not the hash of >> whole .deb file (i.e. control.tar.gz and data.tar.gz). > > So preinst and friends would not be signed? Sounds dangerous to me. All package contents would be signed, except the signature itself. The signature would be a separate file in the ar archive of the .deb that signs control.tar.gz and data.tar.gz. See jar or apk format for an example of how this works. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5423991b.5010...@at.or.at
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
Daniel Kahn Gillmor wrote: > Thanks for the discussion, Hans. > > On 09/19/2014 02:47 PM, Hans-Christoph Steiner wrote: >> Packages should not be accepted into any official repo, sid included, without >> some verification builds. A .deb should remain unchanged once it is accepted >> into any official repo (maybe experimental could be an exception, but not >> sid). I think that is essential. > > But some repositories could have different rules for package inclusion > than others, right? for example, say debian wanted to offer an > unstable-reproducible suite, which only permitted packages that had been > independently rebuilt reproducibly by multiple DDs and at least two > different buildds. Ideally, the packages that are shared between this > repository and other repositories would be identical. > > Note that if .deb files are internally signed, two developers *cannot* > create the same exact .deb if they do not share their secret keys. You're missing one key detail here, let's see if I can suss it out: * the builds are _exactly_ the same, except the signatures * the embedded signature does not sign the signature files (see jar and apk formats, which are almost the same, for examples) * anyone can just copy other dev's signature into the package and it will validate because the package contents are exactly the same * the signature files sign the package contents, not the hash of whole .deb file (i.e. control.tar.gz and data.tar.gz). Therefore two developers can easily create the same .deb if that have access to the signature file since they can just copy it. No need to run the signing process again. If people create their own .deb files in a reproducible process, then copy in the same signature files, then the hash of the .deb will be the same. >> I see no reason for changing the .deb between sid and testing, except for >> perhaps how existing implementations are doing it. It is usually worth the >> work to do things right way, rather than the easy way. > > I agree with this sentiment, i think we're trying to sort out what is > the "right way". > >> The build verification process needs to happen between the package upload and >> publishing to sid or security updates. Two builds is easy: the .deb that the >> uploader generates and the one the Debian process makes. That is probably >> enough. >> >> In Debian's case, it probably is too complicated to include multiple >> signatures. In that case, there should be only one canonical signature by >> dak >> once the build verification signature threshold has been passed. Then all of >> the other signatures could be added to .buildinfo or .changes or whatever >> other file. > > but the .buildinfo file is designed to say "i generated the .deb that > matches this digest exactly", which the corroborating builder cannot do, > because they cannot produce the internal signature. No need to produce the signature, just copy it! > Plus, we now have two different places to look for signatures. one > "canonical" one and then some external ones, and the signatures > themselves have different properties (one signs parts of the deb, the > other signs the whole .deb; one signs the build environment, the other > does not, etc) Definitely look at jar signing, it handles multiple signatures fine. I see no reason why you can't include an unlimited number of signatures in a .deb. Changing the number of signatures will change the hash of the .deb, that is why there needs to be a canonical set of signatures for each .deb. As for signing the hash of the entire .deb, that is what apt already gives us, that does not need to be reproduced in the dpkg-sig embedded signature. For people who want to verify the contents of a .deb with any kind of signature, then a tool will have to compare the hashes of control.tar.gz and data.tar.gz. >> Another option is to do it like f-droid.org does. F-droid.org generates a >> APK >> signing key for each app, then manages the signing on a specialized signing >> server. Or another option is just requiring all the signers to be from the >> debian-keyring, rather than an exact match for previous signers. > > Again, i think this is getting ahead of the discussion. i'm not > proposing that we try to set debian (or other derived distro) archive > policy here, i just think we want to think > >> In any case, the .deb needs to remain unchanged. > > right. but it can't be unchanged if the archive distributor decides > that a different signer is the "canonical" signer. So you're making the > contents of the .deb dependent on archive policy, rather than the other > way around. > > I
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
Daniel Kahn Gillmor wrote: > On 09/22/2014 04:06 PM, Hans-Christoph Steiner wrote: >> I think we're starting to nail down the moving parts here, so I want to >> outline that so we can find out the parts where we agree and where we >> disagree. >> >> * I hope we can all agree that the package itself should not change once it >> has hit the official repos. >> >> * I believe we can achieve what we want without taking a shortcut and >> introducing a new core package type (.sdeb .debs or whatever). We can figure >> out how to do this with the .deb file. Personally, I would accept a new >> package type after a thorough exploration of keeping .deb fails to deliver, >> but not before. >> >> * There should be at least one verification build before a package becomes >> official. >> >> * Then there needs to be a channel for people to submit the results of their >> own builds. That could be only positive results or only negative results, or >> both. >> >> * the .buildinfo file should contain all info needed to reproduce the build, >> given a standard Debian build environment > > Thanks, the above is a very useful summary. > >> Anything I left out? > > I think the summary above hints at but doesn't answer the question of > what an "official" package means, and the fact that there may be > multiple repositories (possibly operated by different organizations) > with different rules about what should make a package "official". > > I think we need to ask whether we care about byte-for-byte identical > .deb files *across* different repositories or not. > > If we don't care about cross-repo (or cross-organization) byte-for-byte > reproducibility, then an embedded signature in the .deb might be > acceptable (though the data it contains would be redundant to signatures > over the buildinfo files, which would eventually be necessary for > external policies or corroboration anyway). > > If we *do* decide that we care about cross-repo byte-for-byte > compatibility, then embedding a signature in the .deb suggests that one > repo can act as the gating factor for another, because repos > collaborating in this reproducibility push cannot both hold the key that > makes a .deb "official". > > I don't think that's a good tradeoff. As tempting as it might be to try > to cement debian's "authoritative" role via such a lock-in, i'd much > rather than debian derivatives, blends, side projects, etc, can all take > initiative that can then be absorbed back into debian cleanly and > reproducibly. > > i also suspect that the redundancy between internal signatures and > signed .buildinfo records is likely to cause some increase in confusion, > but i don't think that's as serious of a problem as the question of > which signing keys get to be "authoritative". > > --dkg Cross-repo byte-for-byte compatibility is a nice thing to strive for, but it sounds quite difficult to achieve and will require lots of social coordination as well as technical work. In terms of builds of a particular .deb by multiple distros, each distro will have to use the exact same toolchain to build the .deb for most packages. Different versions of gcc, javac, etc. will produce different binaries. You'll have the same problems as the canonical signature, like if two distros make a new package at the same time, but with different standards (gcc version, signer, etc). Ubuntu's gcc version will create a .deb with one hash, and Debian's gcc will create a .deb with a different hash, and each distro will mark theirs as canonical. That seems to be a much harder thing to manage across the distros. So if another distro or repo is going to buy into Debian's reproducible system, adding a bit about canonical signatures seems totally feasible to manage. The canonical signature would just need to be done by a key in the debian-keyring for Debian, ubuntu-keyring for Ubuntu, etc. While a static canonical signer is desirable, I don't think it can be supported without adding some restrictions (I think it would be worth it, for the record). Whoever is the first to publish a given package version claims the canonical role for both build setup and signature. To prevent accidental collisions, dput could check the various NEW queues, the various package repos, etc. to look for an existing canonical package. Then the first distro to publish is canonical. Shall we have a real time discussion on this topic? voice, video, or in person all work for me. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542386fd.9080...@guardianproject.info
Re: concrete steps for improving apt downloading security and privacy
Holger Levsen wrote: > Hi Hans, > > On Mittwoch, 16. Juli 2014, Hans-Christoph Steiner wrote: >> What I'm talking about already exists in Debian, but is rarely used. >> dpkg-sig creates a signature that is embedded in the .deb file. So that >> means no matter how the .deb file got onto a system, that signature can be >> verified. I'm proposing to start making dpkg-sig a standard part of >> official .deb files. This can be done in stages to make it manageable. >> Here's a rough idea of that: > > how about you file a bug against dpkg-sig and put your plan and justification > in there. Here on the mailinglist it will just be lost... Finally did this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762153 And someone else filed a bug to get apt-transport-https included in apt: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756535 .hc signature.asc Description: OpenPGP digital signature
Re: concrete steps for improving apt downloading security and privacy
On 07/17/2014 08:20 AM, Joel Rees wrote: > A little context? > > On Thu, Jul 17, 2014 at 1:26 AM, Hans-Christoph Steiner wrote: >> [...] >> * TAILS is a Debian-based live CD >> * the core system image by definition cannot be modified (live CD) >> * it has a feature for persistent storage of files on a USB thumb drive > > What happens when you put your live-image CD or USB in a box whose > boot ROM or BIOS ROM has been overwritten through some vulnerability > and now contains a hook to a backdoor? > > I'm not going to say that the whole idea of a live-image system is > full of holes, but I personally do not trust anything important to any > of the live images I use from time to time on hardware I don't > control, except for the live CDs I use for repairing systems that have > gone belly-up. > > I have, in the past, brought live USBs home from work and booted them > on my home hardware. I don't do that any more. (I'd have to mount the > USB on a running system at home and verify the parts of the file > system that shouldn't change.) _All_ software installed is vulnerable to this kind of exploit. Using a live CD does not address the issue of an untrusted BIOS any more than using a normal Debian install. The live CD does address lots of other issues that cannot be addressed easily in a normal Debian install. Same goes with offline vs online systems, both are entirely vulnerable to already exploited BIOSes. An offline machine reduces the risk since an exploited BIOS could only be installed by gaining physical access. >> * it also can save apt cache/lib to that persistent store >> * it will automatically install packages on boot from that store >> * mostly people use TAILS in online mode >> * there is a fully offline mode in development >> * offline TAILS cannot verify the packages if apt lists are > 2 weeks > > Yes it can. Not without modifying the apt config. The point here is to have a working system that is tested and audited, rather than just a set of instructions or recommendations. .hc >> * updating the apt cache/lib is painful on an offline machine > > Don't turn your nose up at wrappers. Lots of very useful stuff around > that is just wrapping something else. Quite stable, if the wrapper > does its job fully. > >> * an offline machine's threat model is drastically simpler > > I disagree with that, as you see. > >> On top of all that, each update increases risk of compromise on offline >> machines because each new update provides a vector to run a script or >> introduce new code that otherwise does not exist (no network!). > > I suggest looking at the reasons for that again. > >> And any >> decent attacker with physical access to the machine will always get in. > > Isn't this a red herring? > >> Other people want to be able to directly download .deb packages and have then >> verified as part of the install process. This is not my primary concern, but >> I do think it is a valid one. It would also be addressed by fully support of >> dpkg-sig. >> >> .hc >> > > I understand the hesitation. Having individual packages signed is a > good lead to a false sense of security. > > One point I strongly suggest considering is, for example, that > firefox, direct from mozilla.org, on stock debian, is more likely to > have vulnerabilities than firefox (iceweasel) loaded from the debian > packages archives. > -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c7ffee.6060...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On 07/16/2014 08:06 AM, Holger Levsen wrote: > Hi, > > On Mittwoch, 16. Juli 2014, Michael Stone wrote: >> Yes you are--what you described is exactly how the Release files work. > > Well, there are (many) other .debs on the net which are not part of our > releases, so it still seems to me that making .changes files accessable in > standardized ways could be very useful. What I'm talking about already exists in Debian, but is rarely used. dpkg-sig creates a signature that is embedded in the .deb file. So that means no matter how the .deb file got onto a system, that signature can be verified. I'm proposing to start making dpkg-sig a standard part of official .deb files. This can be done in stages to make it manageable. Here's a rough idea of that: 1. Adding a 'builder' signature should be easy to start with, make `debsign` also run `dpkg-sig --sign builder` on any .deb files it finds. I believe that `dpkg -i` will already try to verify a signature if it exists. 2. add something like `dpkg --require-debsig` to force checking of the dpkg-sig signature. This would be optional to start with, and complimentary to the already existing `dpkg --no-debsig`. 3. make `dpkg-buildpackage` call `dpkg-sig --sign builder --sign-changes full` to sign packages. 4. etc. As for Michael's complaint that I have not described a real problem, I have tried already in the thread, so I'll try again in bullet points: * TAILS is a Debian-based live CD * the core system image by definition cannot be modified (live CD) * it has a feature for persistent storage of files on a USB thumb drive * it also can save apt cache/lib to that persistent store * it will automatically install packages on boot from that store * mostly people use TAILS in online mode * there is a fully offline mode in development * offline TAILS cannot verify the packages if apt lists are > 2 weeks * updating the apt cache/lib is painful on an offline machine * an offline machine's threat model is drastically simpler On top of all that, each update increases risk of compromise on offline machines because each new update provides a vector to run a script or introduce new code that otherwise does not exist (no network!). And any decent attacker with physical access to the machine will always get in. Other people want to be able to directly download .deb packages and have then verified as part of the install process. This is not my primary concern, but I do think it is a valid one. It would also be addressed by fully support of dpkg-sig. .hc signature.asc Description: OpenPGP digital signature
Re: concrete steps for improving apt downloading security and privacy
On 07/15/2014 02:11 PM, Michael Stone wrote: > On Tue, Jul 15, 2014 at 01:28:08PM -0400, Hans-Christoph Steiner wrote: >> How do you propose managing a distro that mostly needs apt as is, but other >> times need "Acquire::Check-Valid-Until off;"? In other words, how would you >> manage a distro that sometimes uses apt as it was designed, and other times >> has to tweak in ways that would break the main use case? That sounds like a >> recipe for lots of edge cases and bad bugs. > > Um, so does your suggested change. Using apt with the valid check off is > fundamentally equivalent to using signed .debs. Both mechanisms have the same > failure modes, but one is a configuration change and one reworks the trust > path to get to the same place. >> is up-to-date, downloaded packages are intact, etc. Then the moment of >> install would use the signature in the .deb to verify that the .deb is intact >> and signed by a trusted key. Right now, `dpkg -i package.deb` does not >> verify >> against any signature. > > This is funcationally the same thing as checking that the hash of the deb is > the same as the one listed in the Releases file (or apt-cache show) before > installing the deb. You could do that in a wrapper. > >> So for the offline system, if the .deb files have signatures, the .deb files >> can be copied on the offline machine however (apt-offline is a good option, >> but others are possible), then they can be installed, uninstalled, etc. after >> verifying that the signature in the .deb is trusted. So really, this would >> not be modifying apt so much as modifying `dpkg -i`. > > Right, as I said, a complete reworking of the trust path (new code, new bugs, > etc.) to get essentially the same result. It sounds like what you need to do > to get the result you're talking about is grab the releases file along with > the deb, validate the sig on the releases file (except ignoring the > expiration), verify the hash of the .deb, then install the .deb. Depending on > the specifics of the implementation you could do that from an apt command line > by setting the Check-Valid-Until via -o > or by writing a dpkg wrapper. In any event it shouldn't be all that much code > and certainly much less what you're proposing. (I'd also hope that your front > end would at least tell the user how old the Release file is, and that the > distributor recommends checking for a newer version. The expiration mechanism > is important to ensure that people aren't installing old/vulnerable versions > of trusted packages--which may be equivalent to installing trojan packages.) > > Mike Stone There is already an existing format for signing and verifying .debs, the signing keys infrastructure is already in place, there is a clear spot to validate on install, doing some hacked together dpkg wrapper sounds like a good way to prototype, but a bad way to widely deploy a working system. I'm not saying that adding .deb signature validation to `dpkg -i` would be trivial and without risk. But the idea of validating signed package files on install is hardly revolutionary or even novel any more. Indeed it is pretty widespread: think Android, Fedora, Java, iOS, etc. I think it is the cleanest approach for the problem that I've outlined. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c58e06.3030...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On 07/14/2014 01:57 PM, Michael Stone wrote: > On Mon, Jul 14, 2014 at 01:22:10PM -0400, Hans-Christoph Steiner wrote: >>> Or, you could make use of the Check-Valid-Until and Min-ValidTime options in >>> apt.conf. There's a reason things are done the way they are, and you >>> probably >>> aren't going to find a lot of interest in getting people to do a lot of work >>> to create a system which is duplicative at best and less secure at worst. >> >> Sure, those options would work well for people who understand them and want >> to >> tweak them. I'm not interested in that. I'm currently working on a >> TAILS-based system for running build and signing processes on machines that >> _never_ go online. So that means that changing the apt config is not an >> option. I'm working with apt-offline currently and that helps a lot. > > You're making an assertion and not supporting it. Changing a configuration > parameter is unacceptable, but switching to an entirely different package > trust model is ok? You care very much about the trust path to debian packages > but not anything else (like the software that's installing them?) Seems like a > weird problem, but maybe you're just not fully explaining it. If that's really > the constraint set I guess it may be a case of "you created your problem, so > you get to fix it". > >> TAILS is a live CD, but provides a method of installing and maintaining new >> packages on top of what is provided by the live CD. That means those >> packages >> are stored in an encrypted stash, and are installed on each boot. So in >> order >> to use this feature, the apt cache needs to be refreshed using apt-offline at >> least every two weeks, otherwise the packages won't be installed since apt >> can >> no longer validate them. > > Have you actually tried setting "Acquire::Check-Valid-Until off;" in apt.conf? > What was the result? How do you propose managing a distro that mostly needs apt as is, but other times need "Acquire::Check-Valid-Until off;"? In other words, how would you manage a distro that sometimes uses apt as it was designed, and other times has to tweak in ways that would break the main use case? That sounds like a recipe for lots of edge cases and bad bugs. The situation in TAILS in not like normal Debian installed, but it basically the same for any live CD that has the option of installing additional packages from a persistent store. TAILS is mostly meant to be on online system, but fully offline support is in the works. Having signatures in .debs is entirely complementary to the existing apt system. It does not change how apt works at all in the normal network mode. The apt metadata would be used to verify that repo information is up-to-date, downloaded packages are intact, etc. Then the moment of install would use the signature in the .deb to verify that the .deb is intact and signed by a trusted key. Right now, `dpkg -i package.deb` does not verify against any signature. So for the offline system, if the .deb files have signatures, the .deb files can be copied on the offline machine however (apt-offline is a good option, but others are possible), then they can be installed, uninstalled, etc. after verifying that the signature in the .deb is trusted. So really, this would not be modifying apt so much as modifying `dpkg -i`. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c564a8.4000...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On 07/14/2014 01:12 PM, Michael Stone wrote: > On Mon, Jul 14, 2014 at 12:45:38PM -0400, Hans-Christoph Steiner wrote: >> One place that this will help a lot is managing completely offline machines, >> like machines for running secure build and signing processes. Right now, in >> order to install a package securely on an offline machine, I have to make >> sure >> that the apt-get cache is no older than two weeks, otherwise apt-get >> considers >> the info expired and no longer trusted. It make sense to have a listing of >> packages and updates expire. It does not make sense to have the signature on >> an individual package expire. Debian does not provide the later option. > > Or, you could make use of the Check-Valid-Until and Min-ValidTime options in > apt.conf. There's a reason things are done the way they are, and you probably > aren't going to find a lot of interest in getting people to do a lot of work > to create a system which is duplicative at best and less secure at worst. > > Mike Stone Sure, those options would work well for people who understand them and want to tweak them. I'm not interested in that. I'm currently working on a TAILS-based system for running build and signing processes on machines that _never_ go online. So that means that changing the apt config is not an option. I'm working with apt-offline currently and that helps a lot. TAILS is a live CD, but provides a method of installing and maintaining new packages on top of what is provided by the live CD. That means those packages are stored in an encrypted stash, and are installed on each boot. So in order to use this feature, the apt cache needs to be refreshed using apt-offline at least every two weeks, otherwise the packages won't be installed since apt can no longer validate them. Having a system that verifies existing .deb files against their own signature would eliminate this problem entirely. The apt expiration is only meant to protect against network attacks, so having to work around the expiration on a completely offline machine only complicates the process of running an offline machine, which also has security ramifications. For more info: https://dev.guardianproject.info/projects/psst/wiki/CleanRoom https://tails.boum.org/doc/first_steps/persistence/configure/index.en.html https://tails.boum.org/blueprint/remember_installed_packages/ https://labs.riseup.net/code/issues/7208 .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c411c2.4070...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On 07/14/2014 12:59 PM, Paul Wise wrote: > On Tue, Jul 15, 2014 at 12:45 AM, Hans-Christoph Steiner wrote: > >> I'd like to contribute to this effort > > First thing is to get #733029 fixed, which involves disabling signing > by default (signing should be done after testing not before) and > adding a signing tool to dpkg-dev. Then debsign/debuild need adapting > to the new default and the new signing tool. Then you can modify the > dpkg signing tool to sign .deb files using code from the old stuff and > convince the dpkg maintainers to accept it. Somewhere in there the old > approaches/code should be looked at, checked if they still work and > the old documentation and external websites (some of them only on > archive.org) and mailing list discussions. I agree that dpkg-buildpackage should not sign try to sign by default unless the signer in debian/changelog matches the currently logged in person. But there should always be at least "builder" signature on every .deb. That signature is not there to testify that it is a tested release, it is there to verify that the package was not modified since the builder created it. The Android security model is a good example: you cannot even install an .apk (like an Android .deb) that does not have a signature in it. All .apks must have a valid signature in order to be installed. For debug builds, the Android build tools make it dead simple to use a debug key to sign .apks. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c40fcc.7050...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On 07/14/2014 12:31 PM, Paul Wise wrote: > On Tue, Jul 15, 2014 at 12:24 AM, Hans-Christoph Steiner wrote: > >> I agree that .deb packages should be individually signed > ... >> This has been discussed in the past. I really think it is just a >> matter of someone doing the work. > > The work has been done many years ago and has been in the archive for > ages but has probably bitrotten since apt repo signing won (mostly, > some derivatives don't sign their repos) and now no-one uses deb > signing (probably). The packages are dpkg-sig debsigs debsig-verify. > Ah yes, I had forgotten about those. What I'd like to see is that stuff being integrated into the existing Debian packaging process, so that when you sign an upload, the .deb is automatically signed as well. One place that this will help a lot is managing completely offline machines, like machines for running secure build and signing processes. Right now, in order to install a package securely on an offline machine, I have to make sure that the apt-get cache is no older than two weeks, otherwise apt-get considers the info expired and no longer trusted. It make sense to have a listing of packages and updates expire. It does not make sense to have the signature on an individual package expire. Debian does not provide the later option. I'd like to contribute to this effort, so the first question are what are any issues that might block including this into normal package signing process when someone is uploading to Debian? That seems like the easiest and lowest risk place to start. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c40932.4070...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
I agree that .deb packages should be individually signed, but I don't think that the current apt system is vulnerable to package corruption. Having a signature in the .deb. would make things a lot more flexible in terms of distribution because a .deb could be verified no matter how it ends up on your system. That lets people experiment and create their own distribution systems, or use the tools that they already know when apt does not work for them (internet outages, blocks, etc). Having individually signed .deb packages would not change the existing workflow since uploaders already have to sign packages before uploading them to Debian. This has been discussed in the past. I really think it is just a matter of someone doing the work. .hc On 07/09/2014 08:29 PM, Kitty Cat wrote: > For years I have been concerned with MITM attacks on Debian mirrors. > > I think the only valid solution would be to individually sign EACH package > with a valid GPG > signature from a trusted source. > > I think EACH official package from Debian should be GPG signed by both > package maintainers and > also signed by official Debian release people. > > For example... What is secure about this download link? > > http://cdimage.debian.org/debian-cd/7.5.0/i386/iso-cd/debian-7.5.0-i386-netinst.iso > > Sure I can also download and check the signatures from here: > > http://cdimage.debian.org/debian-cd/7.5.0/i386/iso-cd/ > > However, what if http://cdimage.debian.org/ is actually an NSA mirror site > and not the real one? > > Lets say that I want download anything from http://cdimage.debian.org/ > <http://cdimage.debian.org/debian-cd/7.5.0/amd64/iso-cd/> > > My downloader resolves http://cdimage.debian.org/ > <http://cdimage.debian.org/debian-cd/7.5.0/amd64/iso-cd/> to NSA mirror > site through DNS cache poisoning > or some other means. So, whatever I am downloading is already compromised. > All signatures are valid > but are from the NSA. > > So there is no way for me to actually check that I have downloaded valid > files if everything that I see is > actually faked! > > If I go edit apt sources list and manage to get an actual real Debian > server update, then apt tells me that > all packages available to download are security compromised. > > Or lets say that I get a real install ISO disc and then later on my apt > mirror site is redirected to NSA mirror. > Apt will tell me that all packages available to download are security > compromised. > > One of the two scenarios above has actually happened to me!!! I don't know > if it is actually the NSA but it > DID happen to me. Aptitude was telling me that every single package > available for download was compromised! > > Think about this for a minute. If my ISP or upstream provider is secretly > cooperating with the NSA and the > NSA wants to compromise my machine, they can make it so that everything > that I download is through an > NSA source! > > *Remember, the NSA can create VALID SSL certificates for any website on the > fly.* > > Your web browser trusts many certificate authorities and which ones are > cooperating with the NSA? > > So how can we really be sure that our Debian install has not been > compromised from the beginning? > > > > > > > > On Thu, Jul 3, 2014 at 8:44 PM, Hans-Christoph Steiner > wrote: > >> >> After the latest revelation about NSA tracking all Tor downloads[1] (with >> source code!) and the whole "Debian mirrors and MITM" redux, I think we >> should >> start talking about concrete steps that we can take to improve the >> situation. >> >> The first things that came to mind would be quite easy to do: >> >> * include apt-transport-https by default in Debian >> * include existing HTTPS mirrors wherever Debian mirrors are listed >> * https://www.debian.org/mirror/list >> * netselect-apt >> * http://http.debian.net/ >> * apt-get's mirror:// >> * make http://cdn.debian.net/ have an only-HTTPS version >> * encourage mirror operators to set up a Tor Hidden Service >> >> There is already a good collection of HTTPS mirrors to choose from >> (not-counting all the ones that have HTTPS enabled without a proper >> certificate). >> >> https://mirror.i3d.net/pub/debian/ >> https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/ >> https://mirror.cse.unsw.edu.au/debian/ >> https://mirrors.kernel.org/debian/ >> https://the.earth.li/debian/ >> https://mirror.vorboss.net/debian/ >> https://ftp.arnes.si/pub/packages/debian/ >> https://ftp.iitm.ac.in/debian/ >> https://ftp.uni-erlangen.de/debian/ >
Re: concrete steps for improving apt downloading security and privacy
On 07/07/2014 06:43 PM, Jeremie Marguerie wrote: > On Mon, Jul 7, 2014 at 3:15 PM, Lou RUPPERT wrote: >>> If I'm looking at a catalog page from a shoe store on my table, >>> connected via the phone network, getting close to my 2G cap for my >>> wireless router for the month. My battery's getting low. Do I want >>> to waste bandwidth and CPU cycles for TLS encoding, just for >>> pictures of shoes? >> >> Let's try to turn our focus back to the question at hand, which is >> whether there are merits to promoting https mirrors for users who have >> concerns about being watchlisted based on their software choices. I >> think client cpu cycle and bandwidth concerns are a bit of an >> anachronism these days anyway. > > I think you pulled out the only reason why using https for mirrors > would be useful. > > The threat analysis doesn't show any practicable way for the any > attacker to prevent alter packages even with control of the network. > He could block updates but the client-side would noticed: out-of-date > repository and package list, failed to download specific packages. > > HTTPS is a solution to this risk scenario: > A) I don't want anyone to know which package I download (passive listening) > B) I don't want a third party to selectively prevent me from > downloading a package/update (active man i the middle) > > Scenario A is more likely to happen or to already be in place. > > HTTPS in this case is *not* about security but just privacy. > > 1) Performance concern: The CPU cycles for encrypting is now low > enough so that it seems feasible. Not all package providers need to > provide https-based repository but having a few of those and give them > visibility would be greatly appreciated. > > 2) TLS certificates: we do not need the package to be behind a > "debian" certificate, just to be behind a certificate trusted by a > recognized third party (same requirement as for websites). Since we do > not seek authentication of the package but just privacy, we only need > to ensure that we talk to the server we wanted to, whichever it is. I'm trying to practice what I preach here, so I set up my very first debian mirror. It is hosted on my home connection, so be gentle. It is only debian-security for amd64 and i386: deb http://dju2peblv7upfz3q.onion/debian-security/ wheezy/updates main This is a test repo, so be sure to keep a real debian-security mirror in your sources.list! Just put it after the above line, and apt-get will prefer the tor hidden service, but still get the latest updates available from debian-security. .hc signature.asc Description: OpenPGP digital signature
Re: concrete steps for improving apt downloading security and privacy
On 07/06/2014 10:31 PM, Lou RUPPERT wrote: > Joel Rees: >> On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT >> wrote: >> >> As someone pointed out, verifying the mirror we've connected to is >> not useful when we don't particularly have, or want, a way to >> prevent a spook-owned mirror from joining the pool. > > OK so supposing the NSA offers its own mirror. The package > installation process verifies PGP signatures. What is the actual > scenario you're trying to prevent? apt repositories are great because the users do not have to rely on the servers that host the repositories in order to know that they packages are authentic and unmodified. Tor provides the same resilience in terms of privacy. If apt-get is accessing the NSA mirror using Tor, then even the NSA will not be able to see the IP address of the computer that is downloading from that mirror. And as long as apt does not leak much metadata, it would be quite difficult for the NSA to de-anonymize that connection. .hc signature.asc Description: OpenPGP digital signature
Re: concrete steps for improving apt downloading security and privacy
On 07/06/2014 10:20 PM, Michael Stone wrote: > On Sat, Jul 05, 2014 at 08:54:55AM +0900, Joel Rees wrote: >> And you know, the funny thing is that MSIE took to "warning" people >> when there was a mix of encrypted and unencrypted data on a page. How >> long ago? Yeah, I know, it was so they could display that red herring >> of a lock for "secured pages". >> >> You don't need a warning when you are looking at un-encrypted data. >> You only need a warning if you are _sending_ un-encrypted data. > > This kind of threat analysis is why so many of us are still skeptical of the > need for HTTPS package mirrors. > > Mike Stone Do you have another idea for making it difficult for network observers to keep track of the software people are using? Do you think it does not matter that governments and companies are tracking the packages that people are downloading? .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53baecd7.3080...@at.or.at
Re: concrete steps for improving apt downloading security and privacy
On 07/04/2014 11:43 AM, Lou RUPPERT wrote: > Joel Rees: >> On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner >> wrote: >>> >>> [rhetoric encouraging the use of TLS transport for mirrors] [list >>> of current https mirrors] > >> Far be it from me to argue with ucalgary.ca, but one thing that >> bothers me about using TLS as a download transport is that, if I >> were the spooks, and I wanted a huge sample of crypts from a known >> plaintext, I could think of worse ways to go than to get the >> opensource crowd to provide them for me. > > Any popular site with relatively static content would do that. Apple > store or Play store would probably provide a more useful dataset for > them anyway. But if you configure it and the clients to favor > ephemeral keys you reduce the usefulness of captured traffic in being > able to simulate the server itself. > >> I mean, yeah, they probably have the resources to simulate the >> debian download infrastructure in their internal server farms, but >> why do their work for them and free their resources up for other >> jobs? > > I'm not sure that's a realistic scenario. > >> Especially when the only real advantage of using TLS download >> transport is (the illusion of) being able to download what you >> want without "them" knowing exactly what you downloaded. > > Yeah they could probably infer it based on the session size. They do > that for other encrypted streams, like determining successful SSH logins. > > But TLS also serves as a sort of sloppy authentication mechanism, > assuring you that someone someplace has vouched for the fact that > you've connected to the system you intended to connect to. It's not > terribly useful when you already sign your packages, but layers etc. I'm with Lou on this one, there are already much bigger and better data sets for that. According to this paper[1], Fedora 11+, Red Hat, SUSE, Google updates like Chrome and Android tools, Adobe AIR, Firefox, Python pypi, and others all use HTTPS for their updates. Debian is behind the curve here, HTTPS for updates is becoming the norm. Plus if the HTTPS it set up with "Forward Secrecy" ciphers, the keys are frequently rotated. And on the flipside of Joel's argument, right now, the NSA tries to store as much encrypted data as possible. That way when they get the key later, they can go back and decrypt old traffic. So generating more HTTPS traffic means they can't keep up as much. But this is probably not really important in this case since they would probably notice that the sites are mirrors and ignore the traffic. .hc [1] http://freehaven.net/~arma/tuf-ccs2010.pdf or https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf signature.asc Description: OpenPGP digital signature
concrete steps for improving apt downloading security and privacy
After the latest revelation about NSA tracking all Tor downloads[1] (with source code!) and the whole "Debian mirrors and MITM" redux, I think we should start talking about concrete steps that we can take to improve the situation. The first things that came to mind would be quite easy to do: * include apt-transport-https by default in Debian * include existing HTTPS mirrors wherever Debian mirrors are listed * https://www.debian.org/mirror/list * netselect-apt * http://http.debian.net/ * apt-get's mirror:// * make http://cdn.debian.net/ have an only-HTTPS version * encourage mirror operators to set up a Tor Hidden Service There is already a good collection of HTTPS mirrors to choose from (not-counting all the ones that have HTTPS enabled without a proper certificate). https://mirror.i3d.net/pub/debian/ https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/ https://mirror.cse.unsw.edu.au/debian/ https://mirrors.kernel.org/debian/ https://the.earth.li/debian/ https://mirror.vorboss.net/debian/ https://ftp.arnes.si/pub/packages/debian/ https://ftp.iitm.ac.in/debian/ https://ftp.uni-erlangen.de/debian/ https://ftp-stud.hs-esslingen.de/debian/ https://mirrors.ustc.edu.cn/debian/ https://mirror.cpsc.ucalgary.ca/mirror/debian.org/debian/ https://dennou-q.gfd-dennou.org/debian/ https://dennou-k.gfd-dennou.org/debian/ https://dennou-h.gfd-dennou.org/debian/ .hc [1] http://daserste.ndr.de/panorama/aktuell/nsa230_page-1.html -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b6150a.3000...@at.or.at
Re: Debian mirrors and MITM
On 07/03/2014 02:26 PM, Bernhard R. Link wrote: > * Hans-Christoph Steiner [140703 18:10]: >> You are correct that HTTPS would not entirely address #2, but it does >> improve the situation over HTTP. For example, an ISP, network operator, >> or government could block an entire mirror or all mirrors by redirecting >> requests to their own mirror which does not get updates. That would be >> transparent to the user. > > - An ISP could just offer to host a mirror, thus getting the certificates > for free. All you could avoid is getting in the way of someone willfully > wasting bandwith by using a specific far away mirror. > - A goverment could likely just do the same, but with any > certificates/private keys of any mirrors near you. Yes, there are definitely still possible attacks, even when using HTTPS+Tor onion address. I never said what I propose is perfect, just a large improvement. > - It is only "Transparent" in a very abstract sense of the word. People > know what security updates there are. Sending outdated stuff to many > people is hard to hide. So you need a targeted attack, which would > even cause more suspicion if someone realizes it. > If someone updates the packages manually detection chances are > astronomically high. If things are updated manually then a targeted > attack might as well block the traffic and also block the mails > going out about the automated update failing. In cases like the Great Firewall of China, they do country-wide things like this. They are quite good at blocking Tor all over China, for example. The vast majority of Debian/Ubuntu/etc. users only know there are updates because apt tells them so. > And then there is still the massive negative aspect of using https, > which any positive aspects have to trumph: If using https, people might > actually think they can just use a browser or the like to download > things and get a validated file. Which of course it is not, as so many > people can trivially inject something. An false feeling of having > security can be much worse than anything else often. > > Bernhard R. Link Yes, HTTPS should not be promoted as the thing that keeps the packages secure. That is the GPG signature. HTTPS mostly serves to obscure the traffic details from network observers. Many people think nothing of downloading and installing random software from an HTTP connection, so the bar is not currently very high. And there happens to be some concrete data on why this is important, it turns out that NSA/Five Eyes attempts to track everyone who lives outside the USA who searches for or downloads Tor: https://arstechnica.com/tech-policy/2014/07/report-rare-leaked-nsa-source-code-reveals-tor-servers-targeted/ .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b5b4f3.2030...@at.or.at
Re: Debian mirrors and MITM
On 07/03/2014 03:08 PM, Michael Stone wrote: > On Thu, Jul 03, 2014 at 12:46:45PM -0400, Hans-Christoph Steiner wrote: >> Google uses SPKI pinning heavily, for example, >> but they still use CA-signed certificates so their HTTPS works with Firefox, >> IE, Opera, etc. > > Yes, and MS does similar. The difference is, they own their infrastructure and > debian relies on donations. It's a lot harder for debian to control the > certificates on third party machines than it is for a big company to control > the certificates on its own machines. > > Mike Stone This is true. But Debian owns apt, and apt is the key piece of software that has to talk this encrypted protocol. It would be nice if it worked in the browser, but that is far from a requirement. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b5b070.1060...@at.or.at
Re: Debian mirrors and MITM
On 07/03/2014 12:58 PM, Reid Sutherland wrote: > > On Jul 3, 2014, at 12:46 PM, Hans-Christoph Steiner wrote: >> >> SSH uses entirely unsigned keys, and it has proven a lot more reliable than >> HTTPS/TLS. You use HTTPS/TLS keys the same way as SSH, but TLS requires >> signed keys, self-signed works. The signatures are only worth the trust path >> behind them, and CAs have not proven to be reliable trust paths. So if you >> can't rely on the signatures, why bother using them? This is not just my >> opinion, but of many others. Google uses SPKI pinning heavily, for example, >> but they still use CA-signed certificates so their HTTPS works with Firefox, >> IE, Opera, etc. >> > > SSH is hand verified when you connect initially (thus creating a “signature”). That is not a crypto signature like on a TLS certificate or OpenPGP key. But I guess you could call writing the public key to ~/.ssh/known_hosts a signature of sorts. > Are you are going to hand-verify each signature / key? And then against > what? Why not just verify the CD download once and be done with it? If you > are paranoid, build a trust relationship with a mirror that provides SSL and > save their cert. > > Anyway, I’m really over this. > > Have a good day. > I suggest you read the links that I included, they discuss these questions and more. Pinning means that the SPKI comes included in the software, like in the iso that you mention. In SSH speak, that would be like distributing an SSH known_hosts file along with the iso. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b58d10.1070...@at.or.at
Re: Debian mirrors and MITM
On 07/03/2014 12:38 PM, Reid Sutherland wrote: > On Jul 3, 2014, at 12:25 PM, Hans-Christoph Steiner wrote: >> As for how to manage making HTTPS by default, this does not require every >> mirror buying HTTPS certificates every year from Certificate Authorities. >> There are workable solutions based on self-signed certificates. >> >> In Android apps, there are two approaches that are gaining traction: >> including certificate pins based on the Subject Public Key Info (SPKI) in an >> apt in advance (https://www.imperialviolet.org/2011/05/04/pinning.html). >> And using "Trust On First Use/Persistence of Pseudonym" aka "Memorizing >> Trust Manager" (https://github.com/ge0rg/MemorizingTrustManager) to do >> ssh-style trust with a yes/no prompt the first time. These can also be >> optionally combined with the classic Certificate Authority, to provide a >> redundant check. >> >> We've been thinking about to make this workable, here are some notes: >> https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification >> >> Or there could be a password-based CA-replacement like http://tack.io > > > Self-signed? Really? > > This is full of issues. Just because someone spends time on an idea, doesn’t > mean it’s a good one. SSH uses entirely unsigned keys, and it has proven a lot more reliable than HTTPS/TLS. You use HTTPS/TLS keys the same way as SSH, but TLS requires signed keys, self-signed works. The signatures are only worth the trust path behind them, and CAs have not proven to be reliable trust paths. So if you can't rely on the signatures, why bother using them? This is not just my opinion, but of many others. Google uses SPKI pinning heavily, for example, but they still use CA-signed certificates so their HTTPS works with Firefox, IE, Opera, etc. > But this does trigger another idea; Debian could create their own CA for > managing the project’s SSL infrastructure. Then we would just need to trust > the Debian CA. That is also an option. That could also be done in parallel with what I proposed. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b588f5.7060...@at.or.at
Re: Debian mirrors and MITM
On Jul 3, 2014, at 12:10 PM, Hans-Christoph Steiner wrote: > > On Jul 3, 2014, at 11:52 AM, Michael Stone wrote: > >> On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote: >>> I definitely agree there are legitimate concerns that using HTTPS on apt >>> mirrors would help, and people who suggest otherwise are out of date on >>> what the threats are. I think the integrity of the package itself is not >>> reason enough to use HTTPS since the GPG signing is much more reliable for >>> that task. I break it down into 4 >>> >>> 1. package authenticity >>> (software can be modified while being downloaded) >>> >>> 2. repo availability >>> (internet services can be blocked by governments and companies) >>> >>> 3. package availability >>> (software security updates can be individually blocked) >>> >>> 4. who’s downloading what package (currently visible to anyone who can see >>> the network traffic, including open wifi, etc.) >>> >>> >>> The current apt model covers #1 well, but only covers #2 and #3 with a two >>> week window (the expiration date on the repo metadata). And it does not >>> cover #4 at all. >> >> HTTPS won't address #1 completely in the presence of mirrors, and debian >> doens't have the resources to serve all users without mirrors. It will not >> address #2. It may address #3, but less reliably than the current siutation. >> It may make #4 harder for certain scenarios, but not others (traffic >> analysis of specific host). >> >> Something like tor will be a better solution for #2, & #4 while the current >> system provides #1 & #3. (And also provides #2 for all practical purposes, >> given the length of the mirror list.) >> >> Mike Stone > > You are correct that HTTPS would not entirely address #2, but it does improve > the situation over HTTP. For example, an ISP, network operator, or > government could block an entire mirror or all mirrors by redirecting > requests to their own mirror which does not get updates. That would be > transparent to the user. This would make for a two week block on all updates > (until the repo data expires). Using Using HTTPS and/or Tor with an onion > address makes that a lot more difficult to do. Just connecting to an HTTP > mirror via Tor would not prevent this. > > But HTTP, HTTPS, and Tor are all in the same boat when all network traffic to > the mirrors are blocked. > > .hc As for how to manage making HTTPS by default, this does not require every mirror buying HTTPS certificates every year from Certificate Authorities. There are workable solutions based on self-signed certificates. In Android apps, there are two approaches that are gaining traction: including certificate pins based on the Subject Public Key Info (SPKI) in an apt in advance (https://www.imperialviolet.org/2011/05/04/pinning.html). And using "Trust On First Use/Persistence of Pseudonym" aka "Memorizing Trust Manager" (https://github.com/ge0rg/MemorizingTrustManager) to do ssh-style trust with a yes/no prompt the first time. These can also be optionally combined with the classic Certificate Authority, to provide a redundant check. We've been thinking about to make this workable, here are some notes: https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification Or there could be a password-based CA-replacement like http://tack.io .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cd4e3945-532a-4dad-9cfa-4742dfdcf...@at.or.at
Re: Debian mirrors and MITM
On Jul 3, 2014, at 11:52 AM, Michael Stone wrote: > On Thu, Jul 03, 2014 at 11:05:17AM -0400, Hans-Christoph Steiner wrote: >> I definitely agree there are legitimate concerns that using HTTPS on apt >> mirrors would help, and people who suggest otherwise are out of date on what >> the threats are. I think the integrity of the package itself is not reason >> enough to use HTTPS since the GPG signing is much more reliable for that >> task. I break it down into 4 >> >> 1. package authenticity >> (software can be modified while being downloaded) >> >> 2. repo availability >> (internet services can be blocked by governments and companies) >> >> 3. package availability >> (software security updates can be individually blocked) >> >> 4. who’s downloading what package (currently visible to anyone who can see >> the network traffic, including open wifi, etc.) >> >> >> The current apt model covers #1 well, but only covers #2 and #3 with a two >> week window (the expiration date on the repo metadata). And it does not >> cover #4 at all. > > HTTPS won't address #1 completely in the presence of mirrors, and debian > doens't have the resources to serve all users without mirrors. It will not > address #2. It may address #3, but less reliably than the current siutation. > It may make #4 harder for certain scenarios, but not others (traffic analysis > of specific host). > > Something like tor will be a better solution for #2, & #4 while the current > system provides #1 & #3. (And also provides #2 for all practical purposes, > given the length of the mirror list.) > > Mike Stone You are correct that HTTPS would not entirely address #2, but it does improve the situation over HTTP. For example, an ISP, network operator, or government could block an entire mirror or all mirrors by redirecting requests to their own mirror which does not get updates. That would be transparent to the user. This would make for a two week block on all updates (until the repo data expires). Using Using HTTPS and/or Tor with an onion address makes that a lot more difficult to do. Just connecting to an HTTP mirror via Tor would not prevent this. But HTTP, HTTPS, and Tor are all in the same boat when all network traffic to the mirrors are blocked. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f3c70ec9-e2e9-48ca-87d9-7ce3f8296...@at.or.at
Re: Debian mirrors and MITM
On Jul 3, 2014, at 11:55 AM, Reid Sutherland wrote: > On Jul 3, 2014, at 11:09 AM, Hans-Christoph Steiner wrote: > >> >> On Jun 2, 2014, at 9:29 AM, Jann Horn wrote: >> >>> On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote: >>>> Now I don't want to call into question the esteemed authors of said >>>> program, and depending libraries, but I do think that providing https >>>> mirrors gives us two distinct advantages over plain http: >>>> >>>> . in the case that there is a bug in apt, or gpg, or something >>>> else, having https would provide at minimum a minor set of >>>> defense against bulk, non-targeted quantum insert and foxacid >>>> attacks, not to mention MiTM compromises from a hostile local >>>> network >>> >>> Heh. Because SSL/TLS libraries are so impenetrable and secure? :D >> >> Even GnuPG has had exploitable bugs. Adding layers of different security >> techniques can help make the apt distribution system less fragile when such >> bugs inevitably arise. >> > > > Adding another layer of code does not always improve security. Using the > argument of bugs, what happens when your vulnerable SSL clients connects to a > malicious mirror? > > You suggest that GnuPG could have security flaws, but you promote software > line that has already demonstrated numerous security problems. > > On a side, SSL is already available in apt, anyone is free to implement SSL > on their mirror server and use it in their apt client. If you need to secure > the initial installation download use the verification information found here > <https://www.debian.org/CD/verify>. The point is to figure out a better way that is included by default. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/995ae110-08f9-47ff-9072-ade90c0bd...@at.or.at
Re: Debian mirrors and MITM
On Jul 3, 2014, at 11:05 AM, Hans-Christoph Steiner wrote: > > On May 30, 2014, at 10:06 AM, micah anderson wrote: > >> Kurt Roeckx writes: >> >>> On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote: >>>> On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote: >>>>> On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: >>>>>> The public Debian mirrors seem like an obvious target for governments to >>>>>> MITM. I know that the MD5s are also published, but unless you're >>>>>> verifying them with third parties, what's stopping the MD5s being >>>>>> compromised too? >>>>> >>>>> The cryptographic signatures that are validated automatically by apt. >>>> >>>> What's stopping the attacker from serving a compromised apt? >>> >>> apt will check that the new apt is properly signed. >> >> This entire secure artifice depends entirely on the integrity of >> apt, and presumably the various libraries that it depends on. >> >> Now I don't want to call into question the esteemed authors of said >> program, and depending libraries, but I do think that providing https >> mirrors gives us two distinct advantages over plain http: >> >> . in the case that there is a bug in apt, or gpg, or something >> else, having https would provide at minimum a minor set of >> defense against bulk, non-targeted quantum insert and foxacid >> attacks, not to mention MiTM compromises from a hostile local >> network >> >> . keeps an adversary who may be listening on the wire from >> looking at what you are installing. who cares what you are >> installing? well it turns out that is very interesting >> information. If you can see that I've just installed X package, >> and you then just look over at our security tracker and find >> that this package has an exploit... >> >> micah > > I definitely agree there are legitimate concerns that using HTTPS on apt > mirrors would help, and people who suggest otherwise are out of date on what > the threats are. I think the integrity of the package itself is not reason > enough to use HTTPS since the GPG signing is much more reliable for that > task. I break it down into 4 > > 1. package authenticity > (software can be modified while being downloaded) > > 2. repo availability > (internet services can be blocked by governments and companies) > > 3. package availability > (software security updates can be individually blocked) > > 4. who’s downloading what package (currently visible to anyone who can see > the network traffic, including open wifi, etc.) > > > The current apt model covers #1 well, but only covers #2 and #3 with a two > week window (the expiration date on the repo metadata). And it does not > cover #4 at all. > > Using HTTPS for apt repos is a simple way to improve the security of all 4. > It adds a weak backup security layer for #1, it makes it much more difficult > for the attacker to do #2, #3, and #4. > > For those who want to find HTTPS mirrors, try my script here: > https://guardianproject.info/2013/10/31/issues-when-distributing-software/ > > .hc I should add: apt-transport-tor is a great project to improve this situation as well that is probably more secure than HTTPS, but at a cost of probably much slower download speeds. Using an apt mirror with an onion address would entirely supplant HTTPS. So don't get me wrong, I don't think HTTPS is a great system, what I'm saying is that the current state of apt mirrors (HTTP and GPG signing) is not enough. HTTPS can help, especially when used with some kind of certificate/SPKI pinning. Tor can help too, especially when used with onion addresses. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/578d5f80-c054-4d04-b1cd-39cebef3a...@at.or.at
Re: Debian mirrors and MITM
On Jun 2, 2014, at 9:29 AM, Jann Horn wrote: > On Fri, May 30, 2014 at 10:06:06AM -0400, micah anderson wrote: >> Now I don't want to call into question the esteemed authors of said >> program, and depending libraries, but I do think that providing https >> mirrors gives us two distinct advantages over plain http: >> >>. in the case that there is a bug in apt, or gpg, or something >>else, having https would provide at minimum a minor set of >>defense against bulk, non-targeted quantum insert and foxacid >>attacks, not to mention MiTM compromises from a hostile local >>network > > Heh. Because SSL/TLS libraries are so impenetrable and secure? :D Even GnuPG has had exploitable bugs. Adding layers of different security techniques can help make the apt distribution system less fragile when such bugs inevitably arise. For example, if there was an exploitable bug in the GPG signing or checksum hash algorithms used by apt, anyone fetching packages over HTTP could have malicious versions inserted by systems like FOXACID. If HTTPS was in use, then that would required the attacker to modify the files on the servers where they are stored in order to use the initial GPG/hash exploit. So using HTTPS greatly reduces the attack surface. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/13319bed-07af-4cab-9969-8f8d663bc...@at.or.at
Re: Debian mirrors and MITM
On May 30, 2014, at 10:06 AM, micah anderson wrote: > Kurt Roeckx writes: > >> On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote: >>> On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote: On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: > The public Debian mirrors seem like an obvious target for governments to > MITM. I know that the MD5s are also published, but unless you're > verifying them with third parties, what's stopping the MD5s being > compromised too? The cryptographic signatures that are validated automatically by apt. >>> >>> What's stopping the attacker from serving a compromised apt? >> >> apt will check that the new apt is properly signed. > > This entire secure artifice depends entirely on the integrity of > apt, and presumably the various libraries that it depends on. > > Now I don't want to call into question the esteemed authors of said > program, and depending libraries, but I do think that providing https > mirrors gives us two distinct advantages over plain http: > >. in the case that there is a bug in apt, or gpg, or something >else, having https would provide at minimum a minor set of >defense against bulk, non-targeted quantum insert and foxacid >attacks, not to mention MiTM compromises from a hostile local >network > >. keeps an adversary who may be listening on the wire from >looking at what you are installing. who cares what you are >installing? well it turns out that is very interesting >information. If you can see that I've just installed X package, >and you then just look over at our security tracker and find >that this package has an exploit... > > micah I definitely agree there are legitimate concerns that using HTTPS on apt mirrors would help, and people who suggest otherwise are out of date on what the threats are. I think the integrity of the package itself is not reason enough to use HTTPS since the GPG signing is much more reliable for that task. I break it down into 4 1. package authenticity (software can be modified while being downloaded) 2. repo availability (internet services can be blocked by governments and companies) 3. package availability (software security updates can be individually blocked) 4. who’s downloading what package (currently visible to anyone who can see the network traffic, including open wifi, etc.) The current apt model covers #1 well, but only covers #2 and #3 with a two week window (the expiration date on the repo metadata). And it does not cover #4 at all. Using HTTPS for apt repos is a simple way to improve the security of all 4. It adds a weak backup security layer for #1, it makes it much more difficult for the attacker to do #2, #3, and #4. For those who want to find HTTPS mirrors, try my script here: https://guardianproject.info/2013/10/31/issues-when-distributing-software/ .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/476000fe-7a7d-4dab-b344-a928ef9e3...@at.or.at
Re: PPA security (was: Debian mirrors and MITM)
On May 30, 2014, at 2:41 PM, W. Martin Borgert wrote: > Quoting Jeremie Marguerie : >> Thanks for bringing that issue! I feel the same way when I install a >> packet from a non-official PPA. > > Unfortunately, every package can do anything: pre-inst, post-inst, > pre-rm, post-rm run as root. If you don't trust a PPA the same way > you trust your OS vendor (Debian, Ubuntu or whoever), install only > in a VM or a container (not sure, whether a docker container is > considered safe enough, but chroot is not sufficient). > > Alternatively, download the package, unpack it, remove maintainer > script or check them carefully, check for s-bits on binaries etc. > repack it and install. I'm probably missing more checks here. > > While it would be nice to have sth. like "less trusted sources" and > allow their packages only certain kinds of install/de-install > operations (i.e. no maintainer scripts) etc., it's hard to get > right and a broken solution would put users at risk. This could be approached another way. There could be scripts in the packaging tools that mark a package if it does not run anything in any of the scripts that does not come from the packaging tools. I think many many packages would qualify here, most packages do not touch the pre/post scripts, so the ones that are included are generated by debhelper or whatever. Then you could see whether a package is requesting to run its own scripts as root, and make the call there. A package that does not add anything to those scripts would be pretty safe to install, at least. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9145da3f-12d4-42fc-80a3-2b918e510...@at.or.at
Re: NSA software in Debian
On 01/26/2014 01:30 PM, Andrew McGlashan wrote: > On 25/01/2014 7:39 PM, Emmanuel Thierry wrote: >> Then DNSSEC appeared ! :) > > I wish it was that simple I don't believe it is today, but one day > it will have to be the standard. > >> I remind you it is really difficult to compromise DNS zones protected by >> DNSSEC, even if you have control on root DNS servers (they probably have it) >> and the knowledge of the complete root DNS key (they likely don't have it). >> >> There is no point in considering DNS as compromised, since it would be much >> easier (and as difficult to hide) to subvert IP routing. By the way if you >> succeeded in redirecting DNS traffic to your box, you probably have the >> power of redirecting all the traffic to your box. > > It is technically very easy to compromise DNS for many people. It often > surprises me that people don't question absolutely whether or not a > webpage is legitimate, they almost always take it on faith unless there > is something very obviously wrong and even then the person will take > some convincing (especially the lesser educated on these matters). > > Kind Regards > AndrewM I think the MITM attacks that the NSA does on the core internet routers are likely based on IP rather than DNS. The reports talk about the system is setup to respond before any of the real servers can. So my guess is that they are replying to ARPs, thereby claiming an IP. Just a guess... .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e82a63.4010...@at.or.at
Re: NSA software in Debian
On 01/20/2014 12:22 PM, Octavio Alvarez wrote: > On 01/20/2014 05:29 AM, Marco Saller wrote: >> I have read that the NSA proposed to include SELinux in linux 2.5. (Linux >> Kernel Summit 2001) >> Don't you think that may be one of their fancy tricks to gain access to >> computers running linux? Some news websites also mention vulnerabilities >> similar to this one. >> It would be a great idea to include malicious software to kernel modules. > > It is easy to come up with that idea, and it's easy to fear to it. It's > easy to write about it and to popularize it and cause mass-delusion. > It's difficult to prove, though. > > If you consider that SELinux code available and with so many auditing > humans and tools it's not as easy as it sounds. It can happen, but it's > not as easy as "they can, therefore they are". > > As others have said, the NSA doesn't need specific backdoors. There are > many vulnerabilities in all software already available which are already > being exploited. > > The more general problem is that not all programmers like or know > formality and that not all developers like strict code and algorithm > correctness. *That* is something to worry about. > > I wouldn't worry about SELinux specifically. There are also so many vulnerabilities below the layer that Debian occupies. There can be malware in BIOS and firmware blobs, there can even be malware built into the hardware, or added later in between when it has been shipped from the manufacturer and before it arrives at your house. The NSA hardly has exclusive domain over this stuff. UK, Canada, Australia, Russia, China, Iran, and many other countries have very capable intelligence services that are also working on such exploits. Then there are all the freelancers who just sell exploits to the highest bidder. I think the only way forward is to keep focusing on making progress and avoid getting bogged down in the paranoia. Deterministic Reproducible Builds is a good example of making key progress: https://wiki.debian.org/ReproducibleBuilds .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52ddf886.1050...@at.or.at
Re: SSL for debian.org/security?
On 11/12/2013 01:58 PM, Henrik Ahlgren wrote: > On Tue, Nov 12, 2013 at 01:15:38PM -0500, Hans-Christoph Steiner wrote: >> Having the key generated on the card is the most secure, since those cards >> are >> designed so you can't read the secret key off of the card. So the cost of >> putting a new certificate on the card is only someone's time for generating >> and uploading and new key to it. > > But there is the significant downside that it is not possible to > backup the key, so if the card gets destroyed in a fire or just fails > and stops working, the key needs to be revoked, since only one > physical copy of the private key exists. (Which also means that only > one machine can sign with the key.) > > So for widely used keys it might be better to create the keypair in a > trusted (airgapped from any network and diskless) machine running > something like Debian Live or Tails, and in addition to uploading it > to the smart card, make few backup copies to offline media (e.g. USB > sticks) to be stored in a safe location. That is also a good point. The process needs to be designed to work in each situation. Having a single copy of a private key is not always a disadvantage, but it can provide some interesting, unique advantages. If you look at the example of Lavabit, he was ordered by the government to turn over a copy of his secret key. If that key was generated on a smartcard, then it would not be possible for him to give a copy of the key to someone else. Having a key that is only on a single smartcard would make that key impervious to secret orders. Sure, a government could take that key by secret order, but then the debian server would have to use a new one, so the action would not be a secret. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52827f67.9070...@at.or.at
Re: SSL for debian.org/security?
The whole card setup would be less that 50 Euros, that does not seem at all like a "significant amount of money". You can get a card for 14€ and a USB reader for 18€ http://www.g10code.com/p-card.html The cards have two modes with which they work with keys: * generate the key on the card, export the public key * import a secret key generated elsewhere Having the key generated on the card is the most secure, since those cards are designed so you can't read the secret key off of the card. So the cost of putting a new certificate on the card is only someone's time for generating and uploading and new key to it. .hc On 11/12/2013 04:34 AM, Pedro Worcel wrote: > Also, what is to prevent someone interfering with the creation of the > certificate that will be embedded in the device (or poor pseudo-random > while generating it, etc.), and what would be the cost of replacing the > certificate inside the device once/if compromised? > > > 2013/11/12 Andreas Kuckartz > >> Hans-Christoph Steiner: >>> The crypto smartcard (aka Hardware Security Module) are some work to >> setup, >>> but not really all that much. And they are easy to use once setup. And >> they >>> provide a huge boost in the security of the certificate. >> >> Such hardware also costs a significant amount of money. Are there better >> ways to spend money to improve the security ? >> >> Cheers, >> Andreas >> >> >> -- >> To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact >> listmas...@lists.debian.org >> Archive: http://lists.debian.org/5281c93a.8040...@ping.de >> >> > > signature.asc Description: OpenPGP digital signature
Re: SSL for debian.org/security?
On 11/11/2013 07:41 PM, Jérémie Marguerie wrote: > On Mon, Nov 11, 2013 at 2:48 PM, Mike Mestnik wrote: >> I don't see how this is relevant? Obviously if hardware is seized then the >> owners no longer have control. If you have suggestions as to how to secure >> hardware that's great, but if you just want to point out that "Nothing can >> be done." That's not helpful. > > I think Jacob suggests to get a encryption hardware module that does > not disclose the key. > > Let's get back to "how can we protect the SSL certificate of the server?" > To protect against the certificate being stolen with physical access, > you can encrypt the hard drive (it causes other problems, like how you > enter the key to decrypt the disk -- you can SSH during the boot to > provide the decryption key to Luks). > But it does not protect against freezing the RAM of the server to > extract the private key. > > But... this has both little chance to occur and little chance of the > sysadmin/security guys not noticing it (and thus reacting to that > immediately). > This is also probably more complicated and dangerous than, say, being > the US government and request a signed certificate from a US company > under a sort of FISA warrant (that they cannot disclose) to do "lawful > interception". But all of this is very theoretical. > > What Jacob suggests is to have a HSM (Hardware Security Module) that > contains the private certificate and make it impossible (understand: > very very hard) to extract the key. The black box signs what it gets > asked without revealing the certificate. > And then the idea is to do "certificate pinning" in the distribution > to make sure the SSL certificate hasn't be forged by a trusted third > party (see the Comodo/Diginotar problem). > > I doubt/really hope that Debian doesn't need that much complicated > system to securely its package. The crypto smartcard (aka Hardware Security Module) are some work to setup, but not really all that much. And they are easy to use once setup. And they provide a huge boost in the security of the certificate. As for certificate pinning, that is quite easy. Debian already does it, more or less, by including the SPI and cacert.org certificates. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52818c3a.6050...@at.or.at
Re: SSL for debian.org/security?
On 10/30/2013 10:49 AM, Norbert Kiszka wrote: > Dnia 2013-10-30, śro o godzinie 11:34 -0200, Djones Boni pisze: >> On 30-10-2013 11:05, Celejar wrote: >>> You're snipping crucial context; my comment above was in response to >>> this: For apt-get a self-signed certificate could be used which comes together with Debian. No CA required. This is both simpler and safer. >>> I was pointing out that this comment makes no sense in the context of >>> apt-get. It sounds like you're referring to the website or email system. >> I am talking about updates. >> >> Yes. Apt uses OpenPGP to verify the integrity and authenticity of the >> packages it downloads. >> But how does apt get these packages? Over insecure HTTP. >> >> Hacking DNS or MITM attack can hide updates from you or a country. Then >> you are vulnerable due out-of-date software and you don't even know >> about it. >> >> > > >> and you don't even know >> about it. > > Thats why I am on the debian-security@lists.debian.org A governmental firewall could just as easily block an email as it could block/filter information about security updates. In order to understand why tor and TLS would be useful here, it good to break down the various concerns (or threats if you prefer): 1. package authenticity (provided by the GPG signatures) 2. package availability (can currently be manipulated by MITM) 3. repo availability (can be blocked by firewalls) 4. who's downloading what package (currently visible to anyone who can see the network traffic) Most people are used to thinking about #1 when thinking about the security of Debian repos. But 2-4 are also import, and currently not well addressed. This is where TLS and Tor come in. Both can help prevent MITM manipulations as well as reduce the amount of information that is leaked to the network. Tor can also help with #3 since Tor is difficult to block (though China and Iran are effectively blocking tor traffic these days). I think having official Debian repos available with both TLS and Tor available as options is a very good idea. I'm happy to help where I can, but I'm not on the sysadmin team (though I was a sysadmin in a former life). Also, there are a number of official mirrors that already support TLS. I haven't looked to see if there are any repos available from a Tor Hidden Service. .hc signature.asc Description: OpenPGP digital signature
Re: process to include upstream jar sig in Debian-generated jar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/29/2013 10:56 AM, Michael Stone wrote: > On Thu, Aug 29, 2013 at 11:35:47AM +0200, Sébastien Le Ray wrote: >> Yes but the whole thing looks weird, on one hand OP wants to include a >> signed jar in the package, on the other hand he says "signature could >> be omitted if quick update is needed"… What's the point having signed >> JAR if unsigned JAR is legitimate too? Either you ban unsigned JARs or >> you don't use signed JAR at all… > > It leaves that decision of whether to run with the unsigned jar up to > the user. I think this is a reasonable solution if it works in practice, > and is similar in concept to what the openssl folks have done for FIPS > validation. > > Mike Stone > Another idea is that it provides a public record of whether the upstream jar matches the Debian jar, which is guaranteed to be built from source. This could then serve as a verification that the upstream jar did not have code injected into it that is not in the source tarball. One example of a worry of how this might happen is if a governmental agency issues a secret order to implant a back door in said app. .hc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJSH3pGAAoJEJ8P5Yc3S76BTXIP/inFL/bFGLOb6dAWvBwGmjxZ VW++aWVd1tr9YUMR7n6EEcbrswmi6pg2PnezPekijIe/+VyfrL7YrKOGZ+HfAwOX S3XlkrKYs0s/cTQHG6WGEFVWBnbISjQ0MT5YDLea8U/dK8x1tLbbi+ZruC/NDXqS ruJSDSfcPFFHvNNwpqIHLDoTSzLe3iAX7HpLPmWjCzj3Wxtl8UzPElmQ72nlggfH SgNoj0zovnSmUNpd36Uu+CIj5IZZr/Eu6Nrxcw/onKshvl2itSmOqc+SR4cvFvpU P0b4xhzAItnkyfFzNtGxeFQGH/K81Vek1hu0/rblMFbwpPqzL9dMHB/PwIB6hXP8 6gbzGycupGV8ojX/X3QO+ws87Y1YCiiHkcsUcBRa26pRehv815gPZinNDU8GPxgK JTAv8B2cVa/wxyZvCXUMGGjbvJ988/RhkcFh/r3/DEdM6RZ4bjd7z+afSxBvUTFg cR6/7OEGWb926Q3U19NXPLw1bg8B3Yfbm6og6BTtozi6ljNwqVa9Hf29yRLxSp/C U8K5vKt40UkwNi7yd5IKLXYQbTbtRuddU0vV7/ek/hsKZ0xgkZ7a4bnR5U9Ta0DG 8odIhg6mlY3u+iq7rLEbWq5KV2jlJeX5qXRwCWd9CGbRz8upLcSqRxHBtWnggW2R q83YDbYWKqapQ/HWoUpA =W0To -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/521f7a4b.3070...@at.or.at
process to include upstream jar sig in Debian-generated jar
I want to run an unusual idea by everyone here as an approach to getting an outside signature into a packaged Java jar built from source on the Debian build machines: we want to get http://martus.org packaged and into Debian. Martus is an app that has high requirements for security, so they have a very careful build and signing process. They want to be able to include their jar signature in the jar that is included in the Debian package. We figured we could structure the build like this: 1) include the official martus.jar in the source tarball 2) after the Debian build process completes, verify that contents of the Debian generated jar matches the contents of the martus generated jar, except for timestamps 3) if that passes, then set the timestamps in the Debian generated jar to match the timestamps in the martus.jar, then copy the signing material into place in the Debian generated jar That should then result in a debian-generated jar that has the martus signature on it. If Debian Security needed to update the package to fix an urgent issue, then they could still do so. The package build process would only include the upstream signature from martus.jar if it was an exact match. The security fixed version would then result in an unsigned jar, which is standard for jars in Debian. Is this a workable solution here? .hc signature.asc Description: OpenPGP digital signature
Re: pre-screening new package: SQLCipher, based on SQLite3
On Oct 12, 2012, at 9:03 PM, Hans-Christoph Steiner wrote: > > On Oct 1, 2012, at 7:36 PM, Hans-Christoph Steiner wrote: > >> On 10/01/2012 06:32 PM, Stephen Lombardo wrote: >>> Hello Florian, >>> >>> On Mon, Oct 1, 2012 at 1:57 PM, Florian Weimer wrote: >>>> Okay. Can your fork open unencrypted databases? Are there any symbol >>>> collisions with vanilla SQLite? >>>> >>> Yes, SQLCipher can open standard, unencrypted SQLite databases without a >>> problem and it has the same public API and symbols as vanilla SQLite. Many >>> users take advantage of this today to allow substitution in languages like >>> python and ruby. For example they may build SQLCipher in a separate >>> directory then set LD_LIBRARY_PATH to load the SQLCipher-enhanced library >>> for use in their programs. >>> >>> I believe this is is the reason Hans opted to alter the library name to >>> libsqlcipher, to ensure there wouldn't be any confusion between the two, >>> but I'll let him comment on that further. >>> >>> Cheers, >>> Stephen >> SQLCipher shares all of the public symbols that SQLite3 has, plus a few >> more related to the encryption. It is a lightly modified version of >> SQLite3. Like Stephen said, its possible to dynamically load the >> SQLCipher library for an app that was compiled against SQLite3 and it'll >> work. Also, when not using encryption, SQLCipher works the same as >> SQLite3 in terms of SQL commands, C API, etc. >> >> To make it friendly to packaging, I've made the library called >> libsqlcipher.so with its own ABI version related to the SQLCipher >> version, then the headers are in /usr/include/sqlcipher so they don't >> get easily confused for the SQLite3 headers. >> >> Are you thinking that this package should replace the SQLite3 package in >> Debian? I suppose that is a possibility. I'm guessing that the headers >> would need to be split up. Right now the SQLCipher symbols are just in >> sqlite3.h, and that header is in /usr/include/sqlcipher. I suppose >> sqlite3.h could be untouched, then the SQLCipher symbols could go into >> /usr/include/sqlcipher.h or something like that. >> >> The question remaining there would be how to represent the ABI >> versions. So far, there is no established ABI versioning scheme since >> SQLCipher has mostly been used on iOS and Android. So that's the good >> news. The bad news is that SQLCipher 1.19, 2.0 thru 2.0.3 are all based >> on SQLite 3.7.9. In other words, SQLCipher's release cycle is not >> necessarily in sync with SQLite3's release cycle. We discussed this a bunch in early October and then the discussion died. I just wanted to check in to see if anyone has any time to green light this packaging approach, or nail down a different way. The discussion ended with the above: me asking for more information on an idea of whether the SQLCipher package could provide SQLite. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4a222c87-cfab-4be9-8e23-e2cdb2c60...@eds.org
Re: pre-screening new package: SQLCipher, based on SQLite3
On Oct 1, 2012, at 7:36 PM, Hans-Christoph Steiner wrote: > On 10/01/2012 06:32 PM, Stephen Lombardo wrote: >> Hello Florian, >> >> On Mon, Oct 1, 2012 at 1:57 PM, Florian Weimer wrote: >>> Okay. Can your fork open unencrypted databases? Are there any symbol >>> collisions with vanilla SQLite? >>> >> Yes, SQLCipher can open standard, unencrypted SQLite databases without a >> problem and it has the same public API and symbols as vanilla SQLite. Many >> users take advantage of this today to allow substitution in languages like >> python and ruby. For example they may build SQLCipher in a separate >> directory then set LD_LIBRARY_PATH to load the SQLCipher-enhanced library >> for use in their programs. >> >> I believe this is is the reason Hans opted to alter the library name to >> libsqlcipher, to ensure there wouldn't be any confusion between the two, >> but I'll let him comment on that further. >> >> Cheers, >> Stephen > SQLCipher shares all of the public symbols that SQLite3 has, plus a few > more related to the encryption. It is a lightly modified version of > SQLite3. Like Stephen said, its possible to dynamically load the > SQLCipher library for an app that was compiled against SQLite3 and it'll > work. Also, when not using encryption, SQLCipher works the same as > SQLite3 in terms of SQL commands, C API, etc. > > To make it friendly to packaging, I've made the library called > libsqlcipher.so with its own ABI version related to the SQLCipher > version, then the headers are in /usr/include/sqlcipher so they don't > get easily confused for the SQLite3 headers. > > Are you thinking that this package should replace the SQLite3 package in > Debian? I suppose that is a possibility. I'm guessing that the headers > would need to be split up. Right now the SQLCipher symbols are just in > sqlite3.h, and that header is in /usr/include/sqlcipher. I suppose > sqlite3.h could be untouched, then the SQLCipher symbols could go into > /usr/include/sqlcipher.h or something like that. > > The question remaining there would be how to represent the ABI > versions. So far, there is no established ABI versioning scheme since > SQLCipher has mostly been used on iOS and Android. So that's the good > news. The bad news is that SQLCipher 1.19, 2.0 thru 2.0.3 are all based > on SQLite 3.7.9. In other words, SQLCipher's release cycle is not > necessarily in sync with SQLite3's release cycle. Since it been 11 days without a reply since Stephen and I replied, I just wanted to check in on this. We're both currently available to work directly on further concerns, Stephen as upstream and me as packager, so it would be a great time for us to nail this stuff down. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/92d0a24d-1de1-4ddb-9b01-10048c811...@at.or.at
Re: pre-screening new package: SQLCipher, based on SQLite3
On 10/01/2012 06:32 PM, Stephen Lombardo wrote: > Hello Florian, > > On Mon, Oct 1, 2012 at 1:57 PM, Florian Weimer wrote: >> Okay. Can your fork open unencrypted databases? Are there any symbol >> collisions with vanilla SQLite? >> > Yes, SQLCipher can open standard, unencrypted SQLite databases without a > problem and it has the same public API and symbols as vanilla SQLite. Many > users take advantage of this today to allow substitution in languages like > python and ruby. For example they may build SQLCipher in a separate > directory then set LD_LIBRARY_PATH to load the SQLCipher-enhanced library > for use in their programs. > > I believe this is is the reason Hans opted to alter the library name to > libsqlcipher, to ensure there wouldn't be any confusion between the two, > but I'll let him comment on that further. > > Cheers, > Stephen SQLCipher shares all of the public symbols that SQLite3 has, plus a few more related to the encryption. It is a lightly modified version of SQLite3. Like Stephen said, its possible to dynamically load the SQLCipher library for an app that was compiled against SQLite3 and it'll work. Also, when not using encryption, SQLCipher works the same as SQLite3 in terms of SQL commands, C API, etc. To make it friendly to packaging, I've made the library called libsqlcipher.so with its own ABI version related to the SQLCipher version, then the headers are in /usr/include/sqlcipher so they don't get easily confused for the SQLite3 headers. Are you thinking that this package should replace the SQLite3 package in Debian? I suppose that is a possibility. I'm guessing that the headers would need to be split up. Right now the SQLCipher symbols are just in sqlite3.h, and that header is in /usr/include/sqlcipher. I suppose sqlite3.h could be untouched, then the SQLCipher symbols could go into /usr/include/sqlcipher.h or something like that. The question remaining there would be how to represent the ABI versions. So far, there is no established ABI versioning scheme since SQLCipher has mostly been used on iOS and Android. So that's the good news. The bad news is that SQLCipher 1.19, 2.0 thru 2.0.3 are all based on SQLite 3.7.9. In other words, SQLCipher's release cycle is not necessarily in sync with SQLite3's release cycle. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/506a290e.2040...@eds.org
Re: pre-screening new package: SQLCipher, based on SQLite3
On 09/28/2012 04:23 PM, Florian Weimer wrote: > * Hans-Christoph Steiner: > >> The tricky part is that it is a modified version of SQLite3, and lintian >> properly gives an error about that. But because of the features that >> SQLCipher provides, it must modify the core of SQLite to work, therefore >> it cannot be made into a plugin. > Why isn't it implemented as a VFS plugin? I don't know of any other precedent for a VFS plugin for adding encryption support, do you? Maybe Stephen can speak more to that. .hc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5069c924.3050...@eds.org
pre-screening new package: SQLCipher, based on SQLite3
Hey all, I'm reading to upload a new package called SQLCipher (http://sqlcipher.net/) and I want to run it by y'all first. The upside is that it provides AES256 encrypted SQLite databases in a DFSG-free package that has been pretty widely tested, deployed and audited. You can find out more here: http://sqlcipher.net/design The tricky part is that it is a modified version of SQLite3, and lintian properly gives an error about that. But because of the features that SQLCipher provides, it must modify the core of SQLite to work, therefore it cannot be made into a plugin. The sqlcipher package is based off of the sqlite3 package and includes most of its patches. Hurd and Tcl support are not there yet, so those are the omitted patches. SQLCipher is currrently based off of SQLite3 3.7.12, so its reasonably current (squeeze's SQLite3 is 3.7.3, wheezy's is 3.7.13). Here's the full reasoning from the original author of SQLCipher: On 09/27/2012 03:52 PM, Stephen Lombardo wrote: > SQLCipher modifies SQLite itself, which is the reason we maintain a > separate version of the full source tree. However, we do try very hard to > minimize alterations to core SQLite code, especially to reduce the risk of > things breaking when we merge in upstream changes. > > Unfortunately it would be exceedingly difficult / impossible to make > SQLCipher a plugin to an unmodified SQLite for a number of reasons. > > >1. Enabling the codec system requires the compile-time definition of >SQLITE_HAS_CODEC, which is not present on standard, unmodified SQLite >builds. >2. Even when enabled, SQLite isn't setup to load codecs as plugins. >While SQLite does have a plugin function for loadable modules, this doesn't >extend to any system internals (it mainly used to allow custom user >functions). >3. SQLCipher makes calls to internal functions that are not part of the >public SQLite API. Sometimes these APIs change even in between minor SQLite >versions, and thus require inspection, testing and verification on each >update. Making SQLCipher portable across multiple versions of SQLite would >not be feasible, nor could we easily force it to use only the public API >(for instance, even the first critical step of attaching the codec callback >to the pager uses an internal API). >4. SQLCipher modifies supporting functions to introduce special pragmas, >built in functions, etc (e.g. PRAGMA cipher_*). Injecting this >functionality in a plugin architecture wouldn't be possible, resulting in >major API changes. >5. SQLCipher's test harness needs to be built into libsqlite3 & >testfixture to take advantage of the test API and various internal checks >(memory reference counting, etc) >6. Even if it were possible to use a loadable plugin, dynamic libraries >aren't available on all supported platforms (e.g. iOS) > > It is definitely undesirable to maintain a separate parallel codebase for > SQLCipher, but unfortunately I don't think there is a better way at this > time. > > Cheers, > Stephen signature.asc Description: OpenPGP digital signature
