Raphael Hertzog 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 to
>> >
Harald Braumann 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 preceeding the sig
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
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 t
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 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 wh
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
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
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 long
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 ch
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 i
Raphael Hertzog 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 lead this proj
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
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 writes:
> > > On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote:
> >
> > >> You add an additional ar member that contains the signed chec
Harald Braumann 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 bit more fl
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-ter
Harald Braumann 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 the other
On Fri, Mar 19, 2010 at 05:56:40PM -0700, Russ Allbery wrote:
> Harald Braumann 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
Harald Braumann 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 control.tar.gz, or you
On Thu, Mar 18, 2010 at 04:52:07PM -0700, Russ Allbery wrote:
> Frank Lin PIAT 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 coul
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 ch
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 writes:
>> > > > Simon McVittie writes:
>> > >
>> >
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 writes:
> > > > Simon McVittie writes:
> > >
> > > >> Most packages (in terms of
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 t
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 discu
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 writes:
> > > > Simon McVittie writes:
> > >
> > > >> Most packages (in terms of
Russ Allbery writes:
> Goswin von Brederlow 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
Russ Allbery writes:
> Goswin von Brederlow 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 ca
Harald Braumann writes:
> On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote:
>> Russ Allbery writes:
>>
>> > Simon McVittie writes:
>> >
>> >> Most packages (in terms of proportion of the archive, in particular for
>> >> architectures other than i386 and amd64) are built by
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 writes:
> > > Simon McVittie writes:
> >
> > >> Most packages (in terms of proportion of the archive, in particular for
> > >> architectures other tha
Frank Lin PIAT 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 t
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 writes:
> > > On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
> > >> Harald Braumann writes:
> > >> > On Wed, Mar 10, 2010 at
Goswin von Brederlow 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 practi
Goswin von Brederlow 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
On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote:
> Russ Allbery writes:
>
> > Simon McVittie 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 woul
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
Wouter Verhelst writes:
> On Wed, Mar 17, 2010 at 04:12:46PM -0700, Russ Allbery wrote:
>> Wouter Verhelst 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..
Russ Allbery writes:
> Simon McVittie 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. Fur
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/que
On Wed, Mar 17, 2010 at 04:12:46PM -0700, Russ Allbery wrote:
> Wouter Verhelst 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/don
Wouter Verhelst 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 ever thrown
On 2010-03-17, 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.
> They may not be visible on the mirrors, but they are there.
But
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,
Simon McVittie 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 buil
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 propor
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 existin
On Wed, Mar 17, 2010 at 5:31 PM, Wouter Verhelst 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
h
On Wed, Mar 17, 2010 at 08:58:28AM +0100, Goswin von Brederlow wrote:
> Wouter Verhelst writes:
>
> > On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
> >> Harald Braumann writes:
> >>
> >> > On Wed, Mar 10, 2010 at 03:32:14PM +0100, Wouter Verhelst wrote:
> >> >>
> >> >> H
Wouter Verhelst writes:
> On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
>> Harald Braumann 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 infr
On Fri, Mar 12, 2010 at 05:16:55AM +0100, Goswin von Brederlow wrote:
> Harald Braumann 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 inst
Goswin von Brederlow 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
Harald Braumann 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 go
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
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.
>
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
[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 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 cle
On Wed, 2010-03-10 at 10:52 -0800, Russ Allbery wrote:
> Peter Samuelson 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
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
Peter Samuelson 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 so com
[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 neve
On Mon, Mar 08, 2010 at 12:59:00PM -0800, Russ Allbery wrote:
> Frank Lin PIAT 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 help
[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 coul
Hey Russ,
On Tue, Mar 9, 2010 at 13:57, Russ Allbery wrote:
> Joey Hess 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 straightf
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 downl
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 fil
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
[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.
Adva
* Peter Samuelson , 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 use, never min
* Harald Braumann [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 are
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
> 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
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 thin
On Mon, 2010-03-08 at 19:57 -0800, Russ Allbery wrote:
> Joey Hess 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 straightf
Joey Hess 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 /usr/local/bi
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 dete
Harald Braumann 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.
> Signatures don
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
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 i
On Tue, 9 Mar 2010, 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 attacker to inject
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 touc
Frank Lin PIAT 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 scenario:
> 1.
On Mon, 2010-03-08 at 12:59 -0800, Russ Allbery wrote:
> Frank Lin PIAT 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 comp
Frank Lin PIAT 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 checksum
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 di
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
86 matches
Mail list logo
