Debian Bug report logs - #203741
Release file signature verification (ABI change)

Package: apt; Maintainer for apt is APT Development Team <deity@lists.debian.org>; Source for apt is src:apt.

Reported by: Mikko Rauhala <mjr@iki.fi>

Date: Fri, 1 Aug 2003 07:03:03 UTC

Severity: wishlist

Tags: fixed-in-experimental

Done: Filipus Klutiero <ido@vif.com>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Mikko Rauhala <mjr@iki.fi>:
New Bug report received and forwarded. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Mikko Rauhala <mjr@iki.fi>
To: bugs@debian.org
Date: 01 Aug 2003 10:02:50 +0300
Package: apt

If there has been a nice script for checking Release and Packages file
integrities, wouldn't it be time to include that in the base apt package
(or better yet, include the functionality in apt to be done
automatically during update).

Ref. Debian Security Manual and
http://people.debian.org/~ajt/apt-check-sigs





Changed Bug title. Request was from Matt Zimmerman <mdz@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `wishlist'. Request was from Matt Zimmerman <mdz@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from Matt Zimmerman <mdz@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Colin Walters <walters@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #16 received at 203741@bugs.debian.org (full text, mbox):

From: Colin Walters <walters@debian.org>
To: Matt Zimmerman <mdz@debian.org>
Cc: Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: apt sigcheck patches
Date: Wed, 20 Aug 2003 23:26:45 -0400
[Message part 1 (text/plain, inline)]
On Wed, 2003-08-20 at 18:33, Matt Zimmerman wrote:
> Could you send your patches to me or to #203741 so that I can look into
> merging them into apt CVS?

The patch is attached, I updated it to the latest CVS.
Let us know if you have any questions!

I'd also like to try merging the documentation we have into the apt docs
at some point.

[apt-secure.patch (text/x-patch, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Colin Walters <walters@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #21 received at 203741@bugs.debian.org (full text, mbox):

From: Colin Walters <walters@debian.org>
To: Matt Zimmerman <mdz@debian.org>
Cc: Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: apt sigcheck patches
Date: Thu, 21 Aug 2003 11:50:39 -0400
[Message part 1 (text/plain, inline)]
On Thu, 2003-08-21 at 10:16, Matt Zimmerman wrote:

> Why should it be necessary to modify sources.list to specify the vendor?  I
> would have either expected this to be determined from the Release file, or
> to have a list of trusted vendors and not care which source corresponds to
> which vendor. 

Well, first because you need to have some way to specify whether or not
the source is secured.  You can't take the absence of the Release file
to mean it's not, for obvious reasons.  And a lot of personal-type apt
sources aren't secured, and aren't likely to be anytime soon.

Secondly, because you don't want someone to be able to replace one valid
archive with another, such as replacing Debian stable (and presumably no
security holes) with Debian unstable (and presumably some nonempty set
of holes).

>  It would be nice if we could do this without changing the
> syntax of sources.list, so that older apts are forward compatible.

Well, older apts are forwards compatible - they at least don't barf on
the [...] because it's been parsed by sourcelist.cc (and ignored) since
before woody.

> > I'd also like to try merging the documentation we have into the apt docs
> > at some point.
> 
> That would be great; feel free to send me whatever you have.

Attached is a copy of the Docbook XML we were using for the website.

[apt-secure.xml (text/xml, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Colin Walters <walters@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #26 received at 203741@bugs.debian.org (full text, mbox):

From: Colin Walters <walters@debian.org>
To: Matt Zimmerman <mdz@debian.org>
Cc: ajt@debian.org, Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: apt sigcheck patches
Date: Thu, 21 Aug 2003 15:49:14 -0400
[ re-adding Isaac to CC ]

On Thu, 2003-08-21 at 15:33, Matt Zimmerman wrote:

> I would say that by default, it should go ahead and use the unsecured
> sources, but display a warning to the user.  This is a change from "expect
> security only when explicitly requested" and "expect security by default".
> Because most software does (and will continue to) come from Debian proper,
> and thus will be signed, unofficial repositories will become the exceptional
> case, and I think this strategy can work.

Ok.  Aj, do you agree?

There is something nagging me about this - I have a feeling that there
was a better reason we decided to put the source name in the
sources.list, but after briefly going over my apt-secure mail I don't
see it.

> A force option could be provided, but I think it would be better to make it
> a no-brainer for a source to be secured.

I agree with that.

> I think that per-release keys make more sense than per-year keys for this
> reason.

Ok - you will have to convince the ftpmasters too.

Just a note: I don't think I'll have much time to implement these
changes until late next week at the earliest.  Probably later than that
actually.  So if you beat me to it, that's great :)
Your changes will make the code significantly simpler, by the way. 
Mostly the work will be deleting code.  In fact it will almost be like
just adding the gpgv method.



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Colin Walters <walters@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #31 received at 203741@bugs.debian.org (full text, mbox):

From: Colin Walters <walters@debian.org>
To: Anthony Towns <ajt@debian.org>
Cc: Matt Zimmerman <mdz@debian.org>, Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: apt sigcheck patches
Date: Thu, 21 Aug 2003 15:21:37 -0400
[ re-adding Isaac to the CC list ]

On Thu, 2003-08-21 at 14:37, Anthony Towns wrote:

> So, why don't we just give them a script? 

In other words: why don't we make everyone use only secure sources?

Maybe if this functionality was added to apt-ftparchive or something, I
would be OK with it.  Even then though it's going to be a pain for a lot
of people to change all their apt source generating scripts, and for all
the users of these various archives to add the keys to their
trusted.gpg.



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #36 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Colin Walters <walters@debian.org>
Cc: Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: apt sigcheck patches
Date: Thu, 21 Aug 2003 10:16:38 -0400
On Wed, Aug 20, 2003 at 11:26:45PM -0400, Colin Walters wrote:

> On Wed, 2003-08-20 at 18:33, Matt Zimmerman wrote:
> > Could you send your patches to me or to #203741 so that I can look into
> > merging them into apt CVS?
> 
> The patch is attached, I updated it to the latest CVS.
> Let us know if you have any questions!

OK, I've set things up and it seems to be working, neat.  I have a few
questions:

Why should it be necessary to modify sources.list to specify the vendor?  I
would have either expected this to be determined from the Release file, or
to have a list of trusted vendors and not care which source corresponds to
which vendor.  It would be nice if we could do this without changing the
syntax of sources.list, so that older apts are forward compatible.

> I'd also like to try merging the documentation we have into the apt docs
> at some point.

That would be great; feel free to send me whatever you have.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Colin Walters <walters@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #41 received at 203741@bugs.debian.org (full text, mbox):

From: Colin Walters <walters@debian.org>
To: Matt Zimmerman <mdz@debian.org>
Cc: ajt@debian.org
Subject: Re: apt sigcheck patches
Date: Thu, 21 Aug 2003 13:51:32 -0400
[ Added aj to the CC as I'm pretty sure he's interested in this ]

On Thu, 2003-08-21 at 12:13, Matt Zimmerman wrote:

> It seems OK not to specify whether the source is secured, as long as you're
> not rejecting insecure sources (maybe issuing a warning?).

I'd get pretty annoyed at being prompted every time to ignore unsecured
sources.  And if we add an option to ignore unsecured sources, then
people will just use that, and that kind of makes the whole thing
pointless.

Say company has a setup with a bunch of Debian stable machines, using
apt-secure.  They of course use security.debian.org.  However they also
have a trusted server on their intranet that provides some packages, and
all the other machines use it as an apt source.  Because Debian doesn't
have any standard scripts for generating a secured apt source, and since
it's on their secure intranet, they don't bother checking the sigs on
the Release file.

This company also has scripts to automatically upgrade all the machines
on their intranet.  They don't want to have any user interaction, so
prompting is out.

How would you solve this problem without specifying whether or not a
source is secured in the sources.list?

> Presumably, if you don't trust Debian unstable, you wouldn't have the key
> for unstable in your list.  Though, I guess if we use one key per year
> rather than a key per release, this won't work (unfortunately).

Right.



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #46 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Colin Walters <walters@debian.org>
Cc: ajt@debian.org
Subject: Re: apt sigcheck patches
Date: Thu, 21 Aug 2003 15:33:50 -0400
On Thu, Aug 21, 2003 at 01:51:32PM -0400, Colin Walters wrote:

> On Thu, 2003-08-21 at 12:13, Matt Zimmerman wrote:
> 
> > It seems OK not to specify whether the source is secured, as long as
> > you're not rejecting insecure sources (maybe issuing a warning?).
> 
> I'd get pretty annoyed at being prompted every time to ignore unsecured
> sources.  And if we add an option to ignore unsecured sources, then people
> will just use that, and that kind of makes the whole thing pointless.

I would say that by default, it should go ahead and use the unsecured
sources, but display a warning to the user.  This is a change from "expect
security only when explicitly requested" and "expect security by default".
Because most software does (and will continue to) come from Debian proper,
and thus will be signed, unofficial repositories will become the exceptional
case, and I think this strategy can work.

Currently, any one of these unofficial repositories could simply swap in a
trojan for a new <random essential package>; all they need to do is to
specify a higher version number.  Since their source is listed as insecure
in sources.list, no verification is done and no warning is displayed.

If a user asks to install (or upgrade!) a package, and the selected version
is coming from an insecure source, I think apt should warn loudly about
this, and ask for confirmation.  Because this will only happen when fetching
new packages from unofficial sources (which should be, by far, the less
common case), I don't think there is too much danger in users pressing the
"ignore" button.

If we don't expect security by default, mixing secure and insecure sources
doesn't provide much security, and the download indicator is the only way to
indication of whether a package comes from a trusted source.

> Say company has a setup with a bunch of Debian stable machines, using
> apt-secure.  They of course use security.debian.org.  However they also
> have a trusted server on their intranet that provides some packages, and
> all the other machines use it as an apt source.  Because Debian doesn't
> have any standard scripts for generating a secured apt source, and since
> it's on their secure intranet, they don't bother checking the sigs on the
> Release file.

We should certainly provide tools for this; I expect that apt-ftparchive
could be extended to generate release files and sign them without too much
trouble.

> This company also has scripts to automatically upgrade all the machines on
> their intranet.  They don't want to have any user interaction, so
> prompting is out.

A force option could be provided, but I think it would be better to make it
a no-brainer for a source to be secured.

> > Presumably, if you don't trust Debian unstable, you wouldn't have the
> > key for unstable in your list.  Though, I guess if we use one key per
> > year rather than a key per release, this won't work (unfortunately).
> 
> Right.

I think that per-release keys make more sense than per-year keys for this
reason.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #51 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Colin Walters <walters@debian.org>
Cc: Anthony Towns <ajt@debian.org>, Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: apt sigcheck patches
Date: Thu, 21 Aug 2003 15:52:24 -0400
On Thu, Aug 21, 2003 at 03:21:37PM -0400, Colin Walters wrote:

> On Thu, 2003-08-21 at 14:37, Anthony Towns wrote:
> 
> > So, why don't we just give them a script? 
> 
> In other words: why don't we make everyone use only secure sources?
> 
> Maybe if this functionality was added to apt-ftparchive or something, I
> would be OK with it.  Even then though it's going to be a pain for a lot
> of people to change all their apt source generating scripts, and for all
> the users of these various archives to add the keys to their
> trusted.gpg.

apt-ftparchive would definitely be the place for it.

Key management is, of course, the bane of all cryptosystems, but I think
that with a few simple tools it could become relatively painless.  A single
command could download the key and import it into the keyring.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #56 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Colin Walters <walters@debian.org>
Cc: Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: apt sigcheck patches
Date: Thu, 21 Aug 2003 21:01:29 -0400
[Message part 1 (text/plain, inline)]
On a system running apt CVS + this patch, I get a number of reproducible
segfaults.  For example, after "apt-get source" and "apt-get install".

#0  0x401ff136 in mallopt () from /lib/libc.so.6
#1  0x401ff050 in mallopt () from /lib/libc.so.6
#2  0x401fde67 in free () from /lib/libc.so.6
#3  0x4013e261 in operator delete(void*) () from /usr/lib/libstdc++.so.5
#4  0x4013e2bc in operator delete[](void*) () from /usr/lib/libstdc++.so.5
#5  0x4004e09b in ~pkgTagFile (this=0x80aeb70) at tagfile.cc:58
#6  0x40083bec in ~debRecordParser (this=0x8092770) at basic_string.h:217
#7  0x40055589 in ~pkgRecords (this=0xbffff340) at pkgrecords.cc:55
#8  0x08058c6b in DoSource(CommandLine&) (CmdL=@0x41181940) at apt-get.cc:747
#9  0x4003cea4 in CommandLine::DispatchArg(CommandLine::Dispatch*, bool) (
    this=0xbffff480, Map=0xbffff490, NoMatch=true) at contrib/cmndline.cc:340
#10 0x0805bb27 in main (argc=3, argv=0xbffff7d4) at apt-get.cc:2423

It doesn't crash in any new code, but another apt built with the same
compiler, without the sigcheck patch, doesn't have this problem.  Maybe
there is some heap corruption happening somewhere?

[...]

Using the patch from #206366, I was able to run the patched apt under
valgrind, and it reports a number of errors.  The unpatched apt comes up
clean.  Output is attached.

-- 
 - mdz
[apt-secure-valgrind.txt (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Anthony Towns <ajt@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #61 received at 203741@bugs.debian.org (full text, mbox):

From: Anthony Towns <ajt@debian.org>
To: Colin Walters <walters@debian.org>
Cc: Matt Zimmerman <mdz@debian.org>
Subject: Re: apt sigcheck patches
Date: Fri, 22 Aug 2003 04:37:19 +1000
[Message part 1 (text/plain, inline)]
On Thu, Aug 21, 2003 at 01:51:32PM -0400, Colin Walters wrote:
> Say company has a setup with a bunch of Debian stable machines, using
> apt-secure.  They of course use security.debian.org.  However they also
> have a trusted server on their intranet that provides some packages, and
> all the other machines use it as an apt source.  Because Debian doesn't
> have any standard scripts for generating a secured apt source, and since
> it's on their secure intranet, they don't bother checking the sigs on
> the Release file.

So, why don't we just give them a script? 

	echo 'Origin: foocorp'
	echo 'Label: foocorp'
	echo 'Suite: testing/foocorp'
	echo 'Codename: sarge/foocorp'
	echo 'Date:' `date -R -u`
	echo 'Architectures: i386'
	echo 'Components: main'
	echo 'Description: foocorp local packages'
	echo 'MD5Sum:'
	for a in */binary-*/{Release,Packages}* */source/{Release,Sources}*; do
		m=`md5sum < $a | cut -d\  -f1`
		s=`wc -c < $a | tr -d ' '`
		printf ' %s %16d %s' $m $s $a
	done

or something similar should do, really.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

       ``Is this some kind of psych test?
                      Am I getting paid for this?''
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #66 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Colin Walters <walters@debian.org>
Cc: Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: apt sigcheck patches
Date: Thu, 21 Aug 2003 12:13:09 -0400
On Thu, Aug 21, 2003 at 11:50:39AM -0400, Colin Walters wrote:

> On Thu, 2003-08-21 at 10:16, Matt Zimmerman wrote:
> 
> > Why should it be necessary to modify sources.list to specify the vendor?
> > I would have either expected this to be determined from the Release
> > file, or to have a list of trusted vendors and not care which source
> > corresponds to which vendor. 
> 
> Well, first because you need to have some way to specify whether or not
> the source is secured.  You can't take the absence of the Release file to
> mean it's not, for obvious reasons.  And a lot of personal-type apt
> sources aren't secured, and aren't likely to be anytime soon.

It seems OK not to specify whether the source is secured, as long as you're
not rejecting insecure sources (maybe issuing a warning?).

> Secondly, because you don't want someone to be able to replace one valid
> archive with another, such as replacing Debian stable (and presumably no
> security holes) with Debian unstable (and presumably some nonempty set of
> holes).

Presumably, if you don't trust Debian unstable, you wouldn't have the key
for unstable in your list.  Though, I guess if we use one key per year
rather than a key per release, this won't work (unfortunately).

> >  It would be nice if we could do this without changing the syntax of
> >  sources.list, so that older apts are forward compatible.
> 
> Well, older apts are forwards compatible - they at least don't barf on the
> [...] because it's been parsed by sourcelist.cc (and ignored) since before
> woody.

Ahh, ok.  No worries then.  I didn't realize that.

> > That would be great; feel free to send me whatever you have.
> 
> Attached is a copy of the Docbook XML we were using for the website.

Thanks.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Filip Van Raemdonck <mechanix@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #71 received at 203741@bugs.debian.org (full text, mbox):

From: Filip Van Raemdonck <mechanix@debian.org>
To: Matt Zimmerman <mdz@debian.org>, 203741@bugs.debian.org
Cc: Colin Walters <walters@debian.org>, Anthony Towns <ajt@debian.org>
Subject: Re: Bug#203741: apt sigcheck patches
Date: Tue, 26 Aug 2003 22:07:51 +0200
On Thu, Aug 21, 2003 at 03:33:50PM -0400, Matt Zimmerman wrote:
> On Thu, Aug 21, 2003 at 01:51:32PM -0400, Colin Walters wrote:
> > 
> > I'd get pretty annoyed at being prompted every time to ignore unsecured
> > sources.  And if we add an option to ignore unsecured sources, then people
> > will just use that, and that kind of makes the whole thing pointless.
> 
> I would say that by default, it should go ahead and use the unsecured
> sources, but display a warning to the user.
<...>
> If a user asks to install (or upgrade!) a package, and the selected version
> is coming from an insecure source, I think apt should warn loudly about
> this, and ask for confirmation.

And add an option (defaulting to false I suppose given the earlier
conversation) to actually bail out instead of asking? Thinking about
semi-automated update scripts here - which may want to _not_ upgrade
instead of forcing upgrades when something strange happens.

> > This company also has scripts to automatically upgrade all the machines on
> > their intranet.  They don't want to have any user interaction, so
> > prompting is out.
> 
> A force option could be provided, but I think it would be better to make it
> a no-brainer for a source to be secured.

Actually, wouldn't a force (install) option be a bad idea even in the
above situation? If someone messes with that company's internet connection
and redirects *.debian.org to his own, unsigned archive, the force install
options would have their scripts happily ignore the lack of a key.


Regards,

Filip

-- 
Evil Overlord Quote of the Day:
150.I will provide funding and research to develop tactical and strategic
weapons covering a full range of needs so my choices are not limited to
"hand to hand combat with swords" and "blow up the planet".



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #76 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Filip Van Raemdonck <mechanix@debian.org>
Cc: 203741@bugs.debian.org, Colin Walters <walters@debian.org>, Anthony Towns <ajt@debian.org>
Subject: Re: Bug#203741: apt sigcheck patches
Date: Tue, 26 Aug 2003 16:18:22 -0400
On Tue, Aug 26, 2003 at 10:07:51PM +0200, Filip Van Raemdonck wrote:

> On Thu, Aug 21, 2003 at 03:33:50PM -0400, Matt Zimmerman wrote:
> > I would say that by default, it should go ahead and use the unsecured
> > sources, but display a warning to the user.
> <...>
> > If a user asks to install (or upgrade!) a package, and the selected
> > version is coming from an insecure source, I think apt should warn
> > loudly about this, and ask for confirmation.
> 
> And add an option (defaulting to false I suppose given the earlier
> conversation) to actually bail out instead of asking? Thinking about
> semi-automated update scripts here - which may want to _not_ upgrade
> instead of forcing upgrades when something strange happens.

Of course, it would work just like the other prompts in apt, and do
something sane if a non-interactive mode is requested.

> > A force option could be provided, but I think it would be better to make
> > it a no-brainer for a source to be secured.
> 
> Actually, wouldn't a force (install) option be a bad idea even in the
> above situation? If someone messes with that company's internet connection
> and redirects *.debian.org to his own, unsigned archive, the force install
> options would have their scripts happily ignore the lack of a key.

There are all sorts of reasons why it would be a bad idea to force it, but
sometimes you need to let the user decide their own risks rather than trying
to decide for them.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #81 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Jason Gunthorpe <jgg@debian.org>
Cc: 207400@bugs.debian.org, Jeff Licquia <licquia@progeny.com>, 203741@bugs.debian.org
Subject: Re: Bug#207400: Notes
Date: Wed, 27 Aug 2003 10:29:13 -0400
On Tue, Aug 26, 2003 at 11:40:23PM -0600, Jason Gunthorpe wrote:

> So, I'll chime in here..
> 
> I belive in the past I've looked at all these patches, at least in some
> earlier form, and there are reasons things are as they are..

Thanks for taking the time to look over this stuff again.

> The stuff to handle RPM version+naming+dependencies has developed alot of
> regressions since I merged the earlier passes. This is hard to fix because
> you need to see the whole picture of how and why DEB and RPM deviate from
> each other so that you don't introduce a regression into either side. It's
> also a little tricky to know where to put all the necessary new
> interfaces.

I'm fairly RPM-ignorant at this level of detail, but I'm going to try to
pick it up so that I can properly evaluate these changes.  It seems clear
that some new interfaces will be necessary; if you have any hints on where
they should go, that would be appreciated.

> SSL stuff from Progeny/etc: I was more or less happy with the last patch I
> saw, my biggest concern was the shear amount of extra goo that had to be
> directly copied from some ssl sample program to make it work. I don't
> recall if the work was done to make a seperate binary package for the SSL
> stuff or if that even makes sense anymore.
>
> I'm not sure what the other 3 items in Progreny's patch are?

Jeff Licquia at Progeny has been kind enough to split up the patches and
file them in the BTS, so this should all be clear very soon.  It does not
currently build a separate binary package, and introduces a libssl
dependency in the binary package.  This would seem to be nontrivial to fix
because both methods are in the same binary.  I think this happened in order
to support redirects from http to https and that sort of thing.  Presumably,
this could be changed to use dlopen.

> SWIG: I never liked the idea of the SWIG markup in the code. Since Gustavo
> has said that the SWIG authors will not accept the patch I'd drop it. It
> also sounds like the python-apt painfully hand crafted bindings are
> nicer..

I agree, though I wish I had time to keep the bindings up to date.

> lua: It looked neat, but I never understood what Connectiva was doing with
> it. APT's operation is already very complicated, I worry that adding
> strage arbitary user scripting will only make it hard to understand bug
> reports.

The lua stuff is pretty clearly marked, so I think this can be easily
excluded.  One thing that they seem to have done with it is the program in
contrib/apt-files, which does some sort of munging of Contents files.

> Signed Repos: Parts of this exist in all sorts of forms..  Colin's
> solution seems closer to what I think is needed than Connectiva's - in
> that it does everything in a single download pass. This is harder but has
> a faster runtime. The patch Colin just sent seems pretty close, but I only
> looked briefly. It looks similar to the last patch I saw which did have
> some problems. Since this is a security thing it has to be inspected and
> any holes that could result in an unsecured file being used must be fixed.
> Otherwise you are just deluding yourself if you think there is any
> security.. 

#203741 has some discussion about Colin's patch.  I thought it made more
sense to trust anything signed by a key in the trusted keyring, and nag the
user about anything which isn't trusted, rather than specify in sources.list
which sources are secure and which are not.  Otherwise, having any unsecured
source in sources.list makes the whole thing insecure.  This would
apparently simplify things quite a bit as well.  What do you think?

> Connectiva Build System: Gustavo did this because he hated my original one
> :> Unfortunately in the process a number of things that are important for
> Debian got striped out. It would be a big job to merge this and restore
> all the lost functionality.

Is there any particular advantage to it?  There are a lot of checks in
configure.in, but as far as I know, none of them are necessary for modern
Linux distributions.

> I just ran through the connectiva diff of only the apt-pkg directory. Lots
> can just be blindly merged. Lots needs more thought and there is a bunch
> of stuff that doesn't look quite right..

I'm hoping to pick out the stuff that can be merged right away to trim down
the diff, so that the trees can stay closer and common fixes can be shared
at least.

I'm about to leave for vacation and won't be looking at this stuff anymore
until I get back; I'll run down your list then.  Thanks again.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Jeff Licquia <licquia@progeny.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #86 received at 203741@bugs.debian.org (full text, mbox):

From: Jeff Licquia <licquia@progeny.com>
To: Matt Zimmerman <mdz@debian.org>
Cc: Jason Gunthorpe <jgg@debian.org>, 207400@bugs.debian.org, 203741@bugs.debian.org
Subject: Re: Bug#207400: Notes
Date: 27 Aug 2003 11:06:08 -0500
On Wed, 2003-08-27 at 09:29, Matt Zimmerman wrote:
> On Tue, Aug 26, 2003 at 11:40:23PM -0600, Jason Gunthorpe wrote:
> > SSL stuff from Progeny/etc: I was more or less happy with the last patch I
> > saw, my biggest concern was the shear amount of extra goo that had to be
> > directly copied from some ssl sample program to make it work. I don't
> > recall if the work was done to make a seperate binary package for the SSL
> > stuff or if that even makes sense anymore.
> >
> > I'm not sure what the other 3 items in Progreny's patch are?

Support for HTTP redirect, interactive authentication, and cookies.  The
former two have implications for libapt-pkg.

> Jeff Licquia at Progeny has been kind enough to split up the patches and
> file them in the BTS, so this should all be clear very soon.  

Well, not yet. :-)  I thought I'd update our patch against apt 0.5.9
before splitting, to save some of the inevitable work.

> It does not
> currently build a separate binary package, and introduces a libssl
> dependency in the binary package.  This would seem to be nontrivial to fix
> because both methods are in the same binary.  I think this happened in order
> to support redirects from http to https and that sort of thing.  

Correct.

> Presumably,
> this could be changed to use dlopen.

It certainly could, if it's important to keep the libssl dep separate
from apt proper.

Matt brought up licensing before.  If this is the main reason to
separate the https method out, then I would rather just port the SSL
portion of the patch to GNU TLS, which I can do in a jiffy.  If there
are other good reasons, though, I'm not opposed to dlopen().

> > SWIG: I never liked the idea of the SWIG markup in the code. Since Gustavo
> > has said that the SWIG authors will not accept the patch I'd drop it. It
> > also sounds like the python-apt painfully hand crafted bindings are
> > nicer..
> 
> I agree, though I wish I had time to keep the bindings up to date.

I have no experience with the SWIG bindings, but I have had lots of
recent experience with the hand-crafted ones, and I think they need some
enhancement (and certainly documentation).  We do lots of Python here at
Progeny, so this could become an issue fairly quickly.  If/when that
time comes, I'll ping you, and you can dump your Python tasklist on me
if you like.




Changed Bug title. Request was from Matt Zimmerman <mdz@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #93 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: 203741@bugs.debian.org, Colin Walters <walters@debian.org>, Isaac Jones <ijones@syntaxpolice.org>
Subject: apt-secure changes
Date: Sun, 7 Sep 2003 16:07:35 -0400
[Message part 1 (text/plain, inline)]
Attached are my current working diffs, one is relative to current APT CVS,
and the other is relative to the earlier apt-secure.patch from the BTS.

I implemented these changes:

- Removed the Vendor which was passed down through much of the acquire path

- Rather than configuring sources as secure or insecure, signature
  verification is now attempted on all sources, but if it fails, the package
  indexes are still downloaded.

- Release.gpg is only moved into Dir::State::Lists if the signature is
  successfully verified

- When installing packages, we check to find out whether any packages are
  queued to be retrieved from a source whose index has not been verified.
  If any are found, we warn the user and ask for confirmation.

At this point, everything seems to work the way that I want it to, with one
exception.  The vendor configuration is now inactive, and needs to be
tweaked a bit to get it back.  I plan to fix that shortly, but would
appreciate feedback on what I have done so far.

The only part I feel is a bit hackish is the confirmation stuff.  Because we
can only tell whether a package is to come from a secure source by passing
it through pkgAcquire, we need a mapping back to the package name from the
Acquire::Item.  I added an accessor which returns the ShortDesc, which, as
it happens, is the package name for archive downloads.  If there is a more
elegant way to do this, let me know.

-- 
 - mdz
[apt-secure+mdz.diff (text/plain, attachment)]
[apt-secure-vs-apt-secure+mdz.diff (text/plain, attachment)]
[Message part 4 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #98 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: 203741@bugs.debian.org, Colin Walters <walters@debian.org>, Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: apt-secure changes
Date: Sun, 7 Sep 2003 16:10:39 -0400
Oh, another thing.  The error/warning situation could probably use some
cleanup.  While at this point, someone who installs the new code on an
existing setup will continue to have a functional apt (with the addition of
the confirmation question), but they will get a bunch of warnings from
apt-get update as it tries to verify signatures and finds that it doesn't
have a keyring (or maybe even gnupg).

Suggestions would be appreciated.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #103 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: 203741@bugs.debian.org, Colin Walters <walters@debian.org>, Isaac Jones <ijones@syntaxpolice.org>
Subject: latest apt-secure diff
Date: Sun, 7 Sep 2003 22:38:01 -0400
[Message part 1 (text/plain, inline)]
I've commented out or removed a lot of the code which has been made
inactive.  I moved the vendors.list stuff out of pkgSourceList because it's
not coupled to sources.list anymore.  I moved it into a pkgVendorList class,
but currently it's not used for anything, so I'm debating whether it should
be included.

The only significant piece left to be done, I think, is to write
pkgAcqMetaIndex::VerifyVendor.  That's the hook for doing any validation of
the Release file beyond having a valid signature from a trusted key.  This
would allow different package policies for different trusted sources by
authenticating the non-checksum information in the Release file.

I'm not convinced that this is critical for the initial implementation.
Being able to separate trusted sources from untrusted sources gets us 99% of
the way there, I think.  The existing ExpectedDist check prevents the most
obvious types of spoofing attacks.

The attacks which remain are things like spoofing the current "stable" with
an older "stable", since we currently only authenticate origin, and not
identity.  I think the right approach to fixing this is to configure, in
vendors.list, what Release information is allowed to be supplied by each
vendor.  For example, the Debian 2002 key would only be able to declare
itself to be Version: 2.2*, while Debian 2003 would be able to identify
Version: 3.0*, and that sort of thing.

-- 
 - mdz
[apt-secure+mdz.diff (text/plain, attachment)]
[Message part 3 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Colin Walters <walters@verbum.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #108 received at 203741@bugs.debian.org (full text, mbox):

From: Colin Walters <walters@verbum.org>
To: Matt Zimmerman <mdz@debian.org>
Cc: 203741@bugs.debian.org, Isaac Jones <ijones@syntaxpolice.org>
Subject: apt-secure
Date: Mon, 08 Sep 2003 00:02:39 -0400
We got kicked off IRC due to crappy wireless at this coffee shop, so
here are our thoughts:

First of all, despite what we were saying initially on IRC, if you're
prompting before the packages are actually downloaded, then there are no
problems with polluting the cache, no?

The other issue about displaying which sources (in addition to which
packages) were insecure is probably less pressing.

So if there is no cache problem, this seems quite doable for sarge. 
Some responses to your previous emails:

On Sun, 2003-09-07 at 16:10, Matt Zimmerman wrote:
> Oh, another thing.  The error/warning situation could probably use some
> cleanup.  While at this point, someone who installs the new code on an
> existing setup will continue to have a functional apt (with the addition of
> the confirmation question), but they will get a bunch of warnings from
> apt-get update as it tries to verify signatures and finds that it doesn't
> have a keyring (or maybe even gnupg).

We should have apt Depend: on gnupg, and also ship a default keyring
with the Debian ftp keys, perhaps with a prompt for whether or not to
trust the keys.

On Sat, 2003-09-06 at 21:46, Matt Zimmerman wrote:
> A couple of other things.
> 
> - It looks like pkgAcqIndexRel isn't used anymore.  If this is correct, I
>   think we should remove it.

I think this is still used for semi-obscure pinning purposes.  We should
probably try to merge that back into the main Release file.


> - I'm torn about how to handle the situation where a Release file is
> signed,
>   but the public key isn't available.  On one hand, I don't want to
> issue a
>   warning all the time, because I think it will be a normal situation.

This doesn't seem like a very normal situation - if you don't trust the
source, then you don't trust the source, and you should see a warning.




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #113 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Colin Walters <walters@verbum.org>
Cc: 203741@bugs.debian.org, Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: apt-secure
Date: Mon, 8 Sep 2003 10:12:24 -0400
On Mon, Sep 08, 2003 at 12:02:39AM -0400, Colin Walters wrote:

> First of all, despite what we were saying initially on IRC, if you're
> prompting before the packages are actually downloaded, then there are no
> problems with polluting the cache, no?

The problem situation I was talking about is where someone downloads a
package, then changes their trust policy, then runs an upgrade/install.
Since the package is already downloaded, under the current setup I don't
think they get the warning.  Since the user should be able to change their
policy and have it take effect immediately, this should be fixed.  I'm
looking into the pkgDepCache changes now.

> The other issue about displaying which sources (in addition to which
> packages) were insecure is probably less pressing.

I am concerned about the potential length of that warning message, if it
includes the source.  There is no short, unique identifier for it currently.
If 100 packages are being installed and the source name is displayed, I
think the message would end up being 100 lines long.  Since it currently
displays only the package name, it takes advantage of the existing code to
provide a nicely formatted list which is not too large.

The problem situation you're describing, if I understand correctly, is where
the user has an insecure source that they want packages from regularly, and
have another insecure source which they do not want packages from regularly,
and should be able to see at a glance that packages are coming from the
unexpected insecure source rather than the expected one.

If so, I agree that this is minor, as any source being used for regular
regular upgrades should probably be secured.

Which reminds me; we need to whip up some tools to make this easy.  How is
this done for the Debian archive?  Maybe we can borrow those tools, or use
them for comparison.

> On Sun, 2003-09-07 at 16:10, Matt Zimmerman wrote:
> > Oh, another thing.  The error/warning situation could probably use some
> > cleanup.  While at this point, someone who installs the new code on an
> > existing setup will continue to have a functional apt (with the addition of
> > the confirmation question), but they will get a bunch of warnings from
> > apt-get update as it tries to verify signatures and finds that it doesn't
> > have a keyring (or maybe even gnupg).
> 
> We should have apt Depend: on gnupg, and also ship a default keyring
> with the Debian ftp keys, perhaps with a prompt for whether or not to
> trust the keys.

I'm wary of a Depends: on gnupg, since apt is fully functional without it.
We should definitely ship some keys by default, but if we ship them in the
form of a gnupg keyring, rather than exported keys, I think we can avoid the
dependency and just copy the keyring into place (assuming that gnupg
keyrings are reasonably portable across versions).

> > - It looks like pkgAcqIndexRel isn't used anymore.  If this is correct, I
> >   think we should remove it.
> 
> I think this is still used for semi-obscure pinning purposes.  We should
> probably try to merge that back into the main Release file.

In current apt CVS, it is only used in debindexfile.cc to fetch the Release
file.  Since the the metaindex stuff does that now, it's obsolete and I
think it should be removed.

One thing that pkgAcqIndexRel does that pkgAcqMetaIndex doesn't do is the
Custom600Headers bit, which I think definitely should be added to
pkgAcqMetaIndex  (unless you intentionally wanted it to be fetched every
time).

> > - I'm torn about how to handle the situation where a Release file is
> > signed, but the public key isn't available.  On one hand, I don't want
> > to issue a warning all the time, because I think it will be a normal
> > situation.
> 
> This doesn't seem like a very normal situation - if you don't trust the
> source, then you don't trust the source, and you should see a warning.

I think the warning during update is superfluous because the user will be
asked for confirmation when installing packages.  I might add a source to my
sources.list that I don't generally trust, knowing that apt will ask for
confirmation before installing packages from it.  However, I would still get
a warning on every single apt-get update.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #118 received at 203741@bugs.debian.org (full text, mbox):

From: Adam Heath <doogie@debian.org>
To: Matt Zimmerman <mdz@debian.org>, <203741@bugs.debian.org>
Cc: Colin Walters <walters@verbum.org>, Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: Bug#203741: apt-secure
Date: Mon, 8 Sep 2003 12:49:33 -0500 (CDT)
On Mon, 8 Sep 2003, Matt Zimmerman wrote:

> I'm wary of a Depends: on gnupg, since apt is fully functional without it.
> We should definitely ship some keys by default, but if we ship them in the
> form of a gnupg keyring, rather than exported keys, I think we can avoid the
> dependency and just copy the keyring into place (assuming that gnupg
> keyrings are reasonably portable across versions).

Jason said years ago that he was going to add dlopen support to apt.  He never
did.  If apt could suddenly load external modules, then apt-secure could be a
separate deb, that depended on gpg, and debian-keyring.




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #123 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Adam Heath <doogie@debian.org>
Cc: 203741@bugs.debian.org, Colin Walters <walters@verbum.org>, Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: Bug#203741: apt-secure
Date: Mon, 8 Sep 2003 13:54:08 -0400
On Mon, Sep 08, 2003 at 12:49:33PM -0500, Adam Heath wrote:

> On Mon, 8 Sep 2003, Matt Zimmerman wrote:
> 
> > I'm wary of a Depends: on gnupg, since apt is fully functional without it.
> > We should definitely ship some keys by default, but if we ship them in the
> > form of a gnupg keyring, rather than exported keys, I think we can avoid the
> > dependency and just copy the keyring into place (assuming that gnupg
> > keyrings are reasonably portable across versions).
> 
> Jason said years ago that he was going to add dlopen support to apt.  He never
> did.  If apt could suddenly load external modules, then apt-secure could be a
> separate deb, that depended on gpg, and debian-keyring.

The only part which actually invokes gpg is the gpgv method, which is
already in a separate binary from the rest of apt.  The trouble is that if
they don't have it installed, apt would not be able to verify any signatures
and would complain every time a package is to be installed.  Maybe it should
not even try to verify anything if it finds that gpg is not installed?

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Jason Gunthorpe <jgg@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #128 received at 203741@bugs.debian.org (full text, mbox):

From: Jason Gunthorpe <jgg@debian.org>
To: Matt Zimmerman <mdz@debian.org>, 203741@bugs.debian.org
Cc: Colin Walters <walters@verbum.org>, Isaac Jones <ijones@syntaxpolice.org>, debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>
Subject: Re: Bug#203741: apt-secure
Date: Mon, 08 Sep 2003 16:02:46 -0600 (MDT)
On Mon, 8 Sep 2003, Matt Zimmerman wrote:

> I think the warning during update is superfluous because the user will be
> asked for confirmation when installing packages.  I might add a source to my
> sources.list that I don't generally trust, knowing that apt will ask for
> confirmation before installing packages from it.  However, I would still get
> a warning on every single apt-get update.

Any sort of query during install isn't going to work so well without much
bigger changes. Mostly this has to do with the way multiple instances of
the same package are handled, the various origins are not uniquified and
it cannot retain the md5sum information to figure out what makes sense. 

So even though it says it's coming from a secure source because one
instance is listed as secure it may very well decide to download and
verify it from an insecure one. I haven't the faintest clue about how
you'd go about fixing this.

Basically you have to sign off at update time and you need to ensure your
sources.list has what you want then.

Jason




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #133 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Jason Gunthorpe <jgg@debian.org>
Cc: 203741@bugs.debian.org, Colin Walters <walters@verbum.org>, Isaac Jones <ijones@syntaxpolice.org>, debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>
Subject: Re: Bug#203741: apt-secure
Date: Mon, 8 Sep 2003 18:20:32 -0400
On Mon, Sep 08, 2003 at 04:02:46PM -0600, Jason Gunthorpe wrote:

> Any sort of query during install isn't going to work so well without much
> bigger changes. Mostly this has to do with the way multiple instances of
> the same package are handled, the various origins are not uniquified and
> it cannot retain the md5sum information to figure out what makes sense. 
> 
> So even though it says it's coming from a secure source because one
> instance is listed as secure it may very well decide to download and
> verify it from an insecure one. I haven't the faintest clue about how
> you'd go about fixing this.

Hmm...where in the code does this magic happen?  I suppose it could be
changed to consider a package to be coming from an insecure source if any of
the available origins are insecure, and sidestep the problem that way.  I
don't think this will be much a problem in practice, since sources having
the same packages available will typically also have the same Release, same
signature, etc.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #138 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Jason Gunthorpe <jgg@debian.org>
Cc: 203741@bugs.debian.org, Colin Walters <walters@verbum.org>, Isaac Jones <ijones@syntaxpolice.org>, debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>
Subject: Re: Bug#203741: apt-secure
Date: Mon, 8 Sep 2003 19:15:18 -0400
On Mon, Sep 08, 2003 at 04:02:46PM -0600, Jason Gunthorpe wrote:

> Any sort of query during install isn't going to work so well without much
> bigger changes. Mostly this has to do with the way multiple instances of
> the same package are handled, the various origins are not uniquified and
> it cannot retain the md5sum information to figure out what makes sense. 

Hmm, wait, I may have misunderstood here.  Does this mean that if two
packages will be considered equivalent even if their md5sums are different?
If so, that is a serious problem for any implementation, prompting or no, is
it not?

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Jason Gunthorpe <jgg@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #143 received at 203741@bugs.debian.org (full text, mbox):

From: Jason Gunthorpe <jgg@debian.org>
To: Matt Zimmerman <mdz@debian.org>
Cc: 203741@bugs.debian.org, Colin Walters <walters@verbum.org>, Isaac Jones <ijones@syntaxpolice.org>, debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>
Subject: Re: Bug#203741: apt-secure
Date: Mon, 08 Sep 2003 20:41:48 -0600 (MDT)
On Mon, 8 Sep 2003, Matt Zimmerman wrote:

> > Any sort of query during install isn't going to work so well without much
> > bigger changes. Mostly this has to do with the way multiple instances of
> > the same package are handled, the various origins are not uniquified and
> > it cannot retain the md5sum information to figure out what makes sense. 
> 
> Hmm, wait, I may have misunderstood here.  Does this mean that if two
> packages will be considered equivalent even if their md5sums are different?
> If so, that is a serious problem for any implementation, prompting or no, is
> it not?

That is correct. It is not a serious problem in practice because packages
with the same version number are generally going to be the same.

However when dealing with security issues you can't just gloss over a
problem like that, that's why I said I don't know how you'd fix it. I
don't think you can fix it without changing dpkg to retain the md5sum in
the status file, and even if you do that ideas like debsums break it..

This is also why you sign off on the security at update time, because even
a single insecure or rough site can have very interesting effects on the
meta data within the cache. The retry algorithms are just one interesting
effect that's possible..

Jason




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #148 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Jason Gunthorpe <jgg@debian.org>
Cc: 203741@bugs.debian.org, Colin Walters <walters@verbum.org>, Isaac Jones <ijones@syntaxpolice.org>, debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>
Subject: Re: Bug#203741: apt-secure
Date: Tue, 9 Sep 2003 00:38:15 -0400
On Mon, Sep 08, 2003 at 08:41:48PM -0600, Jason Gunthorpe wrote:

> That is correct. It is not a serious problem in practice because packages
> with the same version number are generally going to be the same.
> 
> However when dealing with security issues you can't just gloss over a
> problem like that, that's why I said I don't know how you'd fix it. I
> don't think you can fix it without changing dpkg to retain the md5sum in
> the status file, and even if you do that ideas like debsums break it..
> 
> This is also why you sign off on the security at update time, because even
> a single insecure or rough site can have very interesting effects on the
> meta data within the cache. The retry algorithms are just one interesting
> effect that's possible..

Argh, this is a show-stopper I think.  So there's no real security unless
every one of your sources is authenticated.  The whole system is only as
strong as the weakest link, and if you have any insecure source, it
compromises all of your available packages.  That's the reasoning behind the
confirmation prompt.  But if it's impossible to tell reliably where a
package comes from, I don't see how it can work.

These days, systems with unofficial sources in sources.list seem to be more
common than those without.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Isaac Jones <ijones@syntaxpolice.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #153 received at 203741@bugs.debian.org (full text, mbox):

From: Isaac Jones <ijones@syntaxpolice.org>
To: Jason Gunthorpe <jgg@debian.org>
Cc: 203741@bugs.debian.org, Colin Walters <walters@verbum.org>, debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>
Subject: Re: Bug#203741: apt-secure
Date: Tue, 09 Sep 2003 01:13:19 -0400
Matt Zimmerman <mdz@debian.org> writes:

> Argh, this is a show-stopper I think.  

I disagree.  It would still be good to offer the users the _ability_
to use only secure sources (for sensitive systems, for instance).
Also, including the security features will allow users to start
transitioning to all secure sources, and give packages distributers
incentive to secure their own sources (especially if apt complains a
bit).  We can make this less painful by adding features to tools like
mini-dinstall.

> So there's no real security unless every one of your sources is
> authenticated.

This has always been the case.  Any package can do anything to your
system.

> These days, systems with unofficial sources in sources.list seem to be more
> common than those without.

There's nothing that says only official sources can be secure :)


peace,

isaac



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #158 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Isaac Jones <ijones@syntaxpolice.org>, 203741@bugs.debian.org
Cc: Jason Gunthorpe <jgg@debian.org>, Colin Walters <walters@verbum.org>
Subject: Re: Bug#203741: apt-secure
Date: Tue, 9 Sep 2003 09:34:17 -0400
On Tue, Sep 09, 2003 at 01:13:19AM -0400, Isaac Jones wrote:

> Matt Zimmerman <mdz@debian.org> writes:
> 
> > Argh, this is a show-stopper I think.  
> 
> I disagree.  It would still be good to offer the users the _ability_ to
> use only secure sources (for sensitive systems, for instance).  Also,
> including the security features will allow users to start transitioning to
> all secure sources, and give packages distributers incentive to secure
> their own sources (especially if apt complains a bit).  We can make this
> less painful by adding features to tools like mini-dinstall.

I don't think it's particularly valid for apt to complain unless it can
actually distinguish whether it is installing packages from insecure sources
(which it cannot).  If a warning is given when things are obviously
insecure, users will take the lack of a warning to be a blessing.

> > So there's no real security unless every one of your sources is
> > authenticated.
> 
> This has always been the case.  Any package can do anything to your
> system.

Having a prompt lets you have an insecure source in sources.list without
allowing it to sneak in a new version of a package that is currently
installed from a secure source.  It means that you can run "apt-get install
foo" and know that you will not get an untrusted version of foo unless you
explicitly sign off on it.  It also means that if you find yourself about to
install an untrusted package, you can do whatever is necessary in order to
authenticate or audit the package before installing it.

I think it provides a much smoother and safer upgrade path for existing
users, most of which will have insecure sources.  Their official Debian
sources are automatically authenticated, and they are warned about
everything else.

> > These days, systems with unofficial sources in sources.list seem to be
> > more common than those without.
> 
> There's nothing that says only official sources can be secure :)

See above; they have no particular incentive to become secure unless apt
places roadblocks in front of untrusted packages, and if it does that
without being able to differentiate accurately, it leads to a dangerous
false sense of security.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Jason Gunthorpe <jgg@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #163 received at 203741@bugs.debian.org (full text, mbox):

From: Jason Gunthorpe <jgg@debian.org>
To: Matt Zimmerman <mdz@debian.org>
Cc: 203741@bugs.debian.org, Colin Walters <walters@verbum.org>, Isaac Jones <ijones@syntaxpolice.org>, debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>
Subject: Re: Bug#203741: apt-secure
Date: Tue, 09 Sep 2003 11:07:01 -0600 (MDT)
On Tue, 9 Sep 2003, Matt Zimmerman wrote:

> > This is also why you sign off on the security at update time, because even
> > a single insecure or rough site can have very interesting effects on the
> > meta data within the cache. The retry algorithms are just one interesting
> > effect that's possible..
 
> Argh, this is a show-stopper I think.  So there's no real security unless
> every one of your sources is authenticated.  The whole system is only as
> strong as the weakest link, and if you have any insecure source, it
> compromises all of your available packages.  That's the reasoning behind the
> confirmation prompt.  But if it's impossible to tell reliably where a
> package comes from, I don't see how it can work.

APT can't sandbox things based on origin, which is the problem here.

The user is ultimately responsible for ensuring that their sources.list
contains sites they trust. The authentication mechanism is _only_ to
secure the network/mirrors - nothing more. Think of it as you think of
SSL/TLS. The problem we are trying to solve is to prevent man in the
middle and rouge mirrors from doing nasty things. 

Even if I put in some random unoffical url that's signed I _still_ need to
be wary about the content! 

Jason




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Adam Heath <doogie@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #168 received at 203741@bugs.debian.org (full text, mbox):

From: Adam Heath <doogie@debian.org>
To: 203741@bugs.debian.org
Subject: Re: Bug#203741: apt-secure
Date: Tue, 9 Sep 2003 15:29:42 -0500 (CDT)
On Mon, 8 Sep 2003, Jason Gunthorpe wrote:

> However when dealing with security issues you can't just gloss over a
> problem like that, that's why I said I don't know how you'd fix it. I
> don't think you can fix it without changing dpkg to retain the md5sum in
> the status file, and even if you do that ideas like debsums break it..

I am open to discussion on changing dpkg to store more information.




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Isaac Jones <ijones@syntaxpolice.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #173 received at 203741@bugs.debian.org (full text, mbox):

From: Isaac Jones <ijones@syntaxpolice.org>
To: Matt Zimmerman <mdz@debian.org>
Cc: 203741@bugs.debian.org, Jason Gunthorpe <jgg@debian.org>, Colin Walters <walters@verbum.org>
Subject: Re: Bug#203741: apt-secure
Date: Wed, 10 Sep 2003 22:39:41 -0400
Matt Zimmerman <mdz@debian.org> writes:

> I don't think it's particularly valid for apt to complain unless it can
> actually distinguish whether it is installing packages from insecure sources
> (which it cannot).  If a warning is given when things are obviously
> insecure, users will take the lack of a warning to be a blessing.

So apt knows about insecure sources and can warn the user about that.
I'm not sure how strongly you meant the "show stopper" comment, but I
think it is far more desirable to give a transition path toward all
secure sources in the next release than to punt until we work out dpkg
issues.  There are still lots of options open for the user interface
(see below).

> I think it provides a much smoother and safer upgrade path for existing
> users, most of which will have insecure sources.  Their official Debian
> sources are automatically authenticated, and they are warned about
> everything else.

I agree that what you wanted was better.  I'm only arguing that not
having this is not, in fact, a show stopper.  The user can still have
secure sources, and people who care will put pressure on the
maintainers of the unofficial sources to secure them.  Thats what
they've been doing to us :)

> See above; they have no particular incentive to become secure unless apt
> places roadblocks in front of untrusted packages, 

Or in front of untrusted sources :)

> and if it does that without being able to differentiate accurately,
> it leads to a dangerous false sense of security.

We can definitely get around that.  My suggestion would be that in
this release (if you feel that we don't have time to change dpkg to
allow your interface), we:

* default to allowing insecure sources unless the user passes a flag
to disallow it, and

* sometime soon, we default to disallowing insecure sources unless the
user passes a flag to allow it.

Both flags will be available in the first release.  This should keep
everyone happy.  People who want only secure sources can have real
security (by passing the flag), the default behavior won't change for
the first release, which gives users time to update any scripts, and
the plan to change the default will give source administrators time
(and insentive!) to update their sources before they become broken.

I would even be a fan of defaulting to disallow insecure sources in
this release by default, but I suspect that would piss people off.

peace,

isaac



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #178 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Isaac Jones <ijones@syntaxpolice.org>
Cc: 203741@bugs.debian.org, Jason Gunthorpe <jgg@debian.org>, Colin Walters <walters@verbum.org>
Subject: Re: Bug#203741: apt-secure
Date: Wed, 10 Sep 2003 23:29:50 -0400
On Wed, Sep 10, 2003 at 10:39:41PM -0400, Isaac Jones wrote:

> Matt Zimmerman <mdz@debian.org> writes:
> 
> > I don't think it's particularly valid for apt to complain unless it can
> > actually distinguish whether it is installing packages from insecure
> > sources (which it cannot).  If a warning is given when things are
> > obviously insecure, users will take the lack of a warning to be a
> > blessing.
> 
> So apt knows about insecure sources and can warn the user about that.  I'm
> not sure how strongly you meant the "show stopper" comment, but I think it
> is far more desirable to give a transition path toward all secure sources
> in the next release than to punt until we work out dpkg issues.  There are
> still lots of options open for the user interface (see below).

apt can only warn at update time about insecure sources.  If a single
insecure source is present, it causes all sorts of problems:

 - any package requested by the user for installation or upgrade could come
   from an untrusted source without warning

 - the user gets accustomed to seeing the warning on every update, and could
   easily miss a new warning about a supposedly secure source

> > See above; they have no particular incentive to become secure unless apt
> > places roadblocks in front of untrusted packages, 
> 
> Or in front of untrusted sources :)

What do you have in mind?  Complaining every time the user runs apt-get
update would only serve to numb their response to the error messages (that's
the effect it would have on me, anyway).

> We can definitely get around that.  My suggestion would be that in
> this release (if you feel that we don't have time to change dpkg to
> allow your interface), we:
> 
> * default to allowing insecure sources unless the user passes a flag
> to disallow it, and
> 
> * sometime soon, we default to disallowing insecure sources unless the
> user passes a flag to allow it.
> 
> Both flags will be available in the first release.  This should keep
> everyone happy.  People who want only secure sources can have real
> security (by passing the flag), the default behavior won't change for
> the first release, which gives users time to update any scripts, and
> the plan to change the default will give source administrators time
> (and insentive!) to update their sources before they become broken.
> 
> I would even be a fan of defaulting to disallow insecure sources in
> this release by default, but I suspect that would piss people off.

I don't think we can even think about defaulting to rejecting insecure
sources until we've provided some simple tools for importing keys into the
trusted keyring and generating Release files.  The latter sounds like an
extension to apt-ftparchive.  I'm not sure what the former should look like.
A wrapper around gpg --import/--recv-keys?

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Isaac Jones <ijones@syntaxpolice.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #183 received at 203741@bugs.debian.org (full text, mbox):

From: Isaac Jones <ijones@syntaxpolice.org>
To: Matt Zimmerman <mdz@debian.org>
Subject: Re: Bug#203741: apt-secure
Date: Mon, 22 Sep 2003 11:16:03 -0400
Matt Zimmerman <mdz@debian.org> writes:

> What is the migration path that you are suggesting?  That we check
> signatures where they are available, and where they are not, warn the user
> during apt-get update?  I suppose this is better than nothing.

I think we should give the user an option to disallow insecure
sources --secure-only, so update fails on insecure sources.  This is
good for people with sensitive systems.  People will be excited about
the feature and they _will_ start securing their sources, especially
if we promise that this will someday be the default.

We should also give the user an option to allow insecure sources,
which would be the default --ignore-insecure.

The logic behind the flag names is that right now we're checking
sources, maybe in the future, we'll be able to check packages (that's
why the flag isn't --secure-sources-only).  No promise to the end user
about how it's done, but apt basically has a secure mode and a
insecure mode.

Whether or not to warn the user during update if they are in "insecure
mode" is up to you.  I think thats a good idea, and it'll help bring
attention to the new security features.  The important part, IMHO, is
to give users the ability to secure their machines if they want, and
to give source maintainers ample warning that security is coming and
they should jump on the bandwagon.

I feel that the combination of SELinux with "apt-secure" will make a
damn secure system, and would be very valuable in Sarge.  I think that
there are people who will switch to Debian for this feature.

peace,

isaac



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #188 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: Bug#203741: apt-secure
Date: Mon, 22 Sep 2003 12:03:41 -0400
On Mon, Sep 22, 2003 at 11:16:03AM -0400, Isaac Jones wrote:

> Matt Zimmerman <mdz@debian.org> writes:
> 
> > What is the migration path that you are suggesting?  That we check
> > signatures where they are available, and where they are not, warn the user
> > during apt-get update?  I suppose this is better than nothing.
> 
> I think we should give the user an option to disallow insecure
> sources --secure-only, so update fails on insecure sources.  This is
> good for people with sensitive systems.  People will be excited about
> the feature and they _will_ start securing their sources, especially
> if we promise that this will someday be the default.

Mind if I start CCing things to the BTS?  I'd like to keep a record of the
discussion and keep others in the loop.

> We should also give the user an option to allow insecure sources,
> which would be the default --ignore-insecure.
> 
> The logic behind the flag names is that right now we're checking
> sources, maybe in the future, we'll be able to check packages (that's
> why the flag isn't --secure-sources-only).  No promise to the end user
> about how it's done, but apt basically has a secure mode and a
> insecure mode.
>
> Whether or not to warn the user during update if they are in "insecure
> mode" is up to you.  I think thats a good idea, and it'll help bring
> attention to the new security features.  The important part, IMHO, is to
> give users the ability to secure their machines if they want, and to give
> source maintainers ample warning that security is coming and they should
> jump on the bandwagon.

I guess this is reasonable...have a "require verification" config option or
such, and if it is true, verification errors will be fatal, and if it is
false, verification errors will be warnings.

I definitely feel that this is very valuable, but according the release
schedule that AJ set forth, changes to major packages like apt should
already be done by now in order for things to go forward. :-/

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #193 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: Bug#203741: apt-secure
Date: Mon, 22 Sep 2003 10:38:22 -0400
On Mon, Sep 22, 2003 at 10:05:45AM -0400, Isaac Jones wrote:

> > I don't think we can even think about defaulting to rejecting insecure
> > sources until we've provided some simple tools for importing keys into the
> > trusted keyring and generating Release files.  
> 
> (Rest of email is below.)
> 
> Like I said, I'm not actually advocating that, but the migration path
> is still a good idea for this release.

What is the migration path that you are suggesting?  That we check
signatures where they are available, and where they are not, warn the user
during apt-get update?  I suppose this is better than nothing.

> I'm just writing to ask what your plan is.  Can I help with anything?

My current plan is to get apt > 0.5.4 into testing.  I don't want to start
breaking things until there is something pretty solid for sarge.
Unfortunately, glibc and gcc-3.3 happened, and so that has held everything
up.  apt also just had an RC bug reported which I need to fix. :-/

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #198 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: 203741@bugs.debian.org
Cc: debian-release@lists.debian.org
Subject: Signature verification status
Date: Mon, 22 Sep 2003 19:07:23 -0400
Given that:

1. I feel it is important that we have an updated apt in sarge, with or
without signature verification.  There have been many important fixes.

2. apt in sarge is currently still at 0.5.4 from woody

3. gcc-3.3 is still blocking a new apt from entering sarge

4. I think it would be a grave error to introduce this level of potential
breakage at this point in the release schedule

I am afraid that these changes may not make it into sarge.  If the release
is delayed for other reasons, it may become possible, but I would rather
release in December without signature checking than in March with it.  I'm
open to input from release-type folks about this, and so CCing
debian-release.

There still remain these outstanding issues, as well:

- What to do about notifying the user about insecure sources

  - A perpetual warning when any insecure source is present will numb the
    user to such warnings

  - An error would prevent users from taking advantage of unofficial sources

  Isaac suggested a configuration option to reject insecure sources, and I
  think that is probably a good compromise.  What should this configuration
  option be called?  Acquire::Require-Signed?

- Tools for generating Release files and signatures

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Isaac Jones <ijones@syntaxpolice.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #203 received at 203741@bugs.debian.org (full text, mbox):

From: Isaac Jones <ijones@syntaxpolice.org>
To: Matt Zimmerman <mdz@debian.org>
Subject: Re: Bug#203741: apt-secure
Date: Mon, 22 Sep 2003 13:13:36 -0400
Matt Zimmerman <mdz@debian.org> writes:

> Mind if I start CCing things to the BTS?  I'd like to keep a record of the
> discussion and keep others in the loop.

Not at all. I emailed you personally because my first mail wasn't
really adding anything to the discussion.

> I guess this is reasonable...have a "require verification" config option or
> such, and if it is true, verification errors will be fatal, and if it is
> false, verification errors will be warnings.

Sounds good.

> I definitely feel that this is very valuable, but according the release
> schedule that AJ set forth, changes to major packages like apt should
> already be done by now in order for things to go forward. :-/

Hm. Maybe he'll be flexible.  The major value is in the transition
path which should start ASAP.

peace,

isaac



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #208 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: 203741@bugs.debian.org, Isaac Jones <ijones@syntaxpolice.org>
Subject: Re: Bug#203741: apt-secure
Date: Tue, 23 Sep 2003 01:09:04 -0400
(Isaac, I'm CCing you because I'm not sure if you're on -deity...are you?)

Another thing I remembered which bugs me about the current stuff...it
doesn't do IMS requests for Release or Release.gpg.  If I pass a
last-modified header to the method, it blows up in my face by deleting the
Packages files and not fetching them again.  I assume the problem is with
the list-cleanup stuff or something.

Anyway, it would be nice if it did this, since the current code does IMS for
everything.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Michael Vogt <mvogt@acm.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #213 received at 203741@bugs.debian.org (full text, mbox):

From: Michael Vogt <mvogt@acm.org>
To: Matt Zimmerman <mdz@debian.org>, 203741@bugs.debian.org
Subject: Re: Bug#203741: Signature verification status
Date: Tue, 23 Sep 2003 15:39:46 +0200
On Mon, Sep 22, 2003 at 07:07:23PM -0400, Matt Zimmerman wrote:
[..]
> I am afraid that these changes may not make it into sarge.  If the release
> is delayed for other reasons, it may become possible, but I would rather
> release in December without signature checking than in March with it.  I'm
> open to input from release-type folks about this, and so CCing
> debian-release.
> 
> There still remain these outstanding issues, as well:
> 
> - What to do about notifying the user about insecure sources
> 
>   - A perpetual warning when any insecure source is present will numb the
>     user to such warnings
> 
>   - An error would prevent users from taking advantage of unofficial sources
> 
>   Isaac suggested a configuration option to reject insecure sources, and I
>   think that is probably a good compromise.  What should this configuration
>   option be called?  Acquire::Require-Signed?
> 
> - Tools for generating Release files and signatures

I have not follwed the discussion closly, but I would like to
encourage you to stay as close as possible with the apt-rpm
solution. This help tools like synaptic (which I maintain) to be able
to work with both versions of apt. Synaptic already supports the
siging stuff that apt-rpm provides. 

I would also love to be able to test the signing stuff early to ensure
that synaptic will not break. 

thanks for your good work on apt!
 Michael
 



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #218 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Michael Vogt <mvogt@acm.org>
Cc: 203741@bugs.debian.org
Subject: Re: Bug#203741: Signature verification status
Date: Tue, 23 Sep 2003 15:58:10 -0400
On Tue, Sep 23, 2003 at 03:39:46PM +0200, Michael Vogt wrote:

> I have not follwed the discussion closly, but I would like to encourage
> you to stay as close as possible with the apt-rpm solution. This help
> tools like synaptic (which I maintain) to be able to work with both
> versions of apt. Synaptic already supports the siging stuff that apt-rpm
> provides. 
> 
> I would also love to be able to test the signing stuff early to ensure
> that synaptic will not break. 

In what way is it different?  It doesn't seem that a frontend like synaptic
should need to worry about this kind of thing; the signatures are verified
when the package lists are downloaded, and after that it should be
transparent (so far).

If their Release files are different or something (or they verify packages
rather than releases), then the solutions are fundamentally different
(though perhaps not incompatible).

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #223 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: 203741@bugs.debian.org
Subject: Current diff
Date: Wed, 24 Sep 2003 00:50:29 -0400
[Message part 1 (text/plain, inline)]
I added a keyring, changed one of the error messages to tell the user to
install gnupg if it can't exec it, and removed pkgAcqIndexRel.

-- 
 - mdz
[apt-secure.diff.gz (application/octet-stream, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #228 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: 207400@bugs.debian.org, 213465@bugs.debian.org, 203741@bugs.debian.org, 222668@bugs.debian.org, 221528@bugs.debian.org, 213311@bugs.debian.org, 218037@bugs.debian.org, 221728@bugs.debian.org
Subject: APT status
Date: Wed, 17 Dec 2003 18:33:04 -0800
Some of these bugs are fixed in CVS already, and others are on my todo list
for the near future.  I am back from my "vacation", and will try to set
aside some time to do apt work once the CVS repository is restored on
cvs.debian.org.  I have verified its contents and sent a message to
debian-admin asking for it to be restored.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #233 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: 203741@bugs.debian.org
Subject: v0_6 branch
Date: Thu, 25 Dec 2003 12:05:07 -0800
I've created a v0_6 branch in CVS and merged the current edition of the
signature verification code into it.

  * Signature verification support patch ("apt-secure") from Colin Walters
    <walters@debian.org> and Isaac Jones <ijones@syntaxpolice.org>.  This
    implements:
     - Release signature verification (Release.gpg)
     - Packages, Sources md5sum verification against Release
     - Closes: #203741
  * Make some modifications to signature verification support:
    - Release.gpg is always retrieved and verified if present, rather than
      requiring that sources be configured as secure
    - Print a hint about installing gnupg if exec(gpgv) fails
    - Remove obsolete pkgAcqIndexRel
    - Move vendors.list stuff into a separate module (vendorlist.{h,cc})
    - If any files about to be retrieved are not authenticated, issue a
      warning to the user and require confirmation
  * Suggests: gnupg
  * Install a keyring in /usr/share/apt/debian-archive.gpg containing an
    initial set of Debian archive signing keys to seed /etc/apt/trusted.gpg
  * Add a new tool, apt-key(8) used to manage the keyring

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #238 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Colin Walters <walters@debian.org>
Cc: Isaac Jones <ijones@syntaxpolice.org>, 203741@bugs.debian.org
Subject: Re: apt sigcheck patches
Date: Fri, 26 Dec 2003 08:26:19 -0800
On Thu, Aug 21, 2003 at 09:01:29PM -0400, Matt Zimmerman wrote:
> On a system running apt CVS + this patch, I get a number of reproducible
> segfaults.  For example, after "apt-get source" and "apt-get install".
> 
> #0  0x401ff136 in mallopt () from /lib/libc.so.6
> #1  0x401ff050 in mallopt () from /lib/libc.so.6
> #2  0x401fde67 in free () from /lib/libc.so.6
> #3  0x4013e261 in operator delete(void*) () from /usr/lib/libstdc++.so.5
> #4  0x4013e2bc in operator delete[](void*) () from /usr/lib/libstdc++.so.5
> #5  0x4004e09b in ~pkgTagFile (this=0x80aeb70) at tagfile.cc:58
> #6  0x40083bec in ~debRecordParser (this=0x8092770) at basic_string.h:217
> #7  0x40055589 in ~pkgRecords (this=0xbffff340) at pkgrecords.cc:55
> #8  0x08058c6b in DoSource(CommandLine&) (CmdL=@0x41181940) at apt-get.cc:747
> #9  0x4003cea4 in CommandLine::DispatchArg(CommandLine::Dispatch*, bool) (
>     this=0xbffff480, Map=0xbffff490, NoMatch=true) at contrib/cmndline.cc:340
> #10 0x0805bb27 in main (argc=3, argv=0xbffff7d4) at apt-get.cc:2423
> 
> It doesn't crash in any new code, but another apt built with the same
> compiler, without the sigcheck patch, doesn't have this problem.  Maybe
> there is some heap corruption happening somewhere?

I found this bug; it was here (srcrecords.cc):

/* Open all the source index files */
pkgSrcRecords::pkgSrcRecords(pkgSourceList &List) : Files(0), Current(0)
{
   Files = new Parser *[List.end() - List.begin() + 1];
   memset(Files,0,sizeof(*Files)*(List.end() - List.begin() + 1));
   
   unsigned int Count = 0;
   pkgSourceList::const_iterator I = List.begin();
   for (; I != List.end(); I++)
   {
      vector<pkgIndexFile *> *Indexes = (*I)->GetIndexFiles();
      for (vector<pkgIndexFile *>::const_iterator J = Indexes->begin();
           J != Indexes->end(); J++)
      {
         Files[Count] = (*J)->CreateSrcParser();
         if (_error->PendingError() == true)
            return;
         if (Files[Count] != 0)
            Count++;
      }
   }
   Files[Count] = 0;

Notice that Files is initialized to be the same size as List, but for each
element in List there can be multiple elements inserted into Files.  I
changed it to be a vector.

-- 
 - mdz



Tags added: fixed-in-experimental Request was from Matt Zimmerman <mdz@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Colin Walters <walters@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #245 received at 203741@bugs.debian.org (full text, mbox):

From: Colin Walters <walters@debian.org>
To: Matt Zimmerman <mdz@debian.org>
Cc: Isaac Jones <ijones@syntaxpolice.org>, 203741@bugs.debian.org
Subject: Re: apt sigcheck patches
Date: Sun, 28 Dec 2003 16:53:53 -0500
[Message part 1 (text/plain, inline)]
On Fri, 2003-12-26 at 11:26, Matt Zimmerman wrote:

> I found this bug; it was here (srcrecords.cc):
[...]

Ah, good catch.  My C++-fu is weak.  I had tried valgrind, but it only
gave me an error much later.

Thanks for integrating the patch!

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #250 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Colin Walters <walters@debian.org>
Cc: Isaac Jones <ijones@syntaxpolice.org>, 203741@bugs.debian.org
Subject: Re: apt sigcheck patches
Date: Sun, 28 Dec 2003 16:10:29 -0800
On Sun, Dec 28, 2003 at 03:37:44PM -0800, Matt Zimmerman wrote:

> On Sun, Dec 28, 2003 at 06:00:05PM -0500, Colin Walters wrote:
> 
> > On Sun, 2003-12-28 at 17:11, Matt Zimmerman wrote:
> > 
> > > Was the intention to move away from per-section Release files, and to only
> > > use the top-level one?  Or was this an oversight, and we should be
> > > downloading these files and continuing to use them?
> > 
> > I think our thought was that the per-section Release files should go
> > away in favor the main Release file; they don't actually contain any
> > more information, right?
> 
> Correct, they do not contain any more information.  The only feature that
> would be lost is the ability to set different parameters (codename,
> notautomatic, etc.) for the various sections of an archive.  I don't think
> that anyone is doing this, and it doesn't seem worth the extra complexity.
> 
> One other small difference is that the main Release file uses "Suite" rather
> than "Archive".  I'm inclined to just change the code to look for Suite,
> since it seems to match other terminology better.

Done in 0.6.4 (experimental).

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #255 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: debian-devel@lists.debian.org
Cc: 203741@bugs.debian.org
Subject: Re: apt 0.6 in experimental
Date: Sun, 28 Dec 2003 14:28:18 -0800
On Sun, Dec 28, 2003 at 01:18:22PM -0800, Matt Zimmerman wrote:

> On Sun, Dec 28, 2003 at 01:32:47PM -0500, Joey Hess wrote:
> 
> > With apt 0.6.1, I have this in sources.list:
> > 
> > deb http://http.us.debian.org/debian/ ../project/experimental main contrib non-free
> > 
> > I thought that apt was supposed to auto-pin experimental to not upgrade
> > to packages in it automatically. However:
> > 
> > joey@dragon:~>apt-cache policy diff
> > diff:
> >   Installed: 2.8.1-6
> >   Candidate: 2.8.4-0.0
> >   Version Table:
> >      2.8.4-0.0 0
> >         500 http://http.us.debian.org ../project/experimental/main Packages
> >  *** 2.8.1-6 0
> >         500 http://http.us.debian.org unstable/main Packages
> >         100 /var/lib/dpkg/status
> > 
> > And indeed it wants to download diff and several other packages from
> > experimental. I downgraded to apt 0.5.17, and it behaves the same. Am I
> > wrong about the default experimental pinning?
> 
> OK, I can reproduce this.  The problem is that it is looking for
> experimental/binary-$(ARCH)/main/Release (which isn't downloaded) rather
> than experimental/Release (which is).  This might require some changes, but
> is fixable.

So here's the deal.

apt 0.5 downloads dists/<dist>/<section>/<binary,source>/Release for use in
policy calculations.  apt 0.6 does not download that file at all, and
downloads dists/<dist>/Release for use in authentication.  However, 0.6
still tries to read dists/<dist>/<section>/<binary,source>/Release, which
has not been downloaded.

This could be fixed one of two ways:

1. Use dists/<dist>/Release for both purposes (authentication and pinning).
This is trivial, and works fine for the Debian archive (dists/<dist>/Release
is more or less a superset of
dists/<dist>/<section>/<binary,source>/Release), but could have unknown
effects for third-party repositories which provide per-section Release
files.

2. Continue to download them all.  This requires some further changes to the
apt-secure code.

Personally, I find the distinction between these two types of Release files
to be confusing, and would prefer (1) as it is much simpler.  However, I
don't know whether there is a rationale for why things were done as they
were for apt-secure, and whether the top-level Release file is intended to
replace the others.

Suggestions?

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #260 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Colin Walters <walters@debian.org>
Cc: Isaac Jones <ijones@syntaxpolice.org>, 203741@bugs.debian.org
Subject: Re: apt sigcheck patches
Date: Sun, 28 Dec 2003 14:11:04 -0800
On Sun, Dec 28, 2003 at 04:53:53PM -0500, Colin Walters wrote:

> On Fri, 2003-12-26 at 11:26, Matt Zimmerman wrote:
> 
> > I found this bug; it was here (srcrecords.cc):
> [...]
> 
> Ah, good catch.  My C++-fu is weak.  I had tried valgrind, but it only
> gave me an error much later.

For some reason it became unreproducible shortly after I found it the first
time, so I assumed I had messed up my build.  It wasn't until it resurfaced
recently that I tracked it down.

I just ran into another issue that I'd appreciate some input/background on.
It appears that while apt 0.5 retrieves the per-section Release files (e.g.,
dists/stable/main/binary-i386/Release), apt 0.6/apt-secure only retrieves
the top-level one (e.g., dists/unstable/Release).  LoadReleaseInfo still
tries to read the per-section file, which isn't there because it was never
downloaded, and so things like pinning are broken.

Was the intention to move away from per-section Release files, and to only
use the top-level one?  Or was this an oversight, and we should be
downloading these files and continuing to use them?

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Colin Walters <walters@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #265 received at 203741@bugs.debian.org (full text, mbox):

From: Colin Walters <walters@debian.org>
To: Matt Zimmerman <mdz@debian.org>
Cc: Isaac Jones <ijones@syntaxpolice.org>, 203741@bugs.debian.org
Subject: Re: apt sigcheck patches
Date: Sun, 28 Dec 2003 18:00:05 -0500
[Message part 1 (text/plain, inline)]
On Sun, 2003-12-28 at 17:11, Matt Zimmerman wrote:

> Was the intention to move away from per-section Release files, and to only
> use the top-level one?  Or was this an oversight, and we should be
> downloading these files and continuing to use them?

I think our thought was that the per-section Release files should go
away in favor the main Release file; they don't actually contain any
more information, right?
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #270 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: debian-devel@lists.debian.org, 203741@bugs.debian.org
Subject: Re: apt 0.6 in experimental
Date: Sun, 28 Dec 2003 16:11:33 -0800
On Sun, Dec 28, 2003 at 02:28:18PM -0800, Matt Zimmerman wrote:

> apt 0.5 downloads dists/<dist>/<section>/<binary,source>/Release for use in
> policy calculations.  apt 0.6 does not download that file at all, and
> downloads dists/<dist>/Release for use in authentication.  However, 0.6
> still tries to read dists/<dist>/<section>/<binary,source>/Release, which
> has not been downloaded.
> 
> This could be fixed one of two ways:
> 
> 1. Use dists/<dist>/Release for both purposes (authentication and pinning).
> This is trivial, and works fine for the Debian archive (dists/<dist>/Release
> is more or less a superset of
> dists/<dist>/<section>/<binary,source>/Release), but could have unknown
> effects for third-party repositories which provide per-section Release
> files.
> 
> 2. Continue to download them all.  This requires some further changes to the
> apt-secure code.
> 
> Personally, I find the distinction between these two types of Release files
> to be confusing, and would prefer (1) as it is much simpler.  However, I
> don't know whether there is a rationale for why things were done as they
> were for apt-secure, and whether the top-level Release file is intended to
> replace the others.

After discussing this with Colin Walters, I've implemented (1.) in apt
0.6.4, which has been uploaded to experimental.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Isaac Jones <ijones@syntaxpolice.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #275 received at 203741@bugs.debian.org (full text, mbox):

From: Isaac Jones <ijones@syntaxpolice.org>
To: Matt Zimmerman <mdz@debian.org>
Cc: Colin Walters <walters@debian.org>, 203741@bugs.debian.org
Subject: Re: apt sigcheck patches
Date: Sun, 28 Dec 2003 19:40:30 -0500
Matt Zimmerman <mdz@debian.org> writes:

> On Sun, Dec 28, 2003 at 04:53:53PM -0500, Colin Walters wrote:
>
>> On Fri, 2003-12-26 at 11:26, Matt Zimmerman wrote:
>> 
>> > I found this bug; it was here (srcrecords.cc):
>> [...]
>> 
>> Ah, good catch.  My C++-fu is weak.  I had tried valgrind, but it only
>> gave me an error much later.
>
> For some reason it became unreproducible shortly after I found it the first
> time, so I assumed I had messed up my build.  It wasn't until it resurfaced
> recently that I tracked it down.

It has always been annoyingly unreproducible.

> Was the intention to move away from per-section Release files, and to only
> use the top-level one?  Or was this an oversight, and we should be
> downloading these files and continuing to use them?

I agree with Colin that the idea was to get rid of the per-section
Release files.  It was probably an oversight that we never got around
to fixing the cases where they were actually used.  Neither of us
really use pinning.

Does anyone know why these sub-release files exist?  Were they around
before the signed ones that "apt-secure" uses?

>> One other small difference is that the main Release file uses "Suite" rather
>> than "Archive".  I'm inclined to just change the code to look for Suite,
>> since it seems to match other terminology better.
>
> Done in 0.6.4 (experimental).

Cool!

peace,

isaac



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #280 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Colin Walters <walters@debian.org>
Cc: Isaac Jones <ijones@syntaxpolice.org>, 203741@bugs.debian.org
Subject: Re: apt sigcheck patches
Date: Sun, 28 Dec 2003 15:37:44 -0800
On Sun, Dec 28, 2003 at 06:00:05PM -0500, Colin Walters wrote:

> On Sun, 2003-12-28 at 17:11, Matt Zimmerman wrote:
> 
> > Was the intention to move away from per-section Release files, and to only
> > use the top-level one?  Or was this an oversight, and we should be
> > downloading these files and continuing to use them?
> 
> I think our thought was that the per-section Release files should go
> away in favor the main Release file; they don't actually contain any
> more information, right?

Correct, they do not contain any more information.  The only feature that
would be lost is the ability to set different parameters (codename,
notautomatic, etc.) for the various sections of an archive.  I don't think
that anyone is doing this, and it doesn't seem worth the extra complexity.

One other small difference is that the main Release file uses "Suite" rather
than "Archive".  I'm inclined to just change the code to look for Suite,
since it seems to match other terminology better.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #285 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Isaac Jones <ijones@syntaxpolice.org>
Cc: Colin Walters <walters@debian.org>, 203741@bugs.debian.org
Subject: Re: apt sigcheck patches
Date: Sun, 28 Dec 2003 19:43:52 -0800
On Sun, Dec 28, 2003 at 07:40:30PM -0500, Isaac Jones wrote:

> I agree with Colin that the idea was to get rid of the per-section
> Release files.  It was probably an oversight that we never got around
> to fixing the cases where they were actually used.  Neither of us
> really use pinning.
> 
> Does anyone know why these sub-release files exist?  Were they around
> before the signed ones that "apt-secure" uses?

They are used by apt 0.5 for pinning, so they go back at least as far as apt
0.5.  I don't know at what point the top-level Release appeared.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #290 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: 203741@bugs.debian.org
Subject: Known issues list
Date: Mon, 29 Dec 2003 17:11:34 -0800
- IMS requests/"Hit" are broken for Release and Release.gpg

- gpgv is broken for local repositories (file:) because the Release file is
  not copied into Dir::State::Lists

- There is still some unknown weirdness with the tagfile parser causing
  segfaults for some people, and when I've tried to fix it, I end up getting
  parse errors instead.  Something to do with EOF detection, appending of
  the record delimiter, buffer alignment, etc.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #295 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: debian-devel@lists.debian.org
Cc: 203741@bugs.debian.org
Subject: Re: apt 0.6 in experimental
Date: Mon, 29 Dec 2003 18:17:11 -0800
On Mon, Dec 29, 2003 at 09:18:41PM -0500, Joey Hess wrote:

> Matt Zimmerman wrote:
> > > Adding -o Debug::Acquire::gpgv=yes does not seem to add any additional
> > > debugging info about why it cannot validate my file: repositories.
> > 
> > It should print the gpg command line.  What is it?
> 
> It doesn't print any extra debugging information at all with that parameter.
> But here goes anyway:

That's because I didn't check the parameter before sending it to you.  It's
actually Debug::pkgAcquire::Auth=yes.

> root@kite:~/bin>strace -s 4092 -f apt-get update 2>&1 |grep exec |grep gpg
> [pid 13972] execve("/usr/lib/apt/methods/gpgv", ["/usr/lib/apt/methods/gpgv"], [/* 44 vars */]) = 0
> [pid 13973] execve("/usr/lib/apt/methods/gpgv", ["/usr/lib/apt/methods/gpgv"], [/* 44 vars */]) = 0
> [pid 13974] execve("/usr/bin/gpgv", ["/usr/bin/gpgv", "--status-fd", "3", "--keyring", "/etc/apt/trusted.gpg", "/var/lib/apt/lists/partial/uqm.debian.net_unstable_Release.gpg", "/var/lib/apt/lists/uqm.debian.net_unstable_Release"], [/* 46 vars */] <unfinished ...>
> [pid 13975] execve("/usr/bin/gpgv", ["/usr/bin/gpgv", "--status-fd", "3", "--keyring", "/etc/apt/trusted.gpg", "/var/lib/apt/lists/partial/_home_joey_lib_debian_local_Release.gpg", "/var/lib/apt/lists/_home_joey_lib_debian_local_Release"], [/* 46 vars */]) = 0

But anyway, it's as I suspected; it's assuming that the Release file has
been copied into Dir::State::Lists, but it isn't copied if it's local.  It
shouldn't be too big of a problem to fix it to verify the file in-place.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #300 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: debian-devel@lists.debian.org
Cc: Peter Palfrader <weasel@debian.org>, 203741@bugs.debian.org
Subject: Re: apt 0.6 in experimental
Date: Wed, 31 Dec 2003 22:09:14 -0800
On Thu, Jan 01, 2004 at 04:32:06AM +0100, Peter Palfrader wrote:
> On Thu, 01 Jan 2004, Peter Palfrader wrote:
> 
> > On Wed, 31 Dec 2003, Matt Zimmerman wrote:
> > 
> > > On Wed, Dec 31, 2003 at 09:29:35AM +0100, Peter Palfrader wrote:
> > > 
> > > > Maybe that's it:  On my ibook apt stopped working after 0.6.3.
> > > > Reverting one of the 0.6.4 changes seems to fix the segfault I'm seeing.
> > > > 
> > > > | apt (0.6.6.1) experimental; urgency=low
> > > > | 
> > > > |   * Local non-maintainer package.
> > > > |   * Remove the +4 after Size in apt-pkg/tagfile.cc:36.
> > > 
> > > Looks like I missed part of the changes I meant to revert.  I'll be
> > > uploading 0.6.7 shortly.
> > 
> > 0.6.7 yields this error:
> > 
> > weasel@danube:~/tmp/apt$ sudo apt-get update
> > [...]
> > Fetched 4161kB in 24s (169kB/s)
> > Reading Package Lists... Error!
> > E: Unable to parse package file /var/lib/apt/lists/ftp.uk.debian.org_debian_dists_unstable_Release (1)
> > E: Problem opening /var/lib/apt/lists/ftp.uk.debian.org_debian_dists_unstable_contrib_binary-powerpc_Packages
> > E: The package lists or status file could not be parsed or opened.
> 
> Hmm, weird.  Removing var/lib/apt didn't fix it, but downgrading to
> 0.6.1 and upgrading to 0.6.7 did.
> 
> Definitely time to sleep.

There's still a bug in the tagfile parser that is tickled by the code which
reads Release.  Can you try this and tell me if it helps?

--- deblistparser.cc.~1.29.2.1.~	2003-12-28 15:56:18.000000000 -0800
+++ deblistparser.cc	2003-12-31 22:05:38.000000000 -0800
@@ -566,7 +566,7 @@
 bool debListParser::LoadReleaseInfo(pkgCache::PkgFileIterator FileI,
 				    FileFd &File)
 {
-   pkgTagFile Tags(&File, File.Size());
+   pkgTagFile Tags(&File, File.Size() + 256);
    pkgTagSection Section;
    if (Tags.Step(Section) == false)
       return false;


-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Peter Palfrader <weasel@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #305 received at 203741@bugs.debian.org (full text, mbox):

From: Peter Palfrader <weasel@debian.org>
To: debian-devel@lists.debian.org
Cc: 203741@bugs.debian.org
Subject: Re: apt 0.6 in experimental
Date: Thu, 1 Jan 2004 16:55:01 +0100
[Message part 1 (text/plain, inline)]
On Wed, 31 Dec 2003, Matt Zimmerman wrote:

> > Hmm, weird.  Removing var/lib/apt didn't fix it, but downgrading to
> > 0.6.1 and upgrading to 0.6.7 did.
> > 
> > Definitely time to sleep.
> 
> There's still a bug in the tagfile parser that is tickled by the code which
> reads Release.  Can you try this and tell me if it helps?
> 
> --- deblistparser.cc.~1.29.2.1.~	2003-12-28 15:56:18.000000000 -0800
> +++ deblistparser.cc	2003-12-31 22:05:38.000000000 -0800
> @@ -566,7 +566,7 @@
>  bool debListParser::LoadReleaseInfo(pkgCache::PkgFileIterator FileI,
>  				    FileFd &File)
>  {
> -   pkgTagFile Tags(&File, File.Size());
> +   pkgTagFile Tags(&File, File.Size() + 256);
>     pkgTagSection Section;
>     if (Tags.Step(Section) == false)
>        return false;

That seems to fix the problem for me.

Peter
-- 
 PGP signed and encrypted  |  .''`.  ** Debian GNU/Linux **
    messages preferred.    | : :' :      The  universal
                           | `. `'      Operating System
 http://www.palfrader.org/ |   `-    http://www.debian.org/
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to el.shaman@wanadoo.fr (Laurent):
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #310 received at 203741@bugs.debian.org (full text, mbox):

