On Wed, Mar 17, 2010 at 5:31 PM, Wouter Verhelst <w@uter.be> wrote:

>> But for packages no longer in the archive there is snapshot.debian.net
>> (or the official replacement).
>
> Which are both not very useful at the moment.

I've found http://snapshot-dev.debian.org quite useful recently.

--
bye,
pabs

http://wiki.debian.org/PaulWise


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

On Wed, Mar 17, 2010 at 08:58:28AM +0100, Goswin von Brederlow wrote:
> I don't think signing the checksum file itself will be feasable as that
> would alter the contents of the deb and change the checksums in the
> changes files autobuilders send the admin for signing. It would break
> the existing signing infrastructure for autobuilders. It would also
> require running dpkg-genchanges again during signing or otherwise adjust
> the checksums in the changes file.

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?

Cheers,
harry


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

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!).

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.

Another issue with signing automatically at build-time is that it gives
preliminary versions of a package the same level of authentication (signature)
as the uploaded version. It sometimes takes a few iterations to make a final
build of a package, so the workflow I use is to build an unsigned package and
test it. If it works well enough to be suitable for upload, I sign and upload
it; if it doesn't, I discard it, amend the source and repeat.

Simon


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100317143631.GA5556@reptile.pseudorandom.co.uk"> http://lists.debian.org/20100317143631.GA5556@reptile.pseudorandom.co.uk

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?

--
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: 87pr32zurw.fsf@windlord.stanford.edu">http://lists.debian.org/87pr32zurw.fsf@windlord.stanford.edu

On Wed, Mar 17, 2010 at 11:07:47AM -0700, Russ Allbery wrote:
> *.changes file and hence its original signature, but given that we throw
> out the *.changes file anyway,

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.

--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100317224016.GC15158@celtic.nixsys.be">http://lists.debian.org/20100317224016.GC15158@celtic.nixsys.be

On 2010-03-17, Wouter Verhelst <wouter@debian.org> wrote:
> On Wed, Mar 17, 2010 at 11:07:47AM -0700, Russ Allbery wrote:
>> *.changes file and hence its original signature, but given that we throw
>> out the *.changes file anyway,
> This is not true.
> They may not be visible on the mirrors, but they are there.

But, as far as I know, there is no connection from a file in the archive
to the corresponding .changes. It's true that they are somehow archived,
but not tracked.

Kind regards,
Philipp Kern


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrnhq2mtb.3t7.trash@kelgar.0x539.de">http://lists.debian.org/slrnhq2mtb.3t7.trash@kelgar.0x539.de

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.

--
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: 87ljdqtudt.fsf@windlord.stanford.edu">http://lists.debian.org/87ljdqtudt.fsf@windlord.stanford.edu

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.

--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100317231806.GE15158@celtic.nixsys.be">http://lists.debian.org/20100317231806.GE15158@celtic.nixsys.be

On Wed, 2010-03-17 at 23:40 +0100, Wouter Verhelst wrote:
> On Wed, Mar 17, 2010 at 11:07:47AM -0700, Russ Allbery wrote:
> > *.changes file and hence its original signature, but given that we throw
> > out the *.changes file anyway,
>
> 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.

Not that you'll be able to verify most of them, since the keyring only
contains keys that are accepted for new uploads.

Ben.

--
Ben Hutchings
One of the nice things about standards is that there are so many of them.

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? 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.

MfG
Goswin


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