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
On Fri, Apr 16, 2010 at 08:08:13AM +0200, Raphael Hertzog wrote:
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.
Require that checksums exist for all files and let dpkg
Harald Braumann ha...@unheit.net writes:
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
Raphael Hertzog hert...@debian.org writes:
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
Hi Wouter,
I followed somewhat the discussion and I'm sorry for the delay
answering but package signatures are quite low in priority
in our roadmap currently:
http://wiki.debian.org/Teams/Dpkg/RoadMap
We would be glad however if someone would lead this project. I think this
project would benefit
Raphael Hertzog hert...@debian.org writes:
Hi Wouter,
I followed somewhat the discussion and I'm sorry for the delay
answering but package signatures are quite low in priority
in our roadmap currently:
http://wiki.debian.org/Teams/Dpkg/RoadMap
We would be glad however if someone would
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
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
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
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
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
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
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
On Sat, Mar 20, 2010 at 01:27:52PM +0100, Harald Braumann wrote:
On Fri, Mar 19, 2010 at 05:56:40PM -0700, Russ Allbery wrote:
Harald Braumann ha...@unheit.net writes:
On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote:
You add an additional ar member that contains the signed
On Fri, Mar 19, 2010 at 05:56:40PM -0700, Russ Allbery wrote:
Harald Braumann ha...@unheit.net writes:
On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote:
You add an additional ar member that contains the signed checksums of
all of the files in data.tar.gz, possibly another
Harald Braumann ha...@unheit.net writes:
On Fri, Mar 19, 2010 at 05:56:40PM -0700, Russ Allbery wrote:
I think it would replace dh_*sums during package build time and make
obsolete including md5sums in the control.tar.gz. You don't really
want the signature and checksums to be inside one of
On Sat, Mar 20, 2010 at 06:13:14AM -0700, Russ Allbery wrote:
Yeah, that would be one such convention. I don't know if that's better or
if adding a prefix of data: and control: to the path names would be
better. My guess is that the latter may be a bit more flexible for
possible long-term
Harald Braumann ha...@unheit.net writes:
On Sat, Mar 20, 2010 at 06:13:14AM -0700, Russ Allbery wrote:
Yeah, that would be one such convention. I don't know if that's better
or if adding a prefix of data: and control: to the path names would be
better. My guess is that the latter may be a
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 r...@debian.org writes:
Simon McVittie s...@debian.org writes:
Most packages (in terms of proportion of the archive, in particular for
Harald Braumann ha...@unheit.net writes:
On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote:
Russ Allbery r...@debian.org writes:
Simon McVittie s...@debian.org writes:
Most packages (in terms of proportion of the archive, in particular for
architectures other than
Russ Allbery r...@debian.org writes:
Goswin von Brederlow goswin-...@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.
Russ Allbery r...@debian.org writes:
Goswin von Brederlow goswin-...@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
On Fri, Mar 19, 2010 at 09:14:13AM +0100, Frank Lin PIAT wrote:
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 r...@debian.org writes:
Simon McVittie s...@debian.org writes:
Most packages
On Fri, Mar 19, 2010 at 10:38:24AM +0100, Goswin von Brederlow wrote:
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.
I would love signed debs. But this is orthogonal to signed checksum
files and should probably
On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote:
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
On Fri, Mar 19, 2010 at 09:14:13AM +0100, Frank Lin PIAT wrote:
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 r...@debian.org writes:
Simon McVittie s...@debian.org writes:
Most packages
Wouter Verhelst wrote:
On Fri, Mar 19, 2010 at 09:14:13AM +0100, Frank Lin PIAT wrote:
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 r...@debian.org writes:
Simon McVittie s...@debian.org
On Fri, 2010-03-19 at 17:40 +0100, Wouter Verhelst wrote:
On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote:
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
On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote:
Frank Lin PIAT fp...@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
Harald Braumann ha...@unheit.net writes:
On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote:
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
Russ Allbery r...@debian.org writes:
Simon McVittie s...@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
Wouter Verhelst wou...@debian.org writes:
On Wed, Mar 17, 2010 at 04:12:46PM -0700, Russ Allbery wrote:
Wouter Verhelst wou...@debian.org writes:
This is not true.
wou...@merkel:/org/ftp.debian.org/queue/done$ ls *ges|wc -l
28969
These are only the *active* changes files, though:
On Wed, Mar 17, 2010 at 02:36:31PM +, 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
On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote:
Russ Allbery r...@debian.org writes:
Simon McVittie s...@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
Goswin von Brederlow goswin-...@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
Goswin von Brederlow goswin-...@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
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 wou...@debian.org writes:
On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
Harald Braumann ha...@unheit.net writes:
On
Frank Lin PIAT fp...@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
Wouter Verhelst wou...@debian.org writes:
On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
Harald Braumann ha...@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
On Wed, Mar 17, 2010 at 08:58:28AM +0100, Goswin von Brederlow wrote:
Wouter Verhelst wou...@debian.org writes:
On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
Harald Braumann ha...@unheit.net writes:
On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst
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,
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
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
Simon McVittie s...@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
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.
wou...@merkel:/org/ftp.debian.org/queue/done$ ls *ges|wc -l
28969
These are only the *active* changes files,
On 2010-03-17, Wouter Verhelst wou...@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
Wouter Verhelst wou...@debian.org writes:
This is not true.
wou...@merkel:/org/ftp.debian.org/queue/done$ ls *ges|wc -l
28969
These are only the *active* changes files, though:
wou...@merkel:/org/ftp.debian.org/queue/done$ find . -name 'nbd*ges'|wc -l
898
... since no .changes file is
On Wed, Mar 17, 2010 at 04:12:46PM -0700, Russ Allbery wrote:
Wouter Verhelst wou...@debian.org writes:
This is not true.
wou...@merkel:/org/ftp.debian.org/queue/done$ ls *ges|wc -l
28969
These are only the *active* changes files, though:
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.
wou...@merkel:/org/ftp.debian.org/queue/done$
On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
Harald Braumann ha...@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
On Thu, 2010-03-11 at 00:37 +, The Fungi wrote:
On Wed, Mar 10, 2010 at 11:22:00PM +0100, Frank Lin PIAT wrote:
I made some tests, and it seems that we could allow,but not require, GPG
signed checksum-file. sha256sum will ignore invalid lines by default
(unless you specify --warn
On Wed, Mar 10, 2010 at 11:13:31AM -0600, Peter Samuelson wrote:
[Wouter Verhelst]
At any rate, a PGP signature takes a lot of data; much more so than
a checksum. It's therefore more economical to produce a signed
package.checksums file than it is to produce a package.pgpsigs.
Huh?
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.
I was
Harald Braumann ha...@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
Goswin von Brederlow goswin-...@web.de 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),
On Mon, Mar 08, 2010 at 12:59:00PM -0800, Russ Allbery wrote:
Frank Lin PIAT fp...@klabs.be writes:
Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
recent checksum.
The way it is implemented, is that the dh_md5sums is a symlink to the
new dh_checksums. The new
[Wouter Verhelst]
At any rate, a PGP signature takes a lot of data; much more so than
a checksum. It's therefore more economical to produce a signed
package.checksums file than it is to produce a package.pgpsigs.
Huh? Since asymmetric cryptography is so computationally expensive,
PGP never
Peter Samuelson pe...@p12n.org writes:
[Wouter Verhelst]
At any rate, a PGP signature takes a lot of data; much more so than
a checksum. It's therefore more economical to produce a signed
package.checksums file than it is to produce a package.pgpsigs.
Huh? Since asymmetric cryptography is
Hello,
On Mon, 2010-03-08 at 17:36 +0100, Frank Lin PIAT wrote:
On Thu, 2010-03-04 at 20:08 +0100, Tollef Fog Heen wrote:
Frank Lin PIAT wrote:
What about a transitional dh_md5sums that would produce md5sum AND
invoke dh_sha ?
Or call it dh_checksums or something so we don't have
On Wed, 2010-03-10 at 10:52 -0800, Russ Allbery wrote:
Peter Samuelson pe...@p12n.org writes:
[Wouter Verhelst]
At any rate, a PGP signature takes a lot of data; much more so than
a checksum. It's therefore more economical to produce a signed
package.checksums file than it is to
On Wed, Mar 10, 2010 at 11:22:00PM +0100, Frank Lin PIAT wrote:
I made some tests, and it seems that we could allow,but not require, GPG
signed checksum-file. sha256sum will ignore invalid lines by default
(unless you specify --warn option).
Similarly, the policy could state that GPG
[despite having not yet replied to this thread, I am watching it...I
just don't have the desire to add to yet another giant, silly thread on
-devel. anyways...]
On Mon, Mar 08, 2010 at 12:21:42PM -0500, Joey Hess wrote:
Your comments on the patch are obviously welcome (feel free to hack
On Mon, 2010-03-08 at 19:57 -0800, Russ Allbery wrote:
Joey Hess jo...@debian.org writes:
Russ Allbery wrote:
It's also always worth bearing in mind that while a really good
attacker can do all sorts of complex things that make them very hard to
find, most attackers are stupid and
On 09/03/2010 14:24, Bernhard R. Link wrote:
It it's that straight forward, please help with the cruft package.
Last time I looked (several years ago) it was severly limited by that
problem (there not being a way to know which files should be there and
which not).
I personally think
On Mon, Mar 08, 2010 at 10:49:54PM -0500, Joey Hess wrote:
Russ Allbery wrote:
It's also always worth bearing in mind that while a really good attacker
can do all sorts of complex things that make them very hard to find, most
attackers are stupid and straightforward.
It's stupid and
* Harald Braumann ha...@unheit.net [100309 13:59]:
On Mon, Mar 08, 2010 at 10:49:54PM -0500, Joey Hess wrote:
Russ Allbery wrote:
It's also always worth bearing in mind that while a really good attacker
can do all sorts of complex things that make them very hard to find, most
attackers
* Peter Samuelson pe...@p12n.org, 2010-03-09, 08:21:
[Frank Lin PIAT]
Why is that everyone seems to move away from MD5?
That's the $64000 question, isn't it? There seems to be this knee-jerk
reaction to all things md5, OH NOES, MD5 is broken! Therefore it must
be replaced in every possible
On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote:
If we take option 2, SHA256 offers no benefits over MD5 and just takes
longer to compute.
[Frank Lin PIAT]
Why is that everyone seems to move away from MD5?
That's the $64000 question, isn't it? There seems to be this knee-jerk
[Frank Lin PIAT]
Please, let's do the easy move *now* for Squeeze, using shasums, and
go ahead later with an even better solution.
Drawbacks: more CPU time on build daemons, slightly larger binary
packages to download, and some disruption when we're trying to get a
release out the door.
Harald Braumann wrote:
On Mon, Mar 08, 2010 at 10:49:54PM -0500, Joey Hess wrote:
It's stupid and straightforward to install /usr/local/bin/ls. debsums
will not detect it.
And it's as straightforward to find files which don't belong to any
package and have some other means in place to
On Tue, Mar 09 2010, Jean-Christophe Dubacq wrote:
On 09/03/2010 14:24, Bernhard R. Link wrote:
It it's that straight forward, please help with the cruft package.
Last time I looked (several years ago) it was severly limited by that
problem (there not being a way to know which files should
On Tue, Mar 09, 2010 at 10:50:59AM -0600, Peter Samuelson wrote:
[Frank Lin PIAT]
Please, let's do the easy move *now* for Squeeze, using shasums, and
go ahead later with an even better solution.
Drawbacks: more CPU time on build daemons, slightly larger binary
packages to download, and
Hey Russ,
On Tue, Mar 9, 2010 at 13:57, Russ Allbery r...@debian.org wrote:
Joey Hess jo...@debian.org writes:
Russ Allbery wrote:
It's also always worth bearing in mind that while a really good
attacker can do all sorts of complex things that make them very hard to
find, most attackers are
[Harald Braumann]
See, you don't need a server. You just ship a signature over the hash
files. Easy as that.
And that signature - if you don't have a server - you probably want to
store it in the .deb, right? So you are going to be editing the .deb
after it is built. At which time, you could
retitle 540215 Introduce dh_checksums
tag 540215 +patch
thanks
On Thu, 2010-03-04 at 20:08 +0100, Tollef Fog Heen wrote:
Frank Lin PIAT wrote:
What about a transitional dh_md5sums that would produce md5sum AND
invoke dh_sha ?
Or call it dh_checksums or something so we don't have to
Frank Lin PIAT wrote:
Note regarding the patch:
I have tried to make the patch so it isn't too intrusive (for
instance, dh_checksums is a symlink to dh_md5sums even though it
should be the other way around).
Symlink direction seems irrelevant.
I'd probably just make dh_md5sums call
On Mon, 2010-03-08 at 12:21 -0500, Joey Hess wrote:
Frank Lin PIAT wrote:
Note regarding the patch:
I have tried to make the patch so it isn't too intrusive (for
instance, dh_checksums is a symlink to dh_md5sums even though it
should be the other way around).
Symlink direction
Frank Lin PIAT fp...@klabs.be writes:
Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
recent checksum.
The way it is implemented, is that the dh_md5sums is a symlink to the
new dh_checksums. The new helper computes both md5sum (for
compatibility/transition) and a new
On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote:
Frank Lin PIAT fp...@klabs.be writes:
Find a patch attached, for a smooth transition from DEBIAN/md5sums to a
recent checksum.
The way it is implemented, is that the dh_md5sums is a symlink to the
new dh_checksums. The new helper
Frank Lin PIAT fp...@klabs.be writes:
On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote:
1. Strengthen the integrity check so that it could potentially be useful
for security purposes as well as for simple integrity checking.
Yes, this is the intended goal. Imagine the following
Russ Allbery wrote:
The missing link, in this validation scenario, is how to get a signed copy
of the MD5 checksums of the files in the package.
That's one missing link. The other one is that there are innumerable
ways for an attacker to inject bad behavior/backdoors onto a system
without
On Tue, 9 Mar 2010, Joey Hess jo...@debian.org wrote:
Russ Allbery wrote:
The missing link, in this validation scenario, is how to get a signed
copy of the MD5 checksums of the files in the package.
That's one missing link. The other one is that there are innumerable
ways for an attacker
On Mon, Mar 08, 2010 at 11:04:24PM +0100, Frank Lin PIAT wrote:
On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote:
1. Strengthen the integrity check so that it could potentially be useful
for security purposes as well as for simple integrity checking.
It would be much easier if a
On Mon, Mar 08, 2010 at 05:59:13PM -0500, Joey Hess wrote:
Russ Allbery wrote:
The missing link, in this validation scenario, is how to get a signed copy
of the MD5 checksums of the files in the package.
That's one missing link. The other one is that there are innumerable
ways for an
Harald Braumann ha...@unheit.net writes:
On Mon, Mar 08, 2010 at 05:59:13PM -0500, Joey Hess wrote:
That's one missing link. The other one is that there are innumerable
ways for an attacker to inject bad behavior/backdoors onto a system
without touching binaries originating from dpkg.
Russ Allbery wrote:
It's also always worth bearing in mind that while a really good attacker
can do all sorts of complex things that make them very hard to find, most
attackers are stupid and straightforward.
It's stupid and straightforward to install /usr/local/bin/ls. debsums
will not detect
Joey Hess jo...@debian.org writes:
Russ Allbery wrote:
It's also always worth bearing in mind that while a really good
attacker can do all sorts of complex things that make them very hard to
find, most attackers are stupid and straightforward.
It's stupid and straightforward to install
87 matches
Mail list logo
