Re: Upstream Tarball Signature Files

[Paul Hardy]

Russ,

On Sat, Aug 12, 2017 at 7:59 PM, Russ Allbery  wrote:

>
> Hi Paul,
>
> This isn't a debian-policy matter...
>

My thinking was it would be beneficial for Debian Policy to suggest (but
not require) use of upstream OpenPGP signatures when available, because
such signature file use will help ensure the integrity of the Debian
archive.

However, I don't think it's a good idea to support multiple file names for
> the same thing...
>
> It's almost never a good idea to introduce synonyms into any sort of
> standard.  It adds a lot of complexity that has to be maintained forever,
> to very little benefit.


In this case, it is a trade-off between Debian packaging tools accepting
both ASCII and binary signature files forever, versus Debian maintainers
who repackage upstream sources with binary signatures having to convert
those signatures with each new upstream release forever.

The GNU FTP repository files are accompanied by binary ".sig" signatures
during upload to that site, and are listed with the accompanying files
(which is why I need to generate binary ".sig" files for upstream).  The
benefit at least would be for Debian maintainers who re-package those GNU
Project files.

However, I can propose additions for the Policy Manual in Chapter 4 and the
Files and Checksums sections that only describe the ".asc" format.  At
least that will document the current situation.

Thanks,


Paul Hardy

Processed: Re: Bug#790040: tex-common: doesn't properly clean up legacy files

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 790040 dpkg
Bug #790040 [tex-common] tex-common: doesn't properly clean up legacy files
Bug reassigned from package 'tex-common' to 'dpkg'.
No longer marked as found in versions tex-common/6.01.
Ignoring request to alter fixed versions of bug #790040 to the same values 
previously set
> retitle 790040 dpkg-maintscript blocks directories from being removed
Bug #790040 [dpkg] tex-common: doesn't properly clean up legacy files
Changed Bug title to 'dpkg-maintscript blocks directories from being removed' 
from 'tex-common: doesn't properly clean up legacy files'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
790040: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790040
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#872146: dpkg: dpkg --verify complains about /usr/share/man/man1/cpp.1.gz

[Sven Joachim]

On 2017-08-14 17:26 +0200, Sven Joachim wrote:

> Package: dpkg
> Version: 1.18.24
> Severity: normal
>
> Something strange is happening here: "dpkg --verify" complains about the
> file /usr/share/man/man1/cpp.1.gz (a symlink shipped in the cpp-doc
> package), but only if the package containing it is _not_ given on the
> commandline.
>
> ,
> | $ dpkg -S /usr/share/man/man1/cpp.1.gz 
> | cpp-doc: /usr/share/man/man1/cpp.1.gz
> | $ dpkg --verify cpp-doc
> | $ dpkg --verify 2>/dev/null | grep cpp
> | ??5??   /usr/share/man/man1/cpp.1.gz
> `

It turned out that this happened because I had an obsolete and
long-forgotten package installed which also shipped
/usr/share/man/man1/cpp.1.gz[1], and I had reinstalled cpp-doc with
"--force-overwrite" back then.  Still, the md5sum of the replaced file
was still in place.

,
| $ grep cpp.1.gz /var/lib/dpkg/info/*md5sums
| 
/var/lib/dpkg/info/pcc-for-i386-linux-gnu.md5sums:64430acd117b32ae7b6afceec7371927
  usr/share/man/man1/cpp.1.gz
`

The problem can be reproduced with the attached dummy packages where a
regular file is replaced with a symlink (thus, there is no md5sum entry
for it in the replacing package).