From: el.shaman@wanadoo.fr (Laurent)
To: 203741@bugs.debian.org
Subject: Re: apt 0.6 in experimental
Date: Thu, 1 Jan 2004 18:24:44 +0100
With apt 0.6.8, I still get the errors:

camus:/home/elshaman# apt-get update
[...]
Atteint http://ftp.de.debian.org unstable/non-US/non-free Sources
4138ko réceptionnés en 2m35s (26.6ko/s)
Impossible de récupérer
file:/var/cache/apt-build/repository/dists/apt-build/Release  impossible 
de changer le nom, Aucun fichier ou répertoire de ce type 
(/var/lib/apt/lists/partial/_var_cache_apt-build_repository_dists_apt-build_Release 
-> 
/var/lib/apt/lists/_var_cache_apt-build_repository_dists_apt-build_Release).
Lecture des listes de paquets... Erreur !
E: Impossible de traiter le fichier 
/var/lib/apt/lists/ftp.de.debian.org_debian_dists_experimental_Release 
(1)
E: Problem opening 
/var/lib/apt/lists/ftp.de.debian.org_debian_dists_experimental_non-free_binary-i386_Packages
E: Les listes de paquets ou le fichier « status » ne peuvent être 
analysés ou lus.
camus:/home/elshaman#


