Bug#338889: Overzealously prefers signed packages to identical unsigned ones

2006-12-12 Thread Santiago Vila
On Wed, 23 Nov 2005, Goswin von Brederlow wrote:

 But in the general case it would be nice if apt-get would get the
 file/size/md5sum from a trusted Packages file and then fetch the deb
 from an untrusted source if it matches.

On Wed, 23 Nov 2005, Andras Korn wrote:

 [...] if two packages have the same size and md5sum, they can IMO be
 assumed to have the same signatures too.

Hi.

I agree with Goswin and Andras here. If sources.list is like this:

deb file:/local-repository
deb http://official-mirror

and package foo is in both repositories, and it has the same md5sum,
the fact that it's authenticated in http://official-mirror should be
enough to consider it authenticated in file:/local-repository as well.

In other words, apt's internal logic should be changed: It should be
the md5sum of a package (i.e. the package itself) what is to be considered
authenticated or not, not the pair package foo from repository bar.

Or at least there should be an option for apt to behave in this way.

It does not make much sense that the user has to fiddle with gpg, keys,
signatures, etc. when everything he wants to do is to have a local
repository which serves as a cache for packages which are already
authenticated by other means.

Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#338889: Overzealously prefers signed packages to identical unsigned ones

2006-12-12 Thread Goswin von Brederlow
Santiago Vila [EMAIL PROTECTED] writes:

 On Wed, 23 Nov 2005, Goswin von Brederlow wrote:

 But in the general case it would be nice if apt-get would get the
 file/size/md5sum from a trusted Packages file and then fetch the deb
 from an untrusted source if it matches.

 On Wed, 23 Nov 2005, Andras Korn wrote:

 [...] if two packages have the same size and md5sum, they can IMO be
 assumed to have the same signatures too.

 Hi.

 I agree with Goswin and Andras here. If sources.list is like this:

 deb file:/local-repository
 deb http://official-mirror

 and package foo is in both repositories, and it has the same md5sum,
 the fact that it's authenticated in http://official-mirror should be
 enough to consider it authenticated in file:/local-repository as well.

 In other words, apt's internal logic should be changed: It should be
 the md5sum of a package (i.e. the package itself) what is to be considered
 authenticated or not, not the pair package foo from repository bar.

 Or at least there should be an option for apt to behave in this way.

 It does not make much sense that the user has to fiddle with gpg, keys,
 signatures, etc. when everything he wants to do is to have a local
 repository which serves as a cache for packages which are already
 authenticated by other means.

 Thanks.

Even more so the same logic should apply to Packages and Sources
files. My sources.list often looks like this:

deb file:/local-mirror sid main contrib non-free
deb-src copy:/local-mirror sid main contrib non-free
deb http://near-official-mirror sid main contrib non-free
deb-src http://near-official-mirror sid main contrib non-free
deb http://ftp.debian.org/debian sid main contrib non-free
deb-src http://ftp.debian.org/debian sid main contrib non-free

It would be real nice if apt-get would only fetch the local
Packages/Sources files and see that the near official mirror and
ftp.debian.org both have the same metafiles.

With pdiff files that would save downloading 24 pdiffs a day and we
all know how long they take. With normal files 12 meta files could be
skipped on a good day (when local is in sync).

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#338889: Overzealously prefers signed packages to identical unsigned ones

2005-11-23 Thread Michael Vogt
On Sun, Nov 13, 2005 at 04:37:15PM +0100, Andras Korn wrote:
 Package: apt
 Version: 0.6.42.3
 Severity: normal

Thanks for your bugreport.
 
 I have a local package repository that is pieced together from many
 different sources. I don't have a signed Release file (is there an easy way
 to generate one automatically?); I only generate my own Packages file.

It's a matter of runing apt-ftparchive and gpg, see apt-secure(8) for
a discussion.
 
 The patch to this local repository is listed first in my sources.list.
 
 Nevertheless, when apt-get needs to fetch packages, it ignores my local
 repository and downloads the exact same packages from the net instead,
 presumably because those repositories are signed. (But do correct me if I'm
 wrong.)
[..]

Yes, it's a feature of apt to prefer signed sources. But if you run it
with --allow-unauthenticated, it should behave exactly as the 0.5.x
versions. Can you please try/confirm this?
 
Cheers,
 Michael

-- 
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#338889: Overzealously prefers signed packages to identical unsigned ones

