On Thu, 15 Apr 2010, Goswin von Brederlow wrote:
> > My only wish at this point is to avoid exploding the number of
> > small administrative files in /var/lib/dpkg/info/ due to this new feature.
>
> The introduction of multiarch will need to change the way metadata is
> stored there. Since some change is needed anyway it might be a good time
> to adapt to the increase in files stored there and use some subdirs.
> Maybe even have one dir per package.

My concern is not about the number of files per directory, my concern is
the overall number of files eating 4 Kb of filesystem space for
a few hundreds of bytes each in reality.

> > The biggest downside in your approach is that it's somewhat painful to
> > ensure that all the content of the package is signed. If the checksums
> > files is incomplete, what is supposed to happen? Is that something that
> > dpkg should take care of or should that be outside the scope of dpkg?
>
> Yes, dpkg should create the checksum file.

Even if it creates a checksum file, someone could always hand-edit the
package to add files not listed in the checksum files and we need to
decide whether that's something that needs to be catched and if yes by
whom and at what point.

Cheers,
--
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100415150344.GA8065@rivendell">http://lists.debian.org/20100415150344.GA8065@rivendell

On Thu, 15 Apr 2010, Goswin von Brederlow wrote:
> > My only wish at this point is to avoid exploding the number of
> > small administrative files in /var/lib/dpkg/info/ due to this new feature.
>
> The introduction of multiarch will need to change the way metadata is
> stored there. Since some change is needed anyway it might be a good time
> to adapt to the increase in files stored there and use some subdirs.
> Maybe even have one dir per package.

My concern is not about the number of files per directory, my concern is
the overall number of files eating 4 Kb of filesystem space for
a few hundreds of bytes each in reality.

> > The biggest downside in your approach is that it's somewhat painful to
> > ensure that all the content of the package is signed. If the checksums
> > files is incomplete, what is supposed to happen? Is that something that
> > dpkg should take care of or should that be outside the scope of dpkg?
>
> Yes, dpkg should create the checksum file.

Even if it creates a checksum file, someone could always hand-edit the
package to add files not listed in the checksum files and we need to
decide whether that's something that needs to be catched and if yes by
whom and at what point.

Cheers,
--
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100415150344.GA8065@rivendell">http://lists.debian.org/20100415150344.GA8065@rivendell

On Thu, 15 Apr 2010, Stefano Zacchiroli wrote:
> On Thu, Apr 15, 2010 at 02:44:07PM +0200, Raphael Hertzog wrote:
> > On Tue, 23 Mar 2010, Wouter Verhelst wrote:
> > > The idea would be to provide a path from a binary on disk to a GPG
> > > signature for installed packages of which the user no longer has the
> > > .deb file from which it was originally installed, nor the Packages
> > > and/or Release.gpg file that was used to download it.
> >
> > Ok, it looks like a good goal.
>
> Now that snapshot.debian.org is officially deployed (and I can't stop
> thanking DSA and the other involved parties for that), let me highlight
> another potential advantage of reaching this goal.
>
> snapshot.d.o now has a really nice lookup interface from (SHA1) checksum
> to the actual file [1]. So having an easy tool to retrieve the (SHA1)
> checksum of a given file installed on disk would make trivial
> re-downloading the corresponding .deb even years later (which would be
> *awesome*).

Hu?! Retrieving the SHA1 checksum is done by running "sha1sum
/the/file"... I don't see what dpkg would bring here. Furthermore,
the content of a file might not change at each release which means it's
not a one-to-one mapping but a one-to-many mapping.

And snapshot stores the SHA1 of .deb, .dsc and related files but not the
content of the .deb.

I'm really confused at what you were trying to suggest.

Cheers,
--
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100415151439.GB8065@rivendell">http://lists.debian.org/20100415151439.GB8065@rivendell

On Thu, Apr 15, 2010 at 05:14:39PM +0200, Raphael Hertzog wrote:
> > > On Tue, 23 Mar 2010, Wouter Verhelst wrote:
> > > > The idea would be to provide a path from a binary on disk to a GPG
> > > > signature for installed packages of which the user no longer has the
> > > > .deb file from which it was originally installed, nor the Packages
> > > > and/or Release.gpg file that was used to download it.

<snip>

> Hu?! Retrieving the SHA1 checksum is done by running "sha1sum
> /the/file"... I don't see what dpkg would bring here. Furthermore,
> the content of a file might not change at each release which means it's
> not a one-to-one mapping but a one-to-many mapping.

The scenario suggested by Wouter quote above is that the user has
deleted *part* of an installed package (e.g. a mistaken "rm" somewhere
under /usr/share/package/), but she no longer has the corresponding
.deb. Under that assumption, while the user can "sha1sum /the/file", she
can no longer "sha1sum /the/.deb"; so there is no way to lookup
snapshot.d.o to retrieve the .deb.

It is my understanding that achieving the goal that you and Wouter
agreed upon would provide the step "/the/file" -->> checksum of the
owning .deb. If this is the case, the circle is closed.

> I'm really confused at what you were trying to suggest.

Any better? (even though it is not yet clear to me what was not clear in
my post, sorry about that)

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

On Thu, 15 Apr 2010, Stefano Zacchiroli wrote:
> On Thu, Apr 15, 2010 at 05:14:39PM +0200, Raphael Hertzog wrote:
> > > > On Tue, 23 Mar 2010, Wouter Verhelst wrote:
> > > > > The idea would be to provide a path from a binary on disk to a GPG
> > > > > signature for installed packages of which the user no longer has the
> > > > > .deb file from which it was originally installed, nor the Packages
> > > > > and/or Release.gpg file that was used to download it.
>
> <snip>
>
> > Hu?! Retrieving the SHA1 checksum is done by running "sha1sum
> > /the/file"... I don't see what dpkg would bring here. Furthermore,
> > the content of a file might not change at each release which means it's
> > not a one-to-one mapping but a one-to-many mapping.
>
> The scenario suggested by Wouter quote above is that the user has
> deleted *part* of an installed package (e.g. a mistaken "rm" somewhere
> under /usr/share/package/),

I did not read this in his words. I read that he wants to verify that the
installed files correspond to files that were signed by Debian without
having to keep around .deb files and/or Packages/Release files.

> It is my understanding that achieving the goal that you and Wouter
> agreed upon would provide the step "/the/file" -->> checksum of the
> owning .deb. If this is the case, the circle is closed.

Not in any straightforward way AFAIK. We get a checksum file for each
package listing the SHA1 of all installed files but that's all.

If you want the checksum of the "owning .deb" you have to record it at
installation time, you can't reconstruct it from the installed files even
with the new checksum file.

Cheers,
--
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100415161202.GB8478@rivendell">http://lists.debian.org/20100415161202.GB8478@rivendell

On Thu, Apr 15, 2010 at 05:03:44PM +0200, Raphael Hertzog wrote:

> Even if it creates a checksum file, someone could always hand-edit the
> package to add files not listed in the checksum files and we need to
> decide whether that's something that needs to be catched and if yes by
> whom and at what point.

Do you mean a maintainer, who hand-edits a package after it was
built, or do you mean an adversery who has evil intentions? If the
former, then this should just be forbidden. If the latter, than this
can be solved by package signatures.

harry


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100416010251.GA25023@sbs288.lan">http://lists.debian.org/20100416010251.GA25023@sbs288.lan

On Thu, Apr 15, 2010 at 05:03:44PM +0200, Raphael Hertzog wrote:

> Even if it creates a checksum file, someone could always hand-edit the
> package to add files not listed in the checksum files and we need to
> decide whether that's something that needs to be catched and if yes by
> whom and at what point.

Do you mean a maintainer, who hand-edits a package after it was
built, or do you mean an adversery who has evil intentions? If the
former, then this should just be forbidden. If the latter, than this
can be solved by package signatures.

harry


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100416010251.GA25023@sbs288.lan">http://lists.debian.org/20100416010251.GA25023@sbs288.lan

On Thu, Apr 15, 2010 at 04:04:51PM +0200, Goswin von Brederlow wrote:

> The checksum file could be attached as additional member in the
> .deb. And a signature could be a signed file containing the checksum
> size and name of all members of a .deb preceeding the signature. That
> way the signature can verify the deb itself or individual members, like
> the checksum file, in the .deb. Just a thought.

I'm not sure, how you mean that exactly. But the signature must be
over the checksum file, nothing more and nothing less. Otherwise
you won't be able to verify the checksum file.

Also I think it's really a very bad idea in general to mix multiple
different things into one signature. The one thing is a signature over
installed files (via the checksum file). The other is a signature over
a package. The two are completely orthogonal and serve different
purposes.

harry


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100416011001.GB25023@sbs288.lan">http://lists.debian.org/20100416011001.GB25023@sbs288.lan

On Thu, Apr 15, 2010 at 04:04:51PM +0200, Goswin von Brederlow wrote:

> The checksum file could be attached as additional member in the
> .deb. And a signature could be a signed file containing the checksum
> size and name of all members of a .deb preceeding the signature. That
> way the signature can verify the deb itself or individual members, like
> the checksum file, in the .deb. Just a thought.

I'm not sure, how you mean that exactly. But the signature must be
over the checksum file, nothing more and nothing less. Otherwise
you won't be able to verify the checksum file.

Also I think it's really a very bad idea in general to mix multiple
different things into one signature. The one thing is a signature over
installed files (via the checksum file). The other is a signature over
a package. The two are completely orthogonal and serve different
purposes.

harry


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100416011001.GB25023@sbs288.lan">http://lists.debian.org/20100416011001.GB25023@sbs288.lan

On Fri, 16 Apr 2010, Harald Braumann wrote:
> On Thu, Apr 15, 2010 at 05:03:44PM +0200, Raphael Hertzog wrote:
>
> > Even if it creates a checksum file, someone could always hand-edit the
> > package to add files not listed in the checksum files and we need to
> > decide whether that's something that needs to be catched and if yes by
> > whom and at what point.
>
> Do you mean a maintainer, who hand-edits a package after it was
> built, or do you mean an adversery who has evil intentions? If the

The latter.

> former, then this should just be forbidden. If the latter, than this
> can be solved by package signatures.

Which one? We are discussing something that is a signature of the (content
of the) package. And there's the signature on Release/Package which can
authenticate the .deb in its entirety.

I'm discussing the case where the signature of the "checksums" file is valid
but that checksums file does not list all the files present in
data.tar.gz or control.tar.gz.

Cheers,
--
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100416060813.GA12604@rivendell">http://lists.debian.org/20100416060813.GA12604@rivendell