It's in french, but it's the same thing.




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #315 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Laurent <el.shaman@wanadoo.fr>, 203741@bugs.debian.org
Subject: Re: Bug#203741: apt 0.6 in experimental
Date: Thu, 1 Jan 2004 13:58:47 -0800
On Thu, Jan 01, 2004 at 06:24:44PM +0100, Laurent wrote:

> With apt 0.6.8, I still get the errors:

Try 0.6.9, in incoming shortly.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to el.shaman@wanadoo.fr (Laurent):
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #320 received at 203741@bugs.debian.org (full text, mbox):

From: el.shaman@wanadoo.fr (Laurent)
To: 203741@bugs.debian.org
Subject: Re: Bug#203741: apt 0.6 in experimental
Date: Fri, 2 Jan 2004 00:41:22 +0100
On Thu, Jan 01, 2004 at 01:58:47PM -0800, Matt Zimmerman wrote:
> 
> Try 0.6.9, in incoming shortly.
> 
It seems to work fine.



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #325 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: 203741@bugs.debian.org
Subject: [ijones@syntaxpolice.org: [(nowhere)] apt-secure]
Date: Thu, 1 Jan 2004 18:32:00 -0800
----- Forwarded message from Isaac Jones <ijones@syntaxpolice.org> -----

Date: Mon, 29 Dec 2003 22:12:21 -0500
From: Isaac Jones <ijones@syntaxpolice.org>
To: Matt Zimmerman <mdz@debian.org>
Subject: [(nowhere)] apt-secure

