[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian packages without md5sums

Florian Kulzer <florian.kulzer+debian@icfo.es> writes:

> [ Felix, I hope this message also helps with your problem. ]
> On Thu, Oct 04, 2007 at 16:22:06 -0700, Carl Johnson wrote:
> > Florian Kulzer writes:
> > > On Tue, Oct 02, 2007 at 21:02:41 -0700, Carl Johnson wrote:
> > > 
> > > Did you try to remove all the DVD-related lines from your
> > > /etc/apt/sources.list, run "aptitude update" and then add the DVD(s)
> > > again using the "apt-cdrom" command? I think that should work but I have
> > > not tested it.
> > 
> > I hadn't tried that originally, but I have since with no change.
> [ snip: output of "apt-key list" ]
> You have all the necessary keys for a normal Debian system. However, it
> seems that the DVDs and CDs simply do not contain Release.gpg files, so
> there are no signatures to check. (I looked at an old netinst CD and I
> downloaded the first Etch_r1 amd64 CD; I could not find a Release.gpg
> file on either one.)
> What you can do now is to check the md5sums and the sha1sums of the
> DVDs.  If they match then you can be reasonably sure that all the
> individual packages on these DVDs are OK.
> First you need to download the files which list these checksums:
>   wget http://cdimage.debian.org/debian-cd/4.0_r1/i386/iso-dvd/MD5SUMS{,.sign}
>   wget http://cdimage.debian.org/debian-cd/4.0_r1/i386/iso-dvd/SHA1SUMS{,.sign}

I didn't notice until after I downloaded them that they are i386, but
I have amd64, but it was easy enough to find the amd64 ones.  Then I
noticed that they are 4.0_r1 and I just have the original 4.0.  That
is where I struck out and was unable to find any other than r1.

> Then you can verify the signatures on the two files:
>   gpg --verify MD5SUMS.sign
>   gpg --verify SHA1SUMS.sign
> These two commands should download Steve McIntyre's public key (ID
> 88C7C1F7) from a keyserver and then check if the current content of
> these files has indeed been signed by him. ("Good signature from ...")

I then discovered that I had never bothered setting up gnupg, so it
couldn't find a keyserver.  I looked for documentation without
success, so it appears I will have to get to the non-free archives to
get documentation for gnupg (and many others).

> Now you can test if your DVDs have the same MD5 and SHA1 checksums as
> listed in MD5SUMS and SHA1SUMS. To calculate these checksums for your
> DVDs, put one of them into the drive and run:
>   md5sum -b /dev/scd0
>   sha1sum -b /dev/scd0
> You have to replace "/dev/scd0" with the correct device node of your DVD
> reader; check where the dvd symlink is pointing ("ls -l /dev/dvd").
> Calculating these sums for a whole DVD will take a while, even on a fast
> computer. You can run all the above commands as you normal user;
> however, you have to be a member of the "cdrom" group to read the raw
> DVD device.

I ran checksums on the first DVD and found they didn't match, as I
expected by now.

> Once you are happy about your DVDs, you can do this (as root):
> echo 'APT::Authentication::TrustCDROM "true";' > /etc/apt/apt.conf.d/99trust-cdrom 
> This tells apt(itude) to trust all "cdrom:" sources. (The DVDs have
> cdrom: URIs in /etc/apt/sources.list, right?)

I ended up doing this anyways, since they are official DVDs from a
vendor listed at debian.org.  I was going to file a bug about the
Release.gpg not being present, until I suddenly realized that they
can't put them on the ISO image without changing the checksum.

> > > > I also noticed
> > > > recently that some packages show multiple entries in aptitude, so
> > > > possibly clearing the entries would clear that.
> > > 
> > > Do you mean multiple versions for the same package or the same package
> > > name as two separate entries? (The former would be OK, the latter would
> > > be cause for concern, I think.) Can you give an example with more
> > > details?
> > 
> > I should have been more clear about that.  I don't have different
> > versions since I just have packages from the Etch DVDs.  It isn't in
> > the actual aptitude list, but instead in the individual package
> > entries.  The list of packages that depend on the package sometimes
> > shows duplicate entries for packages that I already have.  This may
> > just be an artifact of the way that aptitude tracks reverse
> > dependencies.  An example is under apt, the list of 'packages which
> > depend on apt' includes:
> > 
> > i     debtags 1.6.6                                                                                           
> > i     debtags 1.6.6
> Hmm, can you post the output of "apt-cache policy debtags"?

Here it is, but debtags isn't the only one:

  Installed: 1.6.6
  Candidate: 1.6.6
  Version table:
 *** 1.6.6 0
        500 cdrom://[Debian GNU/Linux 4.0 r0 _Etch_ - Official amd64 DVD Binary-1 20070407-12:15] etch/main Packages
        100 /var/lib/dpkg/status

> > My /etc/apt/sources.list has only the 3 original Debian 4.0 DVD's, and
> > all other entries have been commented out throughout this time.
> > 
> > Thanks for taking the time to look at this.  This isn't a problem now,
> > but I am nervous about adding other packages from the net without some
> > verification that they are valid.
> Your system is already configured to check all the packages from the
> net, but it is important that that we get rid of the "untrusted" message
> for the DVD packages. (Otherwise you will get used to ignoring the
> warning or, even worse, you will be tempted to turn it off globally.)

Thanks for your help, but I finally decided to take your earlier
advice already and just mark the DVDs as trusted.  At least I feel
better now that I know why it wouldn't trust the DVDs.

Carl Johnson		carlj@peak.org

Reply to: