Joey Hess [EMAIL PROTECTED] wrote:
Goswin von Brederlow wrote:
What can we do with deb signatures?
For our current problem, the integrity of the debian archive being
questioned, the procedure would be easy and available to every user:
1. get any clean Debian keyring (or just the key
Julian Mehnle [EMAIL PROTECTED] writes:
Joey Hess [EMAIL PROTECTED] wrote:
Goswin von Brederlow wrote:
What can we do with deb signatures?
For our current problem, the integrity of the debian archive being
questioned, the procedure would be easy and available to every user:
* Julian Mehnle ([EMAIL PROTECTED]) [031210 13:40]:
Joey Hess [EMAIL PROTECTED] wrote:
Goswin von Brederlow wrote:
What can we do with deb signatures?
For our current problem, the integrity of the debian archive being
questioned, the procedure would be easy and available to every
On Fri, 2003-12-05 at 22:46, Goswin von Brederlow wrote:
No it isn't. For it to be non-repudiable, you'd have to demonstrate that
the key has not been compromised; that the developer knew what he was
signing (as opposed to a trojaned gpg telling him one thing while doing
another); etc.
Scripsit Goswin von Brederlow [EMAIL PROTECTED]
If a package is compromised we can proof that the DD of the package
either is malicious or incompetent.
Say, we just had a major compromise on certain Debian machines. Pray
tell, who do you think this proves is malicious or incompetent? We'd
* Henning Makholm ([EMAIL PROTECTED]) [031206 13:25]:
Scripsit Goswin von Brederlow [EMAIL PROTECTED]
If a package is compromised we can proof that the DD of the package
either is malicious or incompetent.
Say, we just had a major compromise on certain Debian machines. Pray
tell, who do
First: There is now a version of debsigs that creats debs that the
apt-utils could cope with, see http://debsigs.turmzimmer.net/ (I tried
it with the unmodified apt-utils of woody).
* Goswin von Brederlow ([EMAIL PROTECTED]) [031202 04:55]:
I agree with you that every instance along the way to
Andreas Barth [EMAIL PROTECTED] writes:
First: There is now a version of debsigs that creats debs that the
apt-utils could cope with, see http://debsigs.turmzimmer.net/ (I tried
it with the unmodified apt-utils of woody).
* Goswin von Brederlow ([EMAIL PROTECTED]) [031202 04:55]:
I agree
Henning Makholm [EMAIL PROTECTED] writes:
Scripsit Goswin von Brederlow [EMAIL PROTECTED]
If a package is compromised we can proof that the DD of the package
either is malicious or incompetent.
Say, we just had a major compromise on certain Debian machines. Pray
tell, who do you think
Andreas Barth [EMAIL PROTECTED] writes:
* Henning Makholm ([EMAIL PROTECTED]) [031206 13:25]:
Scripsit Goswin von Brederlow [EMAIL PROTECTED]
If a package is compromised we can proof that the DD of the package
either is malicious or incompetent.
Say, we just had a major compromise
* Matt Zimmerman ([EMAIL PROTECTED]) [031204 22:25]:
On Thu, Dec 04, 2003 at 03:58:38PM -0500, Daniel Jacobowitz wrote:
On Thu, Dec 04, 2003 at 02:41:43PM -0500, Matt Zimmerman wrote:
What kind of real world attacks do signed debs prevent?
The only one which comes to mind is a rogue
On Thu, 4 Dec 2003 14:41:43 -0500, Matt Zimmerman [EMAIL PROTECTED] said:
On Thu, Dec 04, 2003 at 12:28:41PM -0600, Manoj Srivastava wrote:
On Thu, 4 Dec 2003 11:47:50 -0500, Matt Zimmerman [EMAIL PROTECTED]
said:
What kind of real world attacks do signed debs prevent? Not a
compromised
Matt Zimmerman [EMAIL PROTECTED] writes:
On Thu, Dec 04, 2003 at 03:03:39AM +0100, Goswin von Brederlow wrote:
Signed debs establish a trust chain from the buildd to the user and
from the buildd-admin/maintainer to the user as well as copy the
existing trust chain from ftp-master to the
Matt Zimmerman [EMAIL PROTECTED] writes:
On Wed, Dec 03, 2003 at 08:07:53AM +0100, Goswin von Brederlow wrote:
I wrote a little script that checks what apt things its installing
against what the control files of the debs say. I will test it with
some more fakes and then file it in the
On Fri, Dec 05, 2003 at 12:24:07AM +0100, Goswin von Brederlow wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
Release signing protects against a hostile or compromised mirror,
network, DNS server, proxy server, and a host of other, similar attacks,
and also prevents most forms of the
On Fri, 2003-12-05 at 04:54, Manoj Srivastava wrote:
The only one which comes to mind is a rogue Debian developer that
you do not wish to trust, even though the project trusts him.
Not quite. The signed deb is non-repudiable authorship -- nice
to know whence the software cometh.
Matt Zimmerman [EMAIL PROTECTED] writes:
On Fri, Dec 05, 2003 at 12:24:07AM +0100, Goswin von Brederlow wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
Release signing protects against a hostile or compromised mirror,
network, DNS server, proxy server, and a host of other, similar
Anthony DeRobertis [EMAIL PROTECTED] writes:
On Fri, 2003-12-05 at 04:54, Manoj Srivastava wrote:
The only one which comes to mind is a rogue Debian developer that
you do not wish to trust, even though the project trusts him.
Not quite. The signed deb is non-repudiable
* Wouter Verhelst ([EMAIL PROTECTED]) [031203 23:10]:
Op wo 03-12-2003, om 10:09 schreef Andreas Barth:
file back signed by the build admin. The debian archive scripts
accepts packages signed by a buildd-key only if it is a binary package
for this architecture, the key is valid (i.e.
Andreas Barth [EMAIL PROTECTED] writes:
* Wouter Verhelst ([EMAIL PROTECTED]) [031203 23:10]:
Op wo 03-12-2003, om 10:09 schreef Andreas Barth:
file back signed by the build admin. The debian archive scripts
accepts packages signed by a buildd-key only if it is a binary package
* Goswin von Brederlow ([EMAIL PROTECTED]) [031204 15:10]:
Andreas Barth [EMAIL PROTECTED] writes:
Ok?
Sounds ok but the upload rules can be tightened much much later. First
we have to get signing started, which means fixing apt-utils or
debsigs or preferably both. And of cause change
Andreas Barth [EMAIL PROTECTED] writes:
* Goswin von Brederlow ([EMAIL PROTECTED]) [031204 15:10]:
Andreas Barth [EMAIL PROTECTED] writes:
Ok?
Sounds ok but the upload rules can be tightened much much later. First
we have to get signing started, which means fixing apt-utils or
On Thu, Dec 04, 2003 at 03:03:39AM +0100, Goswin von Brederlow wrote:
Signed debs establish a trust chain from the buildd to the user and
from the buildd-admin/maintainer to the user as well as copy the
existing trust chain from ftp-master to the user into the deb itself.
The Release.gpg
On Thu, 4 Dec 2003 11:47:50 -0500, Matt Zimmerman [EMAIL PROTECTED] said:
What kind of real world attacks do signed debs prevent? Not a
compromised buildd, or a compromised maintainer's workstation.
It would allow me to copy .debs around with other people, or
use .debs not made
On Thu, Dec 04, 2003 at 12:28:41PM -0600, Manoj Srivastava wrote:
On Thu, 4 Dec 2003 11:47:50 -0500, Matt Zimmerman [EMAIL PROTECTED] said:
What kind of real world attacks do signed debs prevent? Not a
compromised buildd, or a compromised maintainer's workstation.
It would allow
On Thu, Dec 04, 2003 at 02:41:43PM -0500, Matt Zimmerman wrote:
On Thu, Dec 04, 2003 at 12:28:41PM -0600, Manoj Srivastava wrote:
On Thu, 4 Dec 2003 11:47:50 -0500, Matt Zimmerman [EMAIL PROTECTED] said:
What kind of real world attacks do signed debs prevent? Not a
compromised
On Thu, Dec 04, 2003 at 03:58:38PM -0500, Daniel Jacobowitz wrote:
On Thu, Dec 04, 2003 at 02:41:43PM -0500, Matt Zimmerman wrote:
What kind of real world attacks do signed debs prevent?
The only one which comes to mind is a rogue Debian developer that you do
not wish to trust, even
On Wed, Dec 03, 2003 at 08:07:53AM +0100, Goswin von Brederlow wrote:
I wrote a little script that checks what apt things its installing
against what the control files of the debs say. I will test it with
some more fakes and then file it in the BTS.
Why would you do this with a script rather
On Tue, Dec 02, 2003 at 02:02:19PM -0600, Steve Langasek wrote:
On Tue, Dec 02, 2003 at 06:05:44PM +0100, Andreas Metzler wrote:
Joey Hess [EMAIL PROTECTED] wrote:
Goswin von Brederlow wrote:
dpkg that it is downgrading the package, and a clever attacker might
avoid even that.
On Tue, Dec 02, 2003 at 10:16:32PM +0100, Matthias Urlichs wrote:
Hi, Henrique de Moraes Holschuh wrote:
On Tue, 02 Dec 2003, Wouter Verhelst wrote:
So unless you have a suggestion that would solve this particular issue,
I'm afraid this idea won't work in practice.
We could verify if
On Wed, Dec 03, 2003 at 06:50:09AM +0100, Goswin von Brederlow wrote:
Bernd Eckenfels [EMAIL PROTECTED] writes:
How often has this person glance over the results? As I understand debian
build daemons run unattended and build continously. Correct me when I am
wrong here.
But if I asume
Hi,
[ I'm Cc-ing Werner Koch on this ]
Wouter Verhelst:
On Tue, Dec 02, 2003 at 10:16:32PM +0100, Matthias Urlichs wrote:
Hi, Henrique de Moraes Holschuh wrote:
On Tue, 02 Dec 2003, Wouter Verhelst wrote:
So unless you have a suggestion that would solve this particular issue,
I'm
On Wed, Dec 03, 2003 at 12:08:10PM +0100, Matthias Urlichs wrote:
Wouter Verhelst:
Especially in the case of larger .debs, that would probably reduce the
actual signature size as well...
?? A hash is a hash, and should be independent of file size.
Obviously, sorry. I don't know how I got
* Chad Walstrom [EMAIL PROTECTED] [031202 18:14]:
I'm not following your logic, if that's what you call it. You're saying
that checking the current filesystem on a daily basis is NOT a good way
to verify filesystem integrity?
I say it won't give you an real advantage over checking the
Hi,
Werner Koch:
There are some minor problems because we don't just sign a hash but
need to add some more data. Creating an incomplete hash on the remote
machine is not the cleanest solution, so I have to come up with a
better way.
You're the GPG expert...
I'm also a bit concerned about
Wouter Verhelst [EMAIL PROTECTED] writes:
On Tue, Dec 02, 2003 at 10:16:32PM +0100, Matthias Urlichs wrote:
Hi, Henrique de Moraes Holschuh wrote:
On Tue, 02 Dec 2003, Wouter Verhelst wrote:
So unless you have a suggestion that would solve this particular issue,
I'm afraid this
Matthias Urlichs [EMAIL PROTECTED] writes:
Hi,
Werner Koch:
There are some minor problems because we don't just sign a hash but
need to add some more data. Creating an incomplete hash on the remote
machine is not the cleanest solution, so I have to come up with a
better way.
Hi,
Werner Koch:
On Wed, 3 Dec 2003 13:26:02 +0100, Matthias Urlichs said:
the local side is supposed to sign should probably be encrypted with the
signer's public key, otherwise I can just replace the data packet with
something that ends up signing a totally different file. :-/
And if
Bernd Eckenfels [EMAIL PROTECTED] writes:
On Wed, Dec 03, 2003 at 03:17:20AM +0100, Goswin von Brederlow wrote:
What the admins signature can gives us is a trusted timestamp and
another pair of eyes reading the changes files.
Well, a trusted timestamp can be added/required by a third
On Wed, 3 Dec 2003 12:08:10 +0100, Matthias Urlichs said:
signature algorithm would allow for hashing the data on the remote
machine, and signing that hash locally.
... that would work. It'd probably require a few hooks within GPG
to generate a hash packet / .
Since I moved my actual
On Wed, Dec 03, 2003 at 06:43:18AM +0100, Goswin von Brederlow wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
On Wed, Dec 03, 2003 at 03:07:17AM +0100, Goswin von Brederlow wrote:
But this kind of tampering _can_ be checked by apt before installing
the deb simply by adding a
Anthony Towns aj@azure.humbug.org.au writes:
On Tue, Dec 02, 2003 at 02:02:19PM -0600, Steve Langasek wrote:
You change the contents of the compromised Packages file, so that
Package: bash
is accompanied by
Filename: pool/main/b/bash/vulnerable-ident-server_1.0-1_i386.deb
which
Matt Zimmerman [EMAIL PROTECTED] writes:
On Wed, Dec 03, 2003 at 03:07:17AM +0100, Goswin von Brederlow wrote:
But this kind of tampering _can_ be checked by apt before installing
the deb simply by adding a signature verifyer into the
DPkg::Pre-Install-Pkgs config option, the same
* Goswin von Brederlow ([EMAIL PROTECTED]) [031203 03:25]:
Henning Makholm [EMAIL PROTECTED] writes:
If an attacker compromises the buildd to the point where he can gain
access to its secret key, he could just as well attack its build
environment, or simply use his access to convincingly
Op wo 03-12-2003, om 10:09 schreef Andreas Barth:
file back signed by the build admin. The debian archive scripts
accepts packages signed by a buildd-key only if it is a binary package
for this architecture, the key is valid (i.e. in the right year), and
this package has been handed
On Tue, Dec 02, 2003 at 02:02:19PM -0600, Steve Langasek wrote:
You change the contents of the compromised Packages file, so that
Package: bash
is accompanied by
Filename: pool/main/b/bash/vulnerable-ident-server_1.0-1_i386.deb
which contains a perfectly valid .deb file, signed by a DD, that
* Goswin von Brederlow ([EMAIL PROTECTED]) [031203 03:40]:
Andreas Barth [EMAIL PROTECTED] writes:
* Wouter Verhelst ([EMAIL PROTECTED]) [031202 19:40]:
So unless you have a suggestion that would solve this particular issue,
I'm afraid this idea won't work in practice.
Two suggestions
On Wed, Dec 03, 2003 at 06:50:09AM +0100, Goswin von Brederlow wrote:
[TSP]
If there is no person sitting there signing it manually its useless.
Why is that? I trust an automated service to provide me signed timestamps. In
fact
a Box doing exactly this and nothing else can be very securely
On Wed, 3 Dec 2003 13:26:02 +0100, Matthias Urlichs said:
I'm also a bit concerned about MitM attacks; the hash-or-whatever which
Obviously you can do this only using a secure channel.
the local side is supposed to sign should probably be encrypted with the
signer's public key, otherwise I
Matt Zimmerman [EMAIL PROTECTED] writes:
On Wed, Dec 03, 2003 at 06:43:18AM +0100, Goswin von Brederlow wrote:
Matt Zimmerman [EMAIL PROTECTED] writes:
On Wed, Dec 03, 2003 at 03:07:17AM +0100, Goswin von Brederlow wrote:
But this kind of tampering _can_ be checked by apt
Wouter Verhelst [EMAIL PROTECTED] writes:
Op wo 03-12-2003, om 10:09 schreef Andreas Barth:
file back signed by the build admin. The debian archive scripts
accepts packages signed by a buildd-key only if it is a binary package
for this architecture, the key is valid (i.e. in the
Martin Michlmayr ([EMAIL PROTECTED]) wrote:
* Thomas Viehmann [EMAIL PROTECTED] [2003-12-01 15:30]:
BTW: This is offtopic, but it seems that potato is neither in debian/
nor in debian-archive/?
Potato is on archive.debian.org (in /debian-archive/dists).
Ah. Thanks.
* Goswin von Brederlow ([EMAIL PROTECTED]) [031202 04:55]:
Andreas Barth [EMAIL PROTECTED] writes:
Technical details should IMHO be discussed later, but a sample
passport could look like:
accepted by katie on Mon, 1 Dec 2003 20:34:58 + because of good
signature of DD, KeyID
* Joey Hess ([EMAIL PROTECTED]) [031202 02:55]:
Goswin von Brederlow wrote:
What can we do with deb signatures?
For our current problem, the integrity of the debian archive being
questioned, the procedure would be easy and available to every user:
1. get any clean Debian keyring (or
On Tue, Dec 02, 2003 at 11:07:53AM +0100, Andreas Barth wrote:
* Joey Hess ([EMAIL PROTECTED]) [031202 02:55]:
Goswin von Brederlow wrote:
What can we do with deb signatures?
For our current problem, the integrity of the debian archive being
questioned, the procedure would be easy
Moin Goswin!
Goswin von Brederlow schrieb am Tuesday, den 02. December 2003:
I would like to see the following things happen:
- current md5sums file in control.tar.gz should contain
checksums of really all files
- a signature of the md5sums file should be stored either in
Joey Hess [EMAIL PROTECTED] writes:
John Goerzen wrote:
Please check out the debsigs package. I wrote it when I worked at
Progeny back in 2001, and Branden Robinson maintains it these days. It
does exactly that.
Unfortunatly, the method debsigs uses to add the signature to the .deb
Eduard Bloch [EMAIL PROTECTED] writes:
Moin Goswin!
Goswin von Brederlow schrieb am Tuesday, den 02. December 2003:
I would like to see the following things happen:
- current md5sums file in control.tar.gz should contain
checksums of really all files
- a signature of the
Andreas Barth [EMAIL PROTECTED] writes:
* Joey Hess ([EMAIL PROTECTED]) [031202 02:55]:
Goswin von Brederlow wrote:
What can we do with deb signatures?
For our current problem, the integrity of the debian archive being
questioned, the procedure would be easy and available to every
Tom [EMAIL PROTECTED] writes:
On Tue, Dec 02, 2003 at 11:07:53AM +0100, Andreas Barth wrote:
* Joey Hess ([EMAIL PROTECTED]) [031202 02:55]:
Goswin von Brederlow wrote:
What can we do with deb signatures?
For our current problem, the integrity of the debian archive being
On Tue, Dec 02, 2003 at 01:17:58PM +0100, Goswin von Brederlow wrote:
Tom [EMAIL PROTECTED] writes:
What precautions are taken that the DD actually signed it with the DD's
private key?
Set aside the possibility that the DD herself is actually the attacker.
You never can. But once the
* Chad Walstrom [EMAIL PROTECTED] [031201 22:28]:
md5sums and signatures are most useful in the context of installation.
Post-installation, you cannot be guaranteed that an intrusion rootkit
doesn't compromise the md5sum files themselves. Using the installed
*.md5sum files to check the
Tom [EMAIL PROTECTED] writes:
On Tue, Dec 02, 2003 at 01:17:58PM +0100, Goswin von Brederlow wrote:
Tom [EMAIL PROTECTED] writes:
What precautions are taken that the DD actually signed it with the DD's
private key?
Set aside the possibility that the DD herself is actually the
On Tue, Dec 02, 2003 at 02:20:43PM +0100, Goswin von Brederlow wrote:
There is no security as strong as many people reading the source over
and over. You can't hack their brains to skip over the backdoor code
and you can only obfuscate a backdoor so much.
Allright, allright, I'll cry uncle.
On Tue, Dec 02, 2003 at 11:07:53AM +0100, Andreas Barth wrote:
The canoical attack against signed debs in this situation is to find a
signed deb on snapshot.debian.net that contains a known security hole.
To avoid this attack, it is necessary that the filename of the deb or
the version of
Goswin von Brederlow wrote:
dpkg that it is downgrading the package, and a clever attacker might
avoid even that.
How would you avoid it?
Make the replacement package really be a different package entirely, of
a higher version than the package it purports to replace.
I think aj had some
Scripsit Goswin von Brederlow [EMAIL PROTECTED]
There is no security as strong as many people reading the source over
and over. You can't hack their brains to skip over the backdoor code
and you can only obfuscate a backdoor so much.
I refer you to Ken Thompson's Turing award lecture. If
On Tue, Dec 02, 2003 at 02:01:23PM +0100, Bernhard R. Link wrote:
A true IDS is needed, such as aide, tripwire, or cfengine to detect
post-installation intrusion. Tie in aide or tripwire database
checks/updates with the apt.conf PostInst option in addition to a
daily cronjon to ensure the
Op ma 01-12-2003, om 14:34 schreef Goswin von Brederlow:
[...]
Deb signatures method C:
And now for something completly different. A man with 3 noses. :)
Instead of keeping extra files with the signature of the deb the
information could be stored inside the deb itself.
[...]
As much as I
Joey Hess [EMAIL PROTECTED] wrote:
Goswin von Brederlow wrote:
dpkg that it is downgrading the package, and a clever attacker might
avoid even that.
How would you avoid it?
Make the replacement package really be a different package entirely, of
a higher version than the package it
Goswin von Brederlow wrote:
Joey Hess [EMAIL PROTECTED] writes:
I submitted a one line patch to apt to fix this and behave like
dpkg. I hope this gets added soon. Till then its either signed debs or
pre-configuring of packages.
I filed bugs about this a long time ago, it is apparently
On Tue, 02 Dec 2003, Wouter Verhelst wrote:
So unless you have a suggestion that would solve this particular issue,
I'm afraid this idea won't work in practice.
We could verify if the gpg agent (gpa? I forget the name...) cannot do this
over a secure channel. It should be able to, and if not,
No Cc was necessary, I am subscribed to debian-devel.
On Tue, 2003-12-02 at 03:30, Goswin von Brederlow wrote:
Scott James Remnant [EMAIL PROTECTED] writes:
A compromised dinstall on ftp-master could also replace the keyring
package with a new one containing an extra key, used to sign the
Wouter Verhelst wrote:
Requiring us to log in to the autobuilder to sign the .deb remotely is
not acceptable, for two reasons:
* it's way too much work for most of us
* it requires copying the secret key over, which is, uh, a bad idea.
An alternative would be to copy over the .debs, sign
Andreas Metzler wrote:
I still don't understand how you change the version number (or the
package-name) without breaking the signature.
Which signature? The Packages file is being modified, so of course the
hain of trust back to the Release file signature can be used to catch
tampering with it.
On Tue, Dec 02, 2003 at 06:05:44PM +0100, Andreas Metzler wrote:
Joey Hess [EMAIL PROTECTED] wrote:
Goswin von Brederlow wrote:
dpkg that it is downgrading the package, and a clever attacker might
avoid even that.
How would you avoid it?
Make the replacement package really be a
Scripsit Wouter Verhelst [EMAIL PROTECTED]
Requiring us to log in to the autobuilder to sign the .deb remotely is
not acceptable, for two reasons:
* it's way too much work for most of us
* it requires copying the secret key over, which is, uh, a bad idea.
Um, perhaps this is really stupid
* Wouter Verhelst ([EMAIL PROTECTED]) [031202 19:40]:
As much as I like this idea in principle, storing signatures inside
.debs has a serious problem: it won't work for us buildd maintainers.
Workability for the buildd maintainers is IMHO _certainly_ one
important thing.
As I explain in my
Hi, Henrique de Moraes Holschuh wrote:
On Tue, 02 Dec 2003, Wouter Verhelst wrote:
So unless you have a suggestion that would solve this particular issue,
I'm afraid this idea won't work in practice.
We could verify if the gpg agent (gpa? I forget the name...) cannot do this
over a secure
* Steve Langasek ([EMAIL PROTECTED]) [031202 22:10]:
AFAIK, apt does not sanity check the relationship between package names
and filenames (and it's not obvious that this should be part of its
responsibilities), and dpkg only gets a list of .debs to install once
they've been downloaded.
So
Henning Makholm [EMAIL PROTECTED] writes:
Scripsit Goswin von Brederlow [EMAIL PROTECTED]
There is no security as strong as many people reading the source over
and over. You can't hack their brains to skip over the backdoor code
and you can only obfuscate a backdoor so much.
I refer
Steve Langasek [EMAIL PROTECTED] wrote:
On Tue, Dec 02, 2003 at 06:05:44PM +0100, Andreas Metzler wrote:
Joey Hess [EMAIL PROTECTED] wrote:
Goswin von Brederlow wrote:
dpkg that it is downgrading the package, and a clever attacker might
avoid even that.
How would you avoid it?
Make
Scripsit Goswin von Brederlow
Henning Makholm [EMAIL PROTECTED] writes:
I refer you to Ken Thompson's Turing award lecture. If someone who
really means business manages to compromise binary toolchain debs, all
the hackers in the world reading source over and over will not find
the
Wouter Verhelst [EMAIL PROTECTED] writes:
Op ma 01-12-2003, om 14:34 schreef Goswin von Brederlow:
[...]
Deb signatures method C:
And now for something completly different. A man with 3 noses. :)
Instead of keeping extra files with the signature of the deb the
information could be
Andreas Metzler [EMAIL PROTECTED] writes:
Joey Hess [EMAIL PROTECTED] wrote:
Goswin von Brederlow wrote:
dpkg that it is downgrading the package, and a clever attacker might
avoid even that.
How would you avoid it?
Make the replacement package really be a different package
Chad Walstrom [EMAIL PROTECTED] writes:
On Tue, Dec 02, 2003 at 02:01:23PM +0100, Bernhard R. Link wrote:
A true IDS is needed, such as aide, tripwire, or cfengine to detect
post-installation intrusion. Tie in aide or tripwire database
checks/updates with the apt.conf PostInst option
Scott James Remnant [EMAIL PROTECTED] writes:
No Cc was necessary, I am subscribed to debian-devel.
On Tue, 2003-12-02 at 03:30, Goswin von Brederlow wrote:
Scott James Remnant [EMAIL PROTECTED] writes:
A compromised dinstall on ftp-master could also replace the keyring
package
Joey Hess [EMAIL PROTECTED] writes:
Andreas Metzler wrote:
I still don't understand how you change the version number (or the
package-name) without breaking the signature.
Which signature? The Packages file is being modified, so of course the
hain of trust back to the Release file
Henning Makholm [EMAIL PROTECTED] writes:
Scripsit Wouter Verhelst [EMAIL PROTECTED]
Requiring us to log in to the autobuilder to sign the .deb remotely is
not acceptable, for two reasons:
* it's way too much work for most of us
* it requires copying the secret key over, which is, uh,
On Wed, Dec 03, 2003 at 03:17:20AM +0100, Goswin von Brederlow wrote:
What the admins signature can gives us is a trusted timestamp and
another pair of eyes reading the changes files.
Well, a trusted timestamp can be added/required by a third party. No need to
bother a build admin with signing
Andreas Barth [EMAIL PROTECTED] writes:
* Wouter Verhelst ([EMAIL PROTECTED]) [031202 19:40]:
So unless you have a suggestion that would solve this particular issue,
I'm afraid this idea won't work in practice.
Two suggestions come to my mind. However, I can't judge how useful
they are
Henning Makholm [EMAIL PROTECTED] writes:
Scripsit Goswin von Brederlow
Henning Makholm [EMAIL PROTECTED] writes:
I refer you to Ken Thompson's Turing award lecture. If someone who
really means business manages to compromise binary toolchain debs, all
the hackers in the world
On Wed, Dec 03, 2003 at 03:07:17AM +0100, Goswin von Brederlow wrote:
But this kind of tampering _can_ be checked by apt before installing
the deb simply by adding a signature verifyer into the
DPkg::Pre-Install-Pkgs config option, the same mechanism
apt-listchanges already uses to display
On Wed, 2003-12-03 at 01:52, Goswin von Brederlow wrote:
Scott James Remnant [EMAIL PROTECTED] writes:
No Cc was necessary, I am subscribed to debian-devel.
I can only assume you ignored this out of either spite or stupidity.
I don't mind too much if people forget the code of conduct
Scott James Remnant [EMAIL PROTECTED] writes:
On Wed, 2003-12-03 at 01:52, Goswin von Brederlow wrote:
Scott James Remnant [EMAIL PROTECTED] writes:
No Cc was necessary, I am subscribed to debian-devel.
I can only assume you ignored this out of either spite or stupidity.
I
On Mon, Dec 01, 2003 at 03:30:58PM +0100, Thomas Viehmann wrote:
However: As md5sum my.deb ; ar q my.deb _deb_signature ; ar d my.deb
_deb_signature ; md5sum my.deb gives two different lines, I'd think
signing the individual members of the deb, not the deb in itself is
Please check out the
On Mon, 2003-12-01 at 13:34, Goswin von Brederlow wrote:
We have no continous trust chain going from the maintainer (also
meaning buildd + admin), ftp-master.d.o, mirrors to the user. A
compromised dinstall on master could replace binary uploads with
trojan versions without any user being
On Mon, Dec 01, 2003 at 03:56:59PM +, Scott James Remnant wrote:
Assuming that level of compromise, there's no recent to suspect that
they couldn't have free reign adding anything to the archive they
wanted. Signed .debs gain you nothing here.
If every .deb must be signed by a developer,
#include hallo.h
John Goerzen schrieb am Monday, den 01. December 2003:
Debsigs generates its signature by effectively cating the control and
data components of the ar file together, running that through gpg, and
storing the resulting signature data in a new component of the ar file.
I did
On Mon, Dec 01, 2003 at 05:00:53PM +, Scott James Remnant wrote:
No Cc was necessary, I am subscribed to debian-devel.
Please set your Mail-Followup-To accordingly, then.
If every .deb must be signed by a developer, and we assume that no
developer leaves secret keys on public machines,
1 - 100 of 130 matches
Mail list logo