Here's a message from several months back which has some issues that
may or may not still exist.  I thought I'd pass it along. (I'm going
through old email.)

peace,

isaac


Date: Tue, 8 Jul 2003 08:19:12 +0200
From: wopp@parplies.de
To: walters@debian.org, ijones@syntaxpolice.org
Subject: apt-secure

Hi,

I've started to use apt-secure, and there are a few observations/questions
I'd like to share with you.
  
First of all, I greatly appreciate your efforts, as this hole in the Debian
security system had troubled me. Regular security updates are a nice thing,
but blindly trusting "The Internet" to provide you with legitimate versions
of packages correcting security flaws is, well, to a certain degree
nonsensical. Of course, so is blindly trusting "The Internet" to provide a
legitimate version of apt-secure, so the point made on debian-security is
valid: it would be nice if you provided a Release and a corresponding
Release.gpg file signed with your GPG key. Then we'd only be blindly trusting
you ;-). It doesn't seem too difficult to verify that signature and the
md5sums of the Packages and .deb files manually prior to installing
apt-secure. Something like:
  
- download Release and Release.gpg
- gpg --no-default-keyring --keyring=/etc/apt/trusted.gpg --keyserver the.earth.li --recv-keys <your-key-id(s)>
- gpg --no-default-keyring --keyring=/etc/apt/trusted.gpg --verify Release.gpg Release
- download Packages
- check the md5sum in Release against `md5sum Packages`
- check the md5sum for package apt in Packages against `md5sum apt_0.5.4.secure.2_i386.deb`
  (or does "non-secure apt" do this anyway?)


Ok, this is partly a sort of bug report, so here my first questions:
1.) How do I verify that I am in fact a person? ;-)
2.) How do you define "pre-alpha"? It works and actually does something useful,
    so isn't it at least alpha?


What I observed apt-secure to break (and therefore you might want to
include patched versions for):
1.) apt-proxy 1.3.0
    That was easy to quick-hack into working:

--- apt-proxy.orig      Mon Jul  7 04:07:00 2003
+++ apt-proxy   Mon Jul  7 04:06:40 2003
@@ -1223,7 +1223,7 @@
        conenc=
        ;;

-    *.bin)
+    *.bin|*Release.gpg)
        resolve_url $REQUEST
        [ -f $FRONT ] ||
            STREAM="`fetch_file_start $URL_REST $FRONT_BASE $BACKS`"
--- cut here ---

2.) apt-show-versions 0.03
    (yes, I'm getting my version information manually from
    /var/lib/dpkg/status ...)
    I've looked into that and can't come up with a quick solution. The
    problem is the new layout of the /var/lib/apt/lists directory.
    Before, there was one Release file corresponding to each Packages
    file, which told apt-show-versions to which distribution the
    packages in it belong. Now there is one Release file for several
    Packages files ...
    If you can explain to me (or point me to information explaining it :)
    how the information in the Release file relates to the Packages
    files, I'll have another look at fixing/quick-hacking it :). It
    seems fairly obvious, but I have no idea what nasty surprises I'm
    supposed to expect ;-).

    To give it a try: is it sufficient to take each file listed in
    Release, s|/|_|g and replace the "Release" in the original file name
    by the results obtained in order to get all the (potential) file names
    in /var/lib/apt/lists/ to which the Release file would apply? In
    Perl:

    $release  = name_of_release_file ();
    ($prefix) = $release =~ /^(.*)Release$/;
    $dist     = suite_or_archive_from_release_file ();
    @files    = all_file_names_from ($release);
    %map      = map { s|/|_|g; ("$prefix$_", $dist) } @files;
    
    # and then use $map {$file_name} to lookup the distribution it
    # belongs to
    
    ???
    Ok, writing this email made me try it out, and it seems to work ...
    so here's the pre-pre-alpha-very-quick-hack-type-patch ... presuming my
    interpretation of the semantics is correct. Hey, it's even got the correct
    time stamp on the orig file ;-)

