Wouter Verhelst <wouter@debian.org> writes:

> On Wed, Mar 17, 2010 at 04:12:46PM -0700, Russ Allbery wrote:
>> Wouter Verhelst <wouter@debian.org> writes:
>>
>> > This is not true.
>>
>> > wouter@merkel:/org/ftp.debian.org/queue/done$ ls *ges|wc -l
>> > 28969
>>
>> > These are only the *active* changes files, though:
>>
>> > wouter@merkel:/org/ftp.debian.org/queue/done$ find . -name 'nbd*ges'|wc -l
>> > 898
>>
>> > ... since no .changes file is ever thrown away:
>>
>> > wouter@merkel:/org/ftp.debian.org/queue/done$ du -sh .
>> > 7.1G
>>
>> > They may not be visible on the mirrors, but they are there.
>>
>> Ah, thank you. I didn't realize that we kept them at all.
>>
>> Note, though, that if the concern is a cryptographically strong audit
>> trail, we could still retain a link from the original *.changes file to
>> the final package with a second (possibly signed) document archived with
>> the *.changes file listing the original and final checksums of the
>> now-signed packages.
>
> True.

False.

The changes files are signed by a human and therefor have a strong trust
level. The "was XYZ is now UVW" file would have to be automatically
signed and much less trustworthy. Esspecially if you suspect someone
broke into ftp-master and modified some debs. They would just recreate
and resign the "was XYZ is now UVW" file with the automatic archive key.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87eijif5fs.fsf@frosties.localdomain">http://lists.debian.org/87eijif5fs.fsf@frosties.localdomain

On Wed, Mar 17, 2010 at 02:36:31PM +0000, Simon McVittie wrote:
> On Wed, 17 Mar 2010 at 12:41:58 +0100, Harald Braumann wrote:
> > It should be signed at build time, just after dh_shasums and then the
> > sig file packaged together with all the other files. I don't see a
> > problem with that. Or maybe I'm not getting something here?
>
> Most packages (in terms of proportion of the archive, in particular for
> architectures other than i386 and amd64) are built by a buildd, so each buildd
> would have to have a signing key that could sign the checksums file during
> build. Further, the build part of a buildd runs inside a limited chroot
> running the target distribution, i.e. usually unstable (the "real system" runs
> stable with a backported version of sbuild), which doesn't have access to any
> key material in the "real system".
>
> At the moment buildds don't have their own keys: a buildd maintainer inspects
> the build log and signs the .changes file for upload.
>
> Even for maintainer uploads, maintainers who build their packages in a
> minimal chroot with schroot, pbuilder, cowbuilder etc. (which is strongly
> recommended) don't necessarily have their signing key available inside
> the chroot (nor should they!).

Thanks for explaining all these details.

