Missing ISO hash
The Debian 7.6 update ISO hashes are missing on bt-dvd directory. http://cdimage.debian.org/debian-cd/7.6.0/amd64/bt-dvd/MD5SUMS http://cdimage.debian.org/debian-cd/7.6.0/*/bt-dvd/MD5SUMS They can be found in iso-dvd and jigdo-dvd. http://cdimage.debian.org/debian-cd/7.6.0/amd64/iso-dvd/MD5SUMS http://cdimage.debian.org/debian-cd/7.6.0/amd64/jigdo-dvd/MD5SUMS -- 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/53c3b9cc.7000...@gmail.com
Re: Missing ISO hash
Djones Boni 07ea86b...@gmail.com (2014-07-14): The Debian 7.6 update ISO hashes are missing on bt-dvd directory. http://cdimage.debian.org/debian-cd/7.6.0/amd64/bt-dvd/MD5SUMS http://cdimage.debian.org/debian-cd/7.6.0/*/bt-dvd/MD5SUMS They can be found in iso-dvd and jigdo-dvd. http://cdimage.debian.org/debian-cd/7.6.0/amd64/iso-dvd/MD5SUMS http://cdimage.debian.org/debian-cd/7.6.0/amd64/jigdo-dvd/MD5SUMS This looks OK now. Mraw, KiBi. signature.asc Description: Digital signature
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 h...@at.or.at 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/ 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 -- To UNSUBSCRIBE, email
Re: concrete steps for improving apt downloading security and privacy
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. -- bye, pabs https://wiki.debian.org/PaulWise -- 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/CAKTje6Fk+8zDHmQRsqYLDe0ABAb8q2OMrnRmvyhp2OyYFe=w...@mail.gmail.com
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
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. -- bye, pabs https://wiki.debian.org/PaulWise -- 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/caktje6gmcuzzrmcqqealto-sj4ybw42t3fkjxxbxbxc282u...@mail.gmail.com
Re: concrete steps for improving apt downloading security and privacy
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 -- 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/b0a0301e-0b79-11e4-8363-00163eeb5...@msgid.mathom.us
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 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 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? Mike Stone -- 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/d4a2c78e-0b7d-11e4-b7fa-00163eeb5...@msgid.mathom.us
Torrent tracker problem
These torrents are not working with the Debian tracker. http://cdimage.debian.org/debian-cd/7.6.0/source/bt-cd/debian-update-7.6.0-source-CD-1.iso.torrent http://cdimage.debian.org/debian-cd/7.6.0/source/bt-cd/debian-update-7.6.0-source-CD-2.iso.torrent Torrent Editor and also my Torrent software says that the tracker has not seen these torrents and is not working with them. Check for yourself at these links: http://torrenteditor.com/edit.php?url=http%3A%2F%2Fcdimage.debian.org%2Fdebian-cd%2F7.6.0%2Fsource%2Fbt-cd%2Fdebian-update-7.6.0-source-CD-1.iso.torrent http://torrenteditor.com/edit.php?url=http%3A%2F%2Fcdimage.debian.org%2Fdebian-cd%2F7.6.0%2Fsource%2Fbt-cd%2Fdebian-update-7.6.0-source-CD-2.iso.torrent I am only seeding the i386, amd-64, powerpc and source media ISO's. Not sure if there are problems with other media.
Re: Torrent tracker problem
On Mon, 2014-07-14 at 14:15 -0600, Kitty Cat wrote: These torrents are not working with the Debian tracker. http://cdimage.debian.org/debian-cd/7.6.0/source/bt-cd/debian-update-7.6.0-source-CD-1.iso.torrent http://cdimage.debian.org/debian-cd/7.6.0/source/bt-cd/debian-update-7.6.0-source-CD-2.iso.torrent I'm not sure what you expected anyone on -security to do about that. In any case, I mentioned your message to a member of the CD team and things should be working now. Regards, Adam -- 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/1405376795.2015.38.ca...@jacala.jungle.funky-badger.org
External check
CVE-2013-2101: RESERVED CVE-2013-4120: RESERVED CVE-2014-0026: RESERVED CVE-2014-0029: RESERVED CVE-2014-0183: RESERVED CVE-2014-3531: RESERVED -- The output might be a bit terse, but the above ids are known elsewhere, check the references in the tracker. The second part indicates the status of that id in the tracker at the moment the script was run. -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c37c3e.gs2l472772qlsvkz%atomo64+st...@gmail.com