--- apt-show-versions.orig      Wed Jan 16 23:01:01 2002
+++ apt-show-versions   Tue Jul  8 03:58:54 2003
@@ -103,19 +103,58 @@
 my $apackages;
 my %releases = ();
    
+# wopp, 07.07.03
+# Get relevant releases in the apt-secure era ...
+sub parse_release {
+  my $filename = shift;
+  my $dist;
+  my @files = ();
+  open RELEASE, "<$filename"
+    or die "Can't read release file $filename: $!\n";
+  while (<RELEASE>) {
+    if (/^\s*(?:suite|archive):\s+(\S+)\s*$/i) {
+      $dist ||= $1;
+    } elsif (/^\s*[\da-fA-F]{32}\s+\d{1,9}\s+(.*)$/) {
+      push @files, $1;
+    }
+  }
+  close RELEASE;
+  return ($dist, \@files);
+}
+
+my %map = ();
+opendir DIR, $list_dir
+  or die "Can't opendir $list_dir though I could before: $!\n";
+foreach my $relfile (map { "$list_dir$_" } grep /Release$/, readdir DIR) {
+  my $dist;
+  my $files;
+  (my $prefix) = $relfile =~ /^(.*)Release$/;
+  ($dist, $files) = parse_release ($relfile);
+  foreach (@$files) {
+    s|/|_|g;
+    $map {"$prefix$_"} = $dist;
+  }
+  $releases {$dist} = 1;
+}
+closedir DIR;
+
+# end wopp
+
 # Get available package information out of all Packages files
 foreach (@files) {
-    my $release = $_;
-    $release =~ s/Packages/Release/;
-    $release = quotemeta $release;
-    my $archiv;
-    $archiv = `fgrep -s Archive $release` or
-       $archiv = `fgrep -s Suite $release` or
-           next;
-    $archiv =~ s/Archive: //;
-    $archiv =~ s/Suite: //;
-    $archiv =~ s/\n//;
-    $releases{$archiv} = 1;
+    my $archiv = $map {$_}
+      or next;
+#    my $release = $_;
+#    $release =~ s/Packages/Release/;
+#    $release = quotemeta $release;
+#    my $archiv;
+#    $archiv = `fgrep -s Archive $release` or
+#      $archiv = `fgrep -s Suite $release` or
+#          next;
+#    $archiv =~ s/Archive: //;
+#    $archiv =~ s/Suite: //;
+#    $archiv =~ s/\n//;
+#    $releases{$archiv} = 1;

     my $href = &parse_file ($_);
     foreach (keys %$href) {
--- cut here ---


3.) apt-file 0.2.3-4
    The [debian2003] insertion in sources.list is added to the URL that
    apt-file constructs. I'm not sure about the purpose of that, but I
    suppose it's from CDROM sources (I don't seem to have any CDROM
    entries left anywhere, so I can't check :|). [Update: I found one,
    and it shouldn't be too hard to handle that "correctly" while still
    removing the vendor specification. I'm too tired right now though.]
    As apt-file doesn't implement CDROM sources yet, it doesn't seem to
    hurt to unconditionally remove the [] part: 

--- apt-file.orig       Tue Jul  8 02:25:26 2003
+++ apt-file    Tue Jul  8 02:26:13 2003
@@ -41,6 +41,8 @@
 # This file accepts 2 kinds of notation:
 # deb ftp://non-us.debian.org/debian-non-US sid/non-US main
 # deb ftp://non-us.debian.org/debian-non-US sid non-US/main
+# wopp, 07.07.03:
+# deb [vendor-spec] ftp://non-us.debian.org/debian-non-US sid non-US/main
 sub read_source_list {
     my @res=();
     open(SOURCE, "< $Conf{'sources-list'}")
@@ -52,7 +54,14 @@
            if (m/^([^\[]*)\[([^\]]*)\](.*)$/) {
                my ($tmp1, $tmp2, $tmp3) = ($1, $2, $3);
                $tmp2 =~ s/ /_/g;
-               $line = $tmp1.'['.$tmp2.']'.$tmp3;
+               # wopp, 07.07.03:
+               # I don't know what this []-voodoo is about ... probably
+               # CDROMs. In any case, it conflicts with apt-secure. I prefer
+               # apt-secure over apt-cdrom (which is NYI anyway, see below),
+               # thus ...
+               # $line = $tmp1.'['.$tmp2.']'.$tmp3;
+               $line = $tmp1 . $tmp3;  
+               # Please note that this is merely a Quick Hack (tm) though.
            }
            $line =~ s/\s+/ /g;
            my @path = split / /, $line;
--- cut here ---  

 
What I observed about apt-secure:
1.) The debug output seems to indicate that the woody Releases.gpg
    contains both a signature done with the 2002 key and one with the
    2003 key. A manual test (gpg --verify Release.gpg Release) confirms
    this. apt-secure fails to be satisfied though if you only import
    the 2003 key into trusted.gpg. For apt-secure, you need the 2002 key
    for it to work (so you need both, as you need the 2003 key for the
    security updates). This might be dependent on the order of the output
    from gpg (or gpgv, rather).
    That's not really a problem, but it IS a bug and a small annoyance.


Sorry if some or all of this is confusing and unclear. Please attribute
it to the local time here ;-).

Hope it helps.

Regards,

Holger

Content-Description: PGP Key 0x5828781F.
pub  1024D/5828781F 2003-07-04 Holger Parplies <wopp@parplies.de>
uid                            Holger Parplies <wopp@kloas.de>
uid                            Holger Parplies <wopp@planungsteam-eb.de>
uid                            Holger Parplies <wopp@ehd-gmbh.de>
uid                            Holger Parplies <wopp@werken-spielen-schenken.de>
uid                            Holger Parplies <wopp@cs.tu-berlin.de>
sub  1024g/9E343170 2003-07-04  [expires: 2005-07-03]





----- End forwarded message -----

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #330 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Debian Developers <debian-devel@lists.debian.org>
Cc: 203741@bugs.debian.org
Subject: Re: apt experimental breaks w/ webcaching (was Re: apt 0.6 in experimental)
Date: Thu, 1 Jan 2004 18:52:53 -0800
On Thu, Jan 01, 2004 at 07:34:26PM -0500, Anthony DeRobertis wrote:

> Installed 0.6.9, and now:
> 
> Failed to fetch  
> http://http.us.debian.org/debian/dists/testing/contrib/binary-i386/ 
> Packages.gz  MD5Sum mismatch
> Failed to fetch  
> http://http.us.debian.org/debian/dists/testing/contrib/source/ 
> Sources.gz  MD5Sum mismatch
> Failed to fetch  
> http://http.us.debian.org/debian/dists/unstable/contrib/source/ 
> Sources.gz  MD5Sum mismatch
> Reading Package Lists... Done
> 
> 
> Is it possible that I'm getting outdated copies of the Packages.gz and  
> Sources.gz file, possible due to my webcache? Yes, taking out the proxy  
> in /etc/apt/apt.conf fixes this.
> 
> Squid is certainly within its rights to not fetch a new version of  
> Packages.gz and Sources.gz while fetching the new Release file, and it  
> seems it happens. Especially with the amount of transparent proxying  
> that exists in the wild, this could be a problem...

A cache which serves stale data is a broken cache.  I think that apt is
within its rights to expect a consistent view from the world.  You would see
other failures if you got mismatched versions of Release and Release.gpg.

This will probably go away, though, when apt 0.6 is fixed to send proper
IMS requests for Release and Release.gpg.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #335 received at 203741@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Debian Developers <debian-devel@lists.debian.org>
Cc: 203741@bugs.debian.org
Subject: Re: apt experimental breaks w/ webcaching (was Re: apt 0.6 in experimental)
Date: Fri, 2 Jan 2004 03:44:02 +0000
On Thu, Jan 01, 2004 at 06:52:53PM -0800, Matt Zimmerman wrote:
> On Thu, Jan 01, 2004 at 07:34:26PM -0500, Anthony DeRobertis wrote:
> > Squid is certainly within its rights to not fetch a new version of  
> > Packages.gz and Sources.gz while fetching the new Release file, and it  
> > seems it happens. Especially with the amount of transparent proxying  
> > that exists in the wild, this could be a problem...
> 
> A cache which serves stale data is a broken cache.  I think that apt
> is within its rights to expect a consistent view from the world.  You
> would see other failures if you got mismatched versions of Release and
> Release.gpg.

Without perfect expiration data from the server, HTTP caches can't
fulfil this criterion, otherwise they always need to contact the server
and therefore can't properly fulfil their purpose as caches. What if
somebody had manually fetched Packages.gz ten minutes before the mirror
sync, but Release was uncached so the cache had to fetch it for the apt
run after the mirror sync?

In fact, from the cache's point of view the files are probably *not*
stale. A quick check on ftp.uk.debian.org, for instance, confirms that
we don't send any Expires or Cache-Control headers (even if we did, they
couldn't be 100% accurate). Therefore the cache's only possible
freshness criteria are based on heuristic expiration guesses, and those
are unlikely to be tight enough to avoid occasional failures.

> This will probably go away, though, when apt 0.6 is fixed to send
> proper IMS requests for Release and Release.gpg.

A request with If-Modified-Since returns 304 Not Modified (and therefore
no message-body) if the entity has not been modified, so you can only
use this for files you already have. The caching problems above may well
be caused by requests from multiple systems, so Cache-Control would be a
more appropriate choice of header.