,
| $ dpkg --verify bar foo
| $ dpkg --verify foo bar  
| ??5??   /usr/bin/foo
`

Cheers,
   Sven


1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623952



foo_0_all.deb
Description: application/debian-package


bar_0_all.deb
Description: application/debian-package

Re: Upstream Tarball Signature Files

[Russ Allbery]

Henrique de Moraes Holschuh  writes:

> We do when the binary sig is small enough to be stored along with the
> inode, instead of requiring an entire filesystem block (4KiB), and the
> armored signature is not small enough for that :-( Of course, this
> really depends a lot on the filesystem, etc.

I'm not sure what signatures you're looking at.  Maybe ones with lots of
separate signers?  A typical *.asc file with one signer is about 500
bytes.

> May I humbly suggest that, *if* a change is going to be made, we switch
> to ".sig" (binary) and ".sig.asc" (armored), or .sig.gpg / sig.gpg.asc?
> As in "let's not overload .asc to mean armored signature, when it only
> means ASCII text"...

Note that I'm arguing for no change, just documenting the existing support
for *.asc upstream signatures.  This will imply that anyone who wants to
include an upstream signature that's provided in *.sig format will need to
convert it to *.asc, but that's not a *change*.  That's the current state
of the archive.

-- 
Russ Allbery (r...@debian.org)   

Re: Upstream Tarball Signature Files

[Henrique de Moraes Holschuh]

On Mon, 14 Aug 2017, Russ Allbery wrote:
> Henrique de Moraes Holschuh  writes:
> > On Sun, 13 Aug 2017, Russ Allbery wrote:
> >> it can't just move the file -- it has to ASCII-armor it.  But still, I
> >> think that's the right thing for the tools to do, not add another file.
> >> (The ASCII format is completely equivalent to the binary format; the
> >> conversion shouldn't lose or change any data.)
> 
> > The armor just wastes space, and will do so for every signature in the
> > archive.
> 
> I very much doubt we will ever notice such a tiny amount of overhead.

We do when the binary sig is small enough to be stored along with the
inode, instead of requiring an entire filesystem block (4KiB), and the
armored signature is not small enough for that :-(   Of course, this
really depends a lot on the filesystem, etc.

It is not an extreme difference anyway even in the worst case, but it
might be a Good Idea to avoid technical debt on a feature we have not
even deployed to production (as in "started to use") yet, without at
least considering the alternatives.

> > Why are we not using binary signatures in the first place, if we're
> > going to mandate conversions?
> 
> We could go that route too, but I don't think the benefits are worth
> changing the existing code that supports *.asc files.  But I certainly
> wouldn't object if the folks doing the work wanted to change.  I just want
> to support only one or the other.

Then we should have gone with .sig :-(  At least it means "signature",
and not "ascii text".

May I humbly suggest that, *if* a change is going to be made, we switch
to ".sig" (binary) and ".sig.asc" (armored), or .sig.gpg / sig.gpg.asc?
As in "let's not overload .asc to mean armored signature, when it only
means ASCII text"...

-- 
  Henrique Holschuh

Re: Upstream Tarball Signature Files

[Russ Allbery]

Henrique de Moraes Holschuh  writes:
> On Sun, 13 Aug 2017, Russ Allbery wrote:

>> it can't just move the file -- it has to ASCII-armor it.  But still, I
>> think that's the right thing for the tools to do, not add another file.
>> (The ASCII format is completely equivalent to the binary format; the
>> conversion shouldn't lose or change any data.)

> The armor just wastes space, and will do so for every signature in the
> archive.

I very much doubt we will ever notice such a tiny amount of overhead.

> Why are we not using binary signatures in the first place, if we're
> going to mandate conversions?

We could go that route too, but I don't think the benefits are worth
changing the existing code that supports *.asc files.  But I certainly
wouldn't object if the folks doing the work wanted to change.  I just want
to support only one or the other.

-- 
Russ Allbery (r...@debian.org)   

Bug#872146: dpkg: dpkg --verify complains about /usr/share/man/man1/cpp.1.gz

[Sven Joachim]

Package: dpkg
Version: 1.18.24
Severity: normal

Something strange is happening here: "dpkg --verify" complains about the
file /usr/share/man/man1/cpp.1.gz (a symlink shipped in the cpp-doc
package), but only if the package containing it is _not_ given on the
commandline.

,
| $ dpkg -S /usr/share/man/man1/cpp.1.gz 
| cpp-doc: /usr/share/man/man1/cpp.1.gz
| $ dpkg --verify cpp-doc
| $ dpkg --verify 2>/dev/null | grep cpp
| ??5??   /usr/share/man/man1/cpp.1.gz
`


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.12.7-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-14
ii  liblzma5 5.2.2-1.3
ii  libselinux1  2.6-3+b2
ii  tar  1.29b-2
ii  zlib1g   1:1.2.8.dfsg-5

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.5~beta1
pn  debsig-verify  

-- Configuration Files:
/etc/dpkg/dpkg.cfg changed:
no-debsig
log /var/log/dpkg.log


-- no debconf information