On 01-09-01 Simon Richter wrote:
> On Sat, 1 Sep 2001, Christian Kurz wrote:
> > > not be ascii armored since this would only introduce transmission overhead
> > > and gain nothing. The file name for this file is constructed from the
> > Why does it gain nothing? What about problems during transmission? The
> > ascii armor output which is protected by a crc checksum would help
> > notice such a transmission problem.
> dpkg already has a mechanism for finding packages that have been corrupted
> by transferring them in ASCII mode. I mean, the .tar.gz is already binary,
Since which day does dpkg download packages in ascci-mode from a url?
Are you sure that you are not mixing up dpkg and apt-get? dpkg has as
far as I know no mechanismen to detected corrupted packages and therefor
having an ascii-armored signatures, with a crc checksum to detect
transmission errors will be helpful.
> so why should the file following it be ASCII?
Because there are situations where you don't use a tool that checks if
the transmission was fine. You should not only find a solution for the
specific case, that a tool downloads the packages from a server and
already checks if the transmission was fine, but also for situations
where such a tool is not provided.
> > > If the original filename is no more than sizeof(ar_name)-2 bytes
> > > long, ".s" is appended to it. If it is longer, the part of the
> > > file name before the
> > .s? Another new extension? If you want to achive confusion for our users
> > and developers, that's a possible way to go. If you really don't want to
> > use ascii armor, then the extension should be .sig or if you use
> > ascii-armor then .asc.
> The problem here is the filename length limit. I would have gone for
> ".sig" otherwise. Besides, you will only see those if you look at .deb
> files directly.
And that will never happen? I'm tempted to say that there are cases
where you have to look into the .deb directly or extract it via ar/tar.
And the people will be confused in those cases, if they notice a file
called .s, because that's an unusual extension.
> > > - Modify the autobuilders and existing developer scripts
> > > ("debsign") so that they call dpkg-deb to sign the packages
> > > additionally to signing the .changes file.
> > Sign packages build by an auto-builder?
> Of course. katie needs to verify that they were indeed created by an
> "official" autobuilder.
How do you want to handle the issue with the passphrase in a secure way?
How do you want to ensure that the key is safely placed on the
autobuilder and how do you want to ensure that only trusted people have
access to the autobuilder and especially this key? Placing a key on an
auto-builder with script that contains the passphrase to sign all
packages, is hazardous.
Christian
--
Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
Attachment:
pgpqVHKbNlKhS.pgp
Description: PGP signature