> I build my packages with sbuild/schroot, and my GPG key isn't available inside
> the build system as a result of using gfcombinefs to split my key between my
> laptop and a USB stick (so that if either is stolen, my key isn't compromised).
> I'm told some developers take this further, and only store their key on a
> non-networked machine to which they transfer files for signing (the current
> package upload procedure makes this possible - they only really need to
> transfer the .changes file, in fact). I think it would be irresponsible to
> make it necessary for DDs to choose between weakening the security of their
> GPG keys, or producing less reproducible builds.

Theoretically you could produce rather short-lived keys that are
signed with your maintainer key, make those available in the build
environment and use them for signing. The signing key along with the
signature by the maintainer key would have to be included in the
package as well. But I guess that this would be a tad to complex and I
wouldn't propose it.

harry


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

On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote:
> Russ Allbery <rra@debian.org> writes:
>
> > Simon McVittie <smcv@debian.org> writes:
> >
> >> Most packages (in terms of proportion of the archive, in particular for
> >> architectures other than i386 and amd64) are built by a buildd, so each
> >> buildd would have to have a signing key that could sign the checksums
> >> file during build. Further, the build part of a buildd runs inside a
> >> limited chroot running the target distribution, i.e. usually unstable
> >> (the "real system" runs stable with a backported version of sbuild),
> >> which doesn't have access to any key material in the "real system".
> >
> >> At the moment buildds don't have their own keys: a buildd maintainer
> >> inspects the build log and signs the .changes file for upload.
> >
> >> Even for maintainer uploads, maintainers who build their packages in a
> >> minimal chroot with schroot, pbuilder, cowbuilder etc. (which is
> >> strongly recommended) don't necessarily have their signing key available
> >> inside the chroot (nor should they!).
> >
> > Signatures per buildd or per DD doing uploads are moderately interesting,
> > but not nearly as interesting as a signature by a long-term stable key
> > such as the archive key.
> >
> > Do we actually rely anywhere on packages not changing hashes between
> > upload and publication in the repository, or is it just something we have
> > as an invariant now because there's no reason for it not to be one? The
> > path of least resistance here would be for DAK to add the package
> > signature after verifying the signature of the uploader. This has the
> > drawback that it modifies the *.deb and therefore breaks the hashes in the
> > *.changes file and hence its original signature, but given that we throw
> > out the *.changes file anyway, do we actually care?
>
> The changes files are afaik archived somewhere and are needed to verify
> the archive integrity after a (feared) compromise.
>
> And what do you do when the archive key expires? Resign every deb in the
> archive and have every mirror download them all again?

Why? A signature doesn't become invalid just because the key
expires, as long as the signature was created before the expiration of
the key.

> Same problem on
> releases. Releasing a new stable means a new stable key so every deb
> needs to be signed again and changes. I don't think this is a good idea.
> This would also cause users (apt/aptitude actually) to reinstall the
> packages needlessly creating even more mirror load.
>
> For this to work the signature for the checksum files should be detached
> so that it can be changed/extended without altering the deb files.
>
> I suggested this before but lets repeat it. Why not include a digest of
> the checksum file in DEBIAN/control, carry it into the changes file and
> into Packages.gz. That way all current debs automatically have a clear
> trust path.
>
> Further the changes files could be included in the pool alongside the
> debs and source files. That way everyone can verify the autenticity of
> the debs (or just the checksum file) independent of the archive
> key. Going one step further the changes files could be signed by the
> archive key(s) as well. Adding a new signature to them when keys change
> does mean they need to be mirrored again but they are relatively small.

Self-contained packages, where the signature is included and installed
along with the checksum file, would have a lot of
advantages. You wouldn't need access to a lot of infrastructure just
to verify a signature. It would be very simple. It could be used for
packages, that are not part of Debian. For instance, I could produce a
package and send it to a friend and he could later use my key for
verification. The same holds for projects that publish deb files. With
your proposal they would need a full fledged archive and keep a long
history of all the files.

And what do you do with packages from testing/unstable/experimental?
Would you keep all incarnations of the Release/Packages/changes files?
And if I want to verify the signature of an installed file, from a
package I once installed from, say, unstable, how would I find the
right version of the changes file for the package?

Cheers,
harry


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

Goswin von Brederlow <goswin-v-b@web.de> writes:

> And what do you do when the archive key expires?

Why would you need to do anything at all when the archive key expires?
Keys don't become magically compromised or worthless just because they've
expired. All it means is that you can't trust the integrity of really old
signatures as much as you can trust the integrity of new ones.

> Same problem on releases. Releasing a new stable means a new
> stable key so every deb needs to be signed again and changes.

I don't see why. The only *.debs that we might need to resign are ones
where there have been no uploads for an entire release cycle and hence may
be released with expired signatures, and while there are a few of those,
that's a much smaller problem. You could even just do an all-arch binNMU
to deal with resigning those.

> For this to work the signature for the checksum files should be detached
> so that it can be changed/extended without altering the deb files.

We could do that as well, but it would require changing the binary package
format and the archive software to track an additional file, and I think
that's a much larger change.

> I suggested this before but lets repeat it. Why not include a digest of
> the checksum file in DEBIAN/control, carry it into the changes file and
> into Packages.gz. That way all current debs automatically have a clear
> trust path.

Multiple people have explained to you why this doesn't solve the problem:
it means that you lose your signature path as soon as the package is no
longer listed in Packages.

I'm not interested in new ways of authenticating packages that are still
current and still listed in Packages. That's a solved problem, and while
we can provide some moderate additional convenience, it's not really
enough to justify the work. I'm interested in ways of authenticating
packages that *aren't* listed in Packages, either because they're
unofficial or because they're old and have been superseded. That would be
a useful new feature.

> Further the changes files could be included in the pool alongside the
> debs and source files. That way everyone can verify the autenticity of
> the debs (or just the checksum file) independent of the archive
> key. Going one step further the changes files could be signed by the
> archive key(s) as well. Adding a new signature to them when keys change
> does mean they need to be mirrored again but they are relatively small.

That's an interesting idea. Yes, we could add additional signatures to
the *.changes file without any of this other impact. To solve the full
problem for the Debian archive, we'd need to provide all the *.changes
files for every *.deb that we've ever released, but thankfully they're
small.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d3z1h37v.fsf@windlord.stanford.edu">http://lists.debian.org/87d3z1h37v.fsf@windlord.stanford.edu

Goswin von Brederlow <goswin-v-b@web.de> writes:

> The changes files are signed by a human and therefor have a strong trust
> level. The "was XYZ is now UVW" file would have to be automatically
> signed and much less trustworthy.

This objection makes no sense to me. The archive key is *much* more
trusted in practice than the individual DD keys. Haven't you been
advocating using the Packages file for this purpose, which is signed by
exactly the same key that would be doing this signature?

> Esspecially if you suspect someone broke into ftp-master and modified
> some debs.

Which they can do just as easily if you rely only on Packages. Even more
easily, in fact.

The problems that you are citing here are problems that we already have;
that, in fact, are much worse now than they would be under that proposed
scheme. (However, I will note that your *.changes idea does offer some
additional protection there over the scheme that I was considering.)

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 878w9ph328.fsf@windlord.stanford.edu">http://lists.debian.org/878w9ph328.fsf@windlord.stanford.edu

On Wed, 2010-03-17 at 11:31 +0100, Wouter Verhelst wrote:
> On Wed, Mar 17, 2010 at 08:58:28AM +0100, Goswin von Brederlow wrote:
> > Wouter Verhelst <wouter@debian.org> writes:
> > > On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
> > >> Harald Braumann <harry@unheit.net> writes:
> > >> > On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst wrote:
> > >> >>
> > >> >> Having package.checksums be GPG-signed will take a significant change in
> > >> >> our infrastructure (buildd hosts, for instance, would need to have a way
> > >> >> to sign checksums files as well), so it's not going to happen
> > >> >> tomorrow.
> > >>
> > >> That can be avoided by including a hash of the checksum file in the
> > >> Packages files.
> > >
> > > That doesn't help for the problem we're trying to fix here: having a
> > > path to a GPG signature from an individual binary on the hard disk,
> > > months or years after the package was installed.
> > >
> > > With your proposal, you lose the signatures once the package is out of
> > > the archive and you run 'apt-get update'.
> >
> > Then don't do that.
>
> We can hardly say to our users "if you want to be able to check
> signatures, never run run apt-get update"...

Not necessarily. I assume that it would be easy (and cheap) to preserve
a copy of the previous:
http://ftp.debian.org/debian/dists/testing/InRelease
http://ftp.debian.org/debian/dists/testing/main/binary-i386/Packages.diff/*

It would then be possible to reverse apply the diff, and validate the
packages when needed. The disk-space cost would be quite low. Currently,
that's 448K for 6 days (27MB/year), which is quite cheap compared to
cached binaries that have to be preserved too.

(And it comes to my mind that it might be possible to implement some
roll-back feature... If we were supporting to downgrade packages to some
extend

I have no strong preferences between signed APT and SIGNED DEBs... it is
just that the remaining of the thread showed that signed DEBs are quite
tough to implement. (and I still wonder how we could preserve the
current deb format with "tar.gz in ar", while signing the debs)

That's 2 more cents from me,

Franklin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1268956013.11872.58.camel@solid.paris.klabs.be">ht tp://lists.debian.org/1268956013.11872.58.camel@solid.paris.klabs.be

Frank Lin PIAT <fpiat@klabs.be> writes:

> I have no strong preferences between signed APT and SIGNED DEBs... it is
> just that the remaining of the thread showed that signed DEBs are quite
> tough to implement. (and I still wonder how we could preserve the
> current deb format with "tar.gz in ar", while signing the debs)

You add an additional ar member that contains the signed checksums of all
of the files in data.tar.gz, possibly another additional member that
contains the signed checksums for control.tar.gz, or you document some
convention so that you can combine both into the same signed checksum
document.

There are other implementation methods possible, but that's probably the
most obvious one.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 871vfhchnc.fsf@windlord.stanford.edu">http://lists.debian.org/871vfhchnc.fsf@windlord.stanford.edu

On Thu, 2010-03-18 at 12:39 +0100, Harald Braumann wrote:
> On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote:
> > Russ Allbery <rra@debian.org> writes:
> > > Simon McVittie <smcv@debian.org> writes:
> >
> > >> Most packages (in terms of proportion of the archive, in particular for
> > >> architectures other than i386 and amd64) are built by a buildd, so each
> > >> buildd would have to have a signing key that could sign the checksums
> > >> file during build.
>
> Self-contained packages, where the signature is included and installed
> along with the checksum file, would have a lot of
> advantages. You wouldn't need access to a lot of infrastructure just
> to verify a signature. It would be very simple. It could be used for
> packages, that are not part of Debian. For instance, I could produce a
> package and send it to a friend and he could later use my key for
> verification.

Oh please no. Don't advocate sending individual .deb files, ever. This
practice should be strongly discouraged. One brilliant part of Debian
packaging *is* the APT infrastructure, some key features:

1. Security updates
2. Bug fixes
4. Dependency resolution
5. Smoother dist-upgrades because:
5a. The APT repository provides newer version, with updated
dependencies (libraries transitions...)
5b. The user don't have to visit each web site to dist-upgrade
6. Single GPG key to manage (revocation ; update...)
7. Single GPG key to trust (per repository)

If people and ISV start publishing individual .deb, they (and we) will
have to face the same problem as Windows/Mac/whatever had to solve: each
application will need to embed a feature to "Check for update", etc.

I am spending about 2 hours every two month on my parents computer, just
update all the damned Windows applications. Who really wants Debian to
go down that say.

I must say that if someone can't "setup" an APT repository to publish
packages, you should reconsider the installation of any package from
that person/ISV. (Reminder the Debian Policy has 135 pages, whom ever
can read and use it to create a proper package can also read a few
manpages to setup a repository). The same stand for RPM & co.


cat < /home/fpiat/2¢ >> debian-devel

Regards,

Franklin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1268986453.3488.183.camel@solid.paris.klabs.be">ht tp://lists.debian.org/1268986453.3488.183.camel@solid.paris.klabs.be

Harald Braumann <harry@unheit.net> writes:

> On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote:
>> Russ Allbery <rra@debian.org> writes:
>>
>> > Simon McVittie <smcv@debian.org> writes:
>> >
>> >> Most packages (in terms of proportion of the archive, in particular for
>> >> architectures other than i386 and amd64) are built by a buildd, so each
>> >> buildd would have to have a signing key that could sign the checksums
>> >> file during build. Further, the build part of a buildd runs inside a
>> >> limited chroot running the target distribution, i.e. usually unstable
>> >> (the "real system" runs stable with a backported version of sbuild),
>> >> which doesn't have access to any key material in the "real system".
>> >
>> >> At the moment buildds don't have their own keys: a buildd maintainer
>> >> inspects the build log and signs the .changes file for upload.
>> >
>> >> Even for maintainer uploads, maintainers who build their packages in a
>> >> minimal chroot with schroot, pbuilder, cowbuilder etc. (which is
>> >> strongly recommended) don't necessarily have their signing key available
>> >> inside the chroot (nor should they!).
>> >
>> > Signatures per buildd or per DD doing uploads are moderately interesting,
>> > but not nearly as interesting as a signature by a long-term stable key
>> > such as the archive key.
>> >
>> > Do we actually rely anywhere on packages not changing hashes between
>> > upload and publication in the repository, or is it just something we have
>> > as an invariant now because there's no reason for it not to be one? The
>> > path of least resistance here would be for DAK to add the package
>> > signature after verifying the signature of the uploader. This has the
>> > drawback that it modifies the *.deb and therefore breaks the hashes in the
>> > *.changes file and hence its original signature, but given that we throw
>> > out the *.changes file anyway, do we actually care?
>>
>> The changes files are afaik archived somewhere and are needed to verify
>> the archive integrity after a (feared) compromise.
>>
>> And what do you do when the archive key expires? Resign every deb in the
>> archive and have every mirror download them all again?
>
> Why? A signature doesn't become invalid just because the key
> expires, as long as the signature was created before the expiration of
> the key.
>
>> Same problem on
>> releases. Releasing a new stable means a new stable key so every deb
>> needs to be signed again and changes. I don't think this is a good idea.
>> This would also cause users (apt/aptitude actually) to reinstall the
>> packages needlessly creating even more mirror load.
>>
>> For this to work the signature for the checksum files should be detached
>> so that it can be changed/extended without altering the deb files.
>>
>> I suggested this before but lets repeat it. Why not include a digest of
>> the checksum file in DEBIAN/control, carry it into the changes file and
>> into Packages.gz. That way all current debs automatically have a clear
>> trust path.
>>
>> Further the changes files could be included in the pool alongside the
>> debs and source files. That way everyone can verify the autenticity of
>> the debs (or just the checksum file) independent of the archive
>> key. Going one step further the changes files could be signed by the
>> archive key(s) as well. Adding a new signature to them when keys change
>> does mean they need to be mirrored again but they are relatively small.
>
> Self-contained packages, where the signature is included and installed
> along with the checksum file, would have a lot of
> advantages. You wouldn't need access to a lot of infrastructure just
> to verify a signature. It would be very simple. It could be used for
> packages, that are not part of Debian. For instance, I could produce a
> package and send it to a friend and he could later use my key for
> verification. The same holds for projects that publish deb files. With
> your proposal they would need a full fledged archive and keep a long
> history of all the files.

You can always sign the deb. The tools to sign and verify are all
present. Only ftp-master stands in the way of using that.

And you could automatically download the changes files along with every
deb and keep all changes files for installed package/version
locally. Anyway, I don't consider a ftp/http client a lot of
infrastructure. It would be trivial to write a tool that downloads the
changes files for every installed package and verifies it.

> And what do you do with packages from testing/unstable/experimental?
> Would you keep all incarnations of the Release/Packages/changes files?
> And if I want to verify the signature of an installed file, from a
> package I once installed from, say, unstable, how would I find the
> right version of the changes file for the package?

All changes files are already kept. And you would go directly to
fetching the changes file for the package/version you have
installed. All it would need is for the changes file archive to become
public.

> Cheers,
> harry

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87wrx84pnz.fsf@frosties.localdomain">http://lists.debian.org/87wrx84pnz.fsf@frosties.localdomain

Russ Allbery <rra@debian.org> writes:

> Goswin von Brederlow <goswin-v-b@web.de> writes:
>
>> And what do you do when the archive key expires?
>
> Why would you need to do anything at all when the archive key expires?
> Keys don't become magically compromised or worthless just because they've
> expired. All it means is that you can't trust the integrity of really old
> signatures as much as you can trust the integrity of new ones.

s/expires/is compromised/

>> Same problem on releases. Releasing a new stable means a new
>> stable key so every deb needs to be signed again and changes.
>
> I don't see why. The only *.debs that we might need to resign are ones
> where there have been no uploads for an entire release cycle and hence may
> be released with expired signatures, and while there are a few of those,
> that's a much smaller problem. You could even just do an all-arch binNMU
> to deal with resigning those.

Packages are uploaded to unstable usualy and won't be signed by a stable
key at all. At most they get signed by the automatic archive key, which
is always in danger of being compromised. So on release every package
should be signed by the new stable key. Or at least all those that where
uploaded since the last release, which would be the majority.

>> For this to work the signature for the checksum files should be detached
>> so that it can be changed/extended without altering the deb files.
>
> We could do that as well, but it would require changing the binary package
> format and the archive software to track an additional file, and I think
> that's a much larger change.

Changes files are alraedy archived. Just make them public.

>> I suggested this before but lets repeat it. Why not include a digest of
>> the checksum file in DEBIAN/control, carry it into the changes file and
>> into Packages.gz. That way all current debs automatically have a clear
>> trust path.
>
> Multiple people have explained to you why this doesn't solve the problem:
> it means that you lose your signature path as soon as the package is no
> longer listed in Packages.

Which is why I kept writing the next paragraph.

> I'm not interested in new ways of authenticating packages that are still
> current and still listed in Packages. That's a solved problem, and while
> we can provide some moderate additional convenience, it's not really
> enough to justify the work. I'm interested in ways of authenticating
> packages that *aren't* listed in Packages, either because they're
> unofficial or because they're old and have been superseded. That would be
> a useful new feature.
>
>> Further the changes files could be included in the pool alongside the
>> debs and source files. That way everyone can verify the autenticity of
>> the debs (or just the checksum file) independent of the archive
>> key. Going one step further the changes files could be signed by the
>> archive key(s) as well. Adding a new signature to them when keys change
>> does mean they need to be mirrored again but they are relatively small.
>
> That's an interesting idea. Yes, we could add additional signatures to
> the *.changes file without any of this other impact. To solve the full
> problem for the Debian archive, we'd need to provide all the *.changes
> files for every *.deb that we've ever released, but thankfully they're
> small.

And exist for past debs as well.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87sk7w4pdx.fsf@frosties.localdomain">http://lists.debian.org/87sk7w4pdx.fsf@frosties.localdomain