Of course, Cache-Control requires you to make at least one uncontrolled
request first (or perhaps max-age=0 or no-cache?) in order that you know
the server's date, otherwise you run into clock synchronization
problems. It *is* possible to implement "get me file B and make sure
it's at least as new as file A" as an HTTP client, though, and if you
make sure your first file is genuinely fresh then the problem is solved
unless you're actually in a mirror sync at the time, in which case you
can just try again later.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #340 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Debian Developers <debian-devel@lists.debian.org>, 203741@bugs.debian.org
Subject: Re: apt experimental breaks w/ webcaching (was Re: apt 0.6 in experimental)
Date: Fri, 2 Jan 2004 09:11:31 -0800
On Fri, Jan 02, 2004 at 03:44:02AM +0000, Colin Watson wrote:

> On Thu, Jan 01, 2004 at 06:52:53PM -0800, Matt Zimmerman wrote:
> > A cache which serves stale data is a broken cache.  I think that apt
> > is within its rights to expect a consistent view from the world.  You
> > would see other failures if you got mismatched versions of Release and
> > Release.gpg.
> 
> Without perfect expiration data from the server, HTTP caches can't
> fulfil this criterion, otherwise they always need to contact the server
> and therefore can't properly fulfil their purpose as caches. What if
> somebody had manually fetched Packages.gz ten minutes before the mirror
> sync, but Release was uncached so the cache had to fetch it for the apt
> run after the mirror sync?

Their only purpose as caches is to improve performance; there's no rule that
they aren't allowed to contact the server to ensure that their response is
fresh enough.

> In fact, from the cache's point of view the files are probably *not*
> stale. A quick check on ftp.uk.debian.org, for instance, confirms that we
> don't send any Expires or Cache-Control headers (even if we did, they
> couldn't be 100% accurate). Therefore the cache's only possible freshness
> criteria are based on heuristic expiration guesses, and those are unlikely
> to be tight enough to avoid occasional failures.

Since Release and Packages/Sources are generated at close to the same time,
they should always be about the same age, and the heuristics should apply to
them equally.  Inconsistent Packages/Sources/Release really ought to be a
rather infrequent case.

> A request with If-Modified-Since returns 304 Not Modified (and therefore
> no message-body) if the entity has not been modified, so you can only use
> this for files you already have. The caching problems above may well be
> caused by requests from multiple systems, so Cache-Control would be a more

APT almost always has old copies of the indexes that it needs, so IMS is
very efficient.  You are correct that it cannot guarantee consistency, but I
believe that it would have prevented the problem in this case.

> Of course, Cache-Control requires you to make at least one uncontrolled
> request first (or perhaps max-age=0 or no-cache?) in order that you know
> the server's date, otherwise you run into clock synchronization
> problems. It *is* possible to implement "get me file B and make sure
> it's at least as new as file A" as an HTTP client, though, and if you
> make sure your first file is genuinely fresh then the problem is solved
> unless you're actually in a mirror sync at the time, in which case you
> can just try again later.

Hmm, APT's http method already sends Cache-Control: max-age for Packages and
Sources, just not for Release.  I can fix that.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #345 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Debian Developers <debian-devel@lists.debian.org>, 203741@bugs.debian.org
Subject: Re: apt experimental breaks w/ webcaching (was Re: apt 0.6 in experimental)
Date: Fri, 2 Jan 2004 09:49:46 -0800
On Fri, Jan 02, 2004 at 05:37:31PM +0000, Colin Watson wrote:

> On Fri, Jan 02, 2004 at 09:11:31AM -0800, Matt Zimmerman wrote:
> > Since Release and Packages/Sources are generated at close to the same
> > time, they should always be about the same age, and the heuristics
> > should apply to them equally.
> 
> They will be the same age on the *server*, but not necessarily in the
> cache, as my example quoted up at the top of this message shows. The
> cachedness or otherwise of an entity is very likely to be an input to the
> caching heuristics.

I don't know what other caches do, but Squid's expiration time heuristics
are based on the modification time of the file:

#               FRESH if expires < now, else STALE
#               STALE if age > max
#               FRESH if lm-factor < percent, else STALE
#               FRESH if age < min
#               else STALE

expires represents an explicit expiration time, age is the age of the object
in the cache, and lm-factor is based on the last-modified time on the file.
So the age of the object in the cache only comes into play with the max and
min parameters, not when estimating an expiration time when none is
specified.

It would be great if the mirrors would supply explicit Expires headers,
since they know when they will be next synched.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #350 received at 203741@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Debian Developers <debian-devel@lists.debian.org>
Cc: 203741@bugs.debian.org
Subject: Re: apt experimental breaks w/ webcaching (was Re: apt 0.6 in experimental)
Date: Fri, 2 Jan 2004 17:37:31 +0000
On Fri, Jan 02, 2004 at 09:11:31AM -0800, Matt Zimmerman wrote:
> On Fri, Jan 02, 2004 at 03:44:02AM +0000, Colin Watson wrote:
> > On Thu, Jan 01, 2004 at 06:52:53PM -0800, Matt Zimmerman wrote:
> > > A cache which serves stale data is a broken cache.  I think that apt
> > > is within its rights to expect a consistent view from the world.  You
> > > would see other failures if you got mismatched versions of Release and
> > > Release.gpg.
> > 
> > Without perfect expiration data from the server, HTTP caches can't
> > fulfil this criterion, otherwise they always need to contact the server
> > and therefore can't properly fulfil their purpose as caches. What if
> > somebody had manually fetched Packages.gz ten minutes before the mirror
> > sync, but Release was uncached so the cache had to fetch it for the apt
> > run after the mirror sync?
> 
> Their only purpose as caches is to improve performance; there's no rule that
> they aren't allowed to contact the server to ensure that their response is
> fresh enough.

True, but I quote (RFC 2616 section 13):

   Caching would be useless if it did not significantly improve
   performance. The goal of caching in HTTP/1.1 is to eliminate the need
   to send requests in many cases, and to eliminate the need to send
   full responses in many other cases. The former reduces the number of
   network round-trips required for many operations; we use an
   "expiration" mechanism for this purpose (see section 13.2). The
   latter reduces network bandwidth requirements; we use a "validation"
   mechanism for this purpose (see section 13.3).

You're describing the second part of this, but the first is also
important to the performance of caches. Round trips to the server often
dominate the response time. Release is a good example, since it's small,
but Packages.gz might also be small enough for this to be relevant in
the case of repositories other than Debian main.

> > In fact, from the cache's point of view the files are probably *not*
> > stale. A quick check on ftp.uk.debian.org, for instance, confirms that we
> > don't send any Expires or Cache-Control headers (even if we did, they
> > couldn't be 100% accurate). Therefore the cache's only possible freshness
> > criteria are based on heuristic expiration guesses, and those are unlikely
> > to be tight enough to avoid occasional failures.
> 
> Since Release and Packages/Sources are generated at close to the same time,
> they should always be about the same age, and the heuristics should apply to
> them equally.

They will be the same age on the *server*, but not necessarily in the
cache, as my example quoted up at the top of this message shows. The
cachedness or otherwise of an entity is very likely to be an input to
the caching heuristics.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Anthony DeRobertis <asd@suespammers.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #355 received at 203741@bugs.debian.org (full text, mbox):

From: Anthony DeRobertis <asd@suespammers.org>
To: Debian Developers <debian-devel@lists.debian.org>, 203741@bugs.debian.org
Subject: Re: apt experimental breaks w/ webcaching (was Re: apt 0.6 in experimental)
Date: Fri, 2 Jan 2004 14:22:43 -0500
On Jan 2, 2004, at 12:11, Matt Zimmerman wrote:

> Their only purpose as caches is to improve performance; there's no 
> rule that
> they aren't allowed to contact the server to ensure that their 
> response is
> fresh enough.

RFC 2616 Sec. 13.1.1.

(1), which is "contact the server and ask" starts (see 13.3) "[w]hen a 
cache has a stale entry that it would like to use as a response to a 
client's request...." so it doesn't apply. (3) is for errors, so it 
doesn't apply. (2) does apply.

In general, contacting the server negates all performance benefits, 
especially for small files (like, say, Releases.gpg).




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #360 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: Anthony DeRobertis <asd@suespammers.org>
Cc: Debian Developers <debian-devel@lists.debian.org>, 203741@bugs.debian.org
Subject: Re: apt experimental breaks w/ webcaching (was Re: apt 0.6 in experimental)
Date: Fri, 2 Jan 2004 11:47:08 -0800
On Fri, Jan 02, 2004 at 02:13:08PM -0500, Anthony DeRobertis wrote:

> On Jan 1, 2004, at 21:52, Matt Zimmerman wrote:
> 
> >>Squid is certainly within its rights to not fetch a new version of
> >>Packages.gz and Sources.gz while fetching the new Release file, and it
> >>seems it happens. Especially with the amount of transparent proxying
> >>that exists in the wild, this could be a problem...
> >
> >A cache which serves stale data is a broken cache.
> 
> No, it isn't. That's how a webcache is supposed to work.

I'm afraid not.  Caches must return data which is "fresh enough" according
to the requirements of the various parties involved, and therefore by
definition, must not serve stale data.

APT sends a Cache-Control: max-age header which must be honored by compliant
caches.  It turns out that this was not actually being sent for Release with
the new code, and that is now fixed in 0.6.11.  This is not perfect either,
but should help.  Unfortunately, max-age is not exactly what we want.

> > I think that apt is within its rights to expect a consistent view from
> > the world.
> No. See RFC 2616, Chapter 13. HTTP explicitly does not guarantee this.

APT is doing the best that it can with the available HTTP mechanisms.  There
is no way for APT to be perfect in this respect without going to
unreasonable lengths (such as separate no-cache HEAD requests to check
last-modified).

If you have a solution, by all means, describe it.  And no, I won't take you
seriously if you suggest that apt should use no-cache for everything.

> > You would see other failures if you got mismatched versions of Release
> > and Release.gpg.
> 
> Yep. And apt needs to be fixed to guarantee that doesn't happen.

Patches welcome.

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Anthony DeRobertis <asd@suespammers.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #365 received at 203741@bugs.debian.org (full text, mbox):

From: Anthony DeRobertis <asd@suespammers.org>
To: Matt Zimmerman <mdz@debian.org>
Cc: Debian Developers <debian-devel@lists.debian.org>, 203741@bugs.debian.org
Subject: Re: apt experimental breaks w/ webcaching (was Re: apt 0.6 in experimental)
Date: Fri, 2 Jan 2004 22:31:00 -0500
On Jan 2, 2004, at 14:47, Matt Zimmerman wrote:

>> No, it isn't. That's how a webcache is supposed to work.
>
> I'm afraid not.  Caches must return data which is "fresh enough" 
> according
> to the requirements of the various parties involved, and therefore by
> definition, must not serve stale data.

Sorry about that. I was using stale to mean "data in cache is older 
than what the application expected", not "older than what the protocol 
allows."

[ I was looking at apt < 0.6.11 when I made that statement, and 
certainly that older apt was getting data older than it wanted, due to 
failing to send Cache-Control. ]

> If you have a solution, by all means, describe it.  And no, I won't 
> take you
> seriously if you suggest that apt should use no-cache for everything.

I'm not going to suggest that, because that would be silly. We can both 
agree on that!

Would it be possible to have the mirrors use Expires: headers to make 
sure the files all expire at the same time?

Some other suggestions:
	o Check for time skew, do max-age 0 if-modified-since to fix.
	  probably won't work, reload 
http://http.us.debian.org/debian/dists/testing/main/binary-alpha/ a few 
times to see why. (modified times are
	  apparently not sync'd).

	o Keep yesterday's md5sums in the Release file. Either go ahead
	  silently with the old packages.gz files, or do a max-age 0 to
	  get current versions.

	o Similar to the first one, add sequence numbers to the files.
	  Force a refresh on old sequences.

>> Yep. And apt needs to be fixed to guarantee that doesn't happen.
>
> Patches welcome.

Ugh, you're gonna make me become an apt-hacker, aren't you? ;-)




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Anthony DeRobertis <asd@suespammers.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #370 received at 203741@bugs.debian.org (full text, mbox):

From: Anthony DeRobertis <asd@suespammers.org>
To: Debian Developers <debian-devel@lists.debian.org>, 203741@bugs.debian.org
Subject: Re: apt experimental breaks w/ webcaching (was Re: apt 0.6 in experimental)
Date: Fri, 2 Jan 2004 14:13:08 -0500
On Jan 1, 2004, at 21:52, Matt Zimmerman wrote:

>> Squid is certainly within its rights to not fetch a new version of
>> Packages.gz and Sources.gz while fetching the new Release file, and it
>> seems it happens. Especially with the amount of transparent proxying
>> that exists in the wild, this could be a problem...
>
> A cache which serves stale data is a broken cache.

No, it isn't. That's how a webcache is supposed to work.

>  I think that apt is
> within its rights to expect a consistent view from the world.

No. See RFC 2616, Chapter 13. HTTP explicitly does not guarantee this.

>  You would see
> other failures if you got mismatched versions of Release and 
> Release.gpg.

Yep. And apt needs to be fixed to guarantee that doesn't happen.




Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #375 received at 203741@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Debian Developers <debian-devel@lists.debian.org>
Cc: 203741@bugs.debian.org
Subject: Re: apt experimental breaks w/ webcaching (was Re: apt 0.6 in experimental)
Date: Sat, 3 Jan 2004 05:44:30 +0000
On Fri, Jan 02, 2004 at 10:31:00PM -0500, Anthony DeRobertis wrote:
> On Jan 2, 2004, at 14:47, Matt Zimmerman wrote:
> >If you have a solution, by all means, describe it.  And no, I won't
> >take you seriously if you suggest that apt should use no-cache for
> >everything.
> 
> I'm not going to suggest that, because that would be silly. We can both 
> agree on that!
> 
> Would it be possible to have the mirrors use Expires: headers to make 
> sure the files all expire at the same time?

That doesn't seem like a viable solution. If nothing else, people use
apt to talk to unofficial mirrors; it's not possible to set requirements
on those other than "speaks a protocol we understand".

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #380 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: 203741@bugs.debian.org
Subject: Branch in arch
Date: Tue, 23 Nov 2004 10:48:01 -0800
Ongoing development on the authentication stuff will happen in an arch
branch:

apt@packages.debian.org/apt--authentication--0

-- 
 - mdz



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#203741; Package apt. Full text and rfc822 format available.

Acknowledgement sent to Matt Zimmerman <mdz@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. Full text and rfc822 format available.

Message #385 received at 203741@bugs.debian.org (full text, mbox):

From: Matt Zimmerman <mdz@debian.org>
To: 203741@bugs.debian.org
Subject: Authentication patch brought up to date
Date: Sun, 28 Nov 2004 16:43:39 -0800
Thanks to Michael Vogt and Canonical, the authentication patch has been
now brought up to date with mainline, and merges cleanly again.

-- 
 - mdz



Bug closed, send any further explanations to Mikko Rauhala <mjr@iki.fi> Request was from Filipus Klutiero <ido@vif.com> to control@bugs.debian.org. Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 18 Jun 2007 03:30:32 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 24 08:12:01 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.