2005-11-23 Thread Goswin von Brederlow
Michael Vogt [EMAIL PROTECTED] writes:

 On Sun, Nov 13, 2005 at 04:37:15PM +0100, Andras Korn wrote:
 Package: apt
 Version: 0.6.42.3
 Severity: normal

 Thanks for your bugreport.
  
 I have a local package repository that is pieced together from many
 different sources. I don't have a signed Release file (is there an easy way
 to generate one automatically?); I only generate my own Packages file.

 It's a matter of runing apt-ftparchive and gpg, see apt-secure(8) for
 a discussion.

I can't resist suggesting reprepro again. :) It is just born to do
exactly that (a local package repository that is pieced together from
many different sources). I piece together my own archive from
ftp.de.debian.org (source+i386), amd64.debian.net (source+amd64),
security.debian.org (source+i386+amd64) as well all locally build,
backported and patched packages.

 The patch to this local repository is listed first in my sources.list.
 
 Nevertheless, when apt-get needs to fetch packages, it ignores my local
 repository and downloads the exact same packages from the net instead,
 presumably because those repositories are signed. (But do correct me if I'm
 wrong.)
 [..]

 Yes, it's a feature of apt to prefer signed sources. But if you run it
 with --allow-unauthenticated, it should behave exactly as the 0.5.x
 versions. Can you please try/confirm this?

There is also a patch from me in the BTS that allows a vendor tag of
[TRUSTED] in the source.list to skip the Release.gpg check for that
entry.

But in the general case it would be nice if apt-get would get the
file/size/md5sum from a trusted Packages file and then fetch the deb
from an untrusted source if it matches.
  
 Cheers,
  Michael

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#338889: Overzealously prefers signed packages to identical unsigned ones

2005-11-23 Thread Andras Korn
On Wed, Nov 23, 2005 at 04:47:02PM +0100, Michael Vogt wrote:

Hi,

  I have a local package repository that is pieced together from many
  different sources. I don't have a signed Release file (is there an easy way
  to generate one automatically?); I only generate my own Packages file.
 
 It's a matter of runing apt-ftparchive and gpg, see apt-secure(8) for
 a discussion.

OK, will do; thanks.

  Nevertheless, when apt-get needs to fetch packages, it ignores my local
  repository and downloads the exact same packages from the net instead,
  presumably because those repositories are signed. (But do correct me if I'm
  wrong.)
 [..]
 
 Yes, it's a feature of apt to prefer signed sources. But if you run it
 with --allow-unauthenticated, it should behave exactly as the 0.5.x
 versions. Can you please try/confirm this?

This switch seems to work as advertised here; alas, the manpage isn't very
clear about it - it just seems to say that this turns off the prompt about
unsigned packages.

This is a good enough workaround for me, but I still think the new behaviour
is wasteful (it wastes bandwidth) - if two packages have the same size and
md5sum, they can IMO be assumed to have the same signatures too.

Andras

-- 
 Andras Korn korn at chardonnay.math.bme.hu
 http://chardonnay.math.bme.hu/~korn/ QOTD:
  Whoever decided to limit taglines to a single line can just kiss my


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#338889: Overzealously prefers signed packages to identical unsigned ones

2005-11-13 Thread Andras Korn
Package: apt
Version: 0.6.42.3
Severity: normal

Hi,

I have a local package repository that is pieced together from many
different sources. I don't have a signed Release file (is there an easy way
to generate one automatically?); I only generate my own Packages file.

The patch to this local repository is listed first in my sources.list.

Nevertheless, when apt-get needs to fetch packages, it ignores my local
repository and downloads the exact same packages from the net instead,
presumably because those repositories are signed. (But do correct me if I'm
wrong.)

This is inefficient. I think that in situations where an identical (same
md5sum) package is available from multiple sources, the existence of a
Release signature shouldn't be a consideration - after all, if the local
copy has the same md5sum, it can be assumed that the same signature that the
copy from the official mirror has also applies to this one.

Currently, I work around the problem by copying all packages apt would
download to /var/cache/apt/archives from my local repository before invoking
apt.

Andras

-- Package-specific info:

-- apt-config dump --

APT ;
APT::Architecture i386;
APT::Build-Essential ;
APT::Build-Essential:: build-essential;
APT::Get ;
APT::Get::Download-Only false;
APT::Get::Simulate false;
APT::Get::Assume-Yes false;
APT::Get::Force-Yes false;
APT::Get::Fix-Broken false;
APT::Get::Show-Upgraded false;
APT::Get::No-Upgrade false;
APT::Get::Print-URIs false;
APT::Get::Compile false;
APT::Get::No-Download false;
APT::Get::Purge false;
APT::Get::List-Cleanup true;
APT::Cache ;
APT::Cache::Important false;
APT::CDROM ;
APT::CDROM::Rename false;
APT::CDROM::NoMount false;
APT::CDROM::Fast false;
APT::CDROM::NoAct false;
APT::Cache-Limit 4000;
APT::Ignore-Hold false;
APT::Immediate-Configure true;
APT::Force-LoopBreak false;
APT::FTPArchive ;
APT::FTPArchive::Release ;
APT::FTPArchive::Release::Origin Korn;
APT::FTPArchive::Release::Label Debian;
APT::FTPArchive::Release::Suite experimental;
APT::FTPArchive::Release::Codename chardonnay;
APT::FTPArchive::Release::Components main;
APT::FTPArchive::Release::Description Experimental archive for private use;
Dir /;
Dir::State var/lib/apt/;
Dir::State::lists lists/;
Dir::State::cdroms cdroms.list;
Dir::State::userstatus status.user;
Dir::State::status /var/lib/dpkg/status;
Dir::Cache var/cache/apt/;
Dir::Cache::archives archives/;
Dir::Cache::srcpkgcache srcpkgcache.bin;
Dir::Cache::pkgcache pkgcache.bin;
Dir::Etc etc/apt/;
Dir::Etc::sourcelist sources.list;
Dir::Etc::vendorlist vendors.list;
Dir::Etc::vendorparts vendors.list.d;
Dir::Etc::main apt.conf;
Dir::Etc::parts apt.conf.d;
Dir::Etc::preferences preferences;
Dir::Bin ;
Dir::Bin::methods /usr/lib/apt/methods;
Dir::Bin::dpkg /usr/bin/dpkg;
DPkg ;
DPkg::Pre-Install-Pkgs ;
DPkg::Pre-Install-Pkgs:: if dpkg -s apt-listbugs | grep -q '^Status: .* ok 
installed'; then /usr/sbin/apt-listbugs apt || ( test $? -ne 10 || exit 10; 
echo 'Warning: apt-listbugs exited abnormally, hit enter key to continue.' 12 
; read a  /dev/tty ); fi;
DPkg::Pre-Install-Pkgs:: /usr/bin/apt-listchanges --apt || test $? -ne 10;
DPkg::Tools ;
DPkg::Tools::Options ;
DPkg::Tools::Options::/usr/bin/apt-listchanges ;
DPkg::Tools::Options::/usr/bin/apt-listchanges::Version 2;
DPkg::Post-Invoke ;
DPkg::Post-Invoke:: if [ -x /usr/bin/debsums ]; then /usr/bin/debsums 
--generate=nocheck -sp /var/cache/apt/archives; fi;
DPkg::Post-Invoke:: if [ -x /usr/sbin/localepurge ]  [ $(ps w -p $PPID | 
grep -c remove) != 1 ]; then /usr/sbin/localepurge; else exit 0; fi;
DPkg::Options ;
DPkg::Options:: --force-overwrite;
DPkg::Options:: --force-bad-verify;
DPkg::Run-Directory /;
DPkg::Build-Options -b -uc;
Acquire ;
Acquire::Queue-Mode host;
Acquire::Retries 0;
Acquire::Source-Symlinks true;
Acquire::http ;
Acquire::http::Proxy ;
Acquire::http::Timeout 5;
Acquire::http::No-Cache false;
Acquire::http::Max-Age 86400;
Acquire::http::No-Store false;
Acquire::Timeout 5;
Acquire::Passive true;
Acquire::Passive::galeon.sourceforge.net false;
Acquire::Proxy ;
Acquire::Proxy::Passive true;
cdrom ;
cdrom::Mount /cdrom;
cdrom::/cdrom/ ;
cdrom::/cdrom/::Mount sleep 1000;
cdrom::/cdrom/::UMount sleep 500;
DSelect ;
DSelect::Clean auto;
DSelect::Options -f;
DSelect::UpdateOptions ;
DSelect::PromptAfterUpdate no;
Debug ;
Debug::pkgProblemResolver false;
Debug::pkgAcquire false;
Debug::pkgAcquire::Worker false;
Debug::pkgDPkgPM false;
Debug::pkgInitialize false;
Debug::NoLocking false;
Debug::Acquire ;
Debug::Acquire::Ftp false;
Debug::aptcdrom false;

-- /etc/apt/preferences --


-- /etc/apt/sources.list --

deb file:/mnt/debian unstable main
deb ftp://ftp.bme.hu/OS/Linux/dist/debian sid main contrib non-free
[...]

-- System Information:
Debian Release: unstable
  APT prefers breezy-security
  APT policy: (500, 'breezy-security'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.7-chardonnay-skas3-v8-rc2
